RetailMeNot，属于Ziff Davis，Inc的一部分，让购物者过更实惠的生活。他们是领先的节省目的地，提供线上和线下优惠券和现金返还优惠。RetailMeNot通过其桌面、移动网页、原生（iOS和Android）应用和浏览器扩展（交易查找™）体验，为每月数百万活跃用户提供服务。
通过采用GraphQL现代化其技术堆栈
2019年，RetailMeNot开始了一项项目，旨在现代化其技术堆栈，以便更好地为未来的体验做好准备并增加公司收入。Kartik Kumar Gujarati是RetailMeNot的高级软件工程师，他在RMN的工程博客中描述了这一演变：
“在过去10年中，RetailMeNot的工程团队构建了多个高性能、可扩展和高效的系统，通过我们的体验为用户提供节省数据。就像许多公司一样，RetailMeNot使用REST API来提供数据。然而，随着公司和系统的增长，我们开始遇到版本控制、过度检索和不足检索等问题。最终，这导致了性能限制。”
为了为他们的网页和原生应用体验以及新的浏览器扩展Deal Finder™提供动力，RetailMeNot开始采用一个单体GraphQL API的解决方案。他们有一个团队负责治理和该图的标准。客户团队被授权可以向单体图做出贡献，而中心图团队将审查他们的贡献。
单体图成为瓶颈
然而，随着时间的推移，单体图开始成为RetailMeNot的瓶颈。API团队发现自己被所有的贡献搞得手忙脚乱。API团队的资深软件工程师Hannah Shin描述了挑战：
“我们的团队负责维护那个单体。但我们有许多不同的客户团队在做这项工作。我们开始陷入协调不同发布周期、冲突特性和确保特性得以正确测试的困境。”
Hannah的团队还负责维护核心数据源和它们的事件驱动架构。然而，她的团队被代码审查压得喘不过气来。
“我们三个工程师的团队花了大约75%的时间来审查对我们GraphQL单体代码的更改，这让我们几乎没有时间去创新我们的后端平台。”
采用 Apollo Federation 超图
RetailMeNot 认识到他们的单体架构已无法扩展，并希望找到一个既能够为在图上构建的日益增长的团队提供良好解决方案的方案。他们选择了 Apollo Federation，因为它允许每个子图团队构建和维护其统一的超图模式的一部分。正如 Hannah 所说，
“我们希望团队之间不要过于紧密耦合。在维护我们的单体架构期间，我们发现数据结构中存在许多不一致和不效率的问题。例如，我们有一个网页优惠卡、一个应用优惠卡，还有一种类型的优惠卡。我们相信，有了共享的图和共享类型的集中所有权，我们将作为组织更好地理解和建模我们的数据。”
从单体架构迁移的过程是渐进的。Kartik 在他的博客文章中深入描述了这个过程。
“以下是本次迁移所采取的渐进步骤
- 首先，我们将单体服务中现有的 GraphQL 模式转换为支持联合规范。这使得我们能够在同一服务中支持联合规范和模式拼接的一个开源库如下提供对联合规范的支撑。
- 然后，我们设置了一个新的网关服务，该服务只是将流量转发到单体服务。
- 通过加权路由技术，我们控制了将打入新网关服务与单体服务的流量量。一旦我们在测试环境（阶段/预生产）中对于改变和验证有信心，我们就将所有流量切换到100%通过网关服务进行生产。此时，我们的单体服务完全位于网关后端。
- 最后，我们开始将单体服务中的模式分离开来（现在成为子图），并将实体迁移到更细小而统一的子图服务中。
超级图：更快捷、更安全的产品发布方式
在采用 Apollo Federation 和 Apollo Studio 之后，RetailMeNot 开始看到立即的收益。通过使用 Apollo Studio 自动化他们的架构审查和部署，RetailMeNot 的 API 团队不再花费大多数时间审查代码。
韩慧欣说：“在采用管理式联盟和模式检查后，我们从三个工程师花费75%的时间来审查代码转变为不到10%。”
他们的平台团队可以专注于创新。他们不再进行代码审查，而是专注于建立向图谱贡献的最佳实践。他们开始为开发人员、工程领导者和产品团队定期进行GraphQL优势的教育课程。随着时间的推移，讨论转向了改善他们的超图谱。他们在可观察性、模板化体验和内容分发方面投入了更多。
“自我们采用Apollo以来，已经一年多没有出现任何重大更改了。在采用Apollo之前，我们每月都会出现重大更改。我们曾经关闭移动主页长达六小时。”
韩慧欣 零售返利网高级软件工程师
零售返利网在迁移到他们的超图谱后，可靠性也显著提高。韩慧欣说：“自从我们采用Apollo以来，已经一年多没有出现任何重大更改了。在采用Apollo之前，我们每月都会出现重大更改。我们曾经关闭移动主页长达六小时。”
“在单体架构中工作意味着你必须非常小心你的变更，转向子图谱架构让你可以更快地工作。自从我们迁移到Apollo联盟后，我们能够将功能早早推出，速度快了40%。”
卡蒂克·库马尔·古贾拉蒂 零售返利网高级软件工程师
痛苦的重置和战争室的日子已经被对GraphQL发布流程的更多信心所取代。结果是，团队在他们从GraphQL单体到超图谱的过程中看到开发速度有显著提升。卡蒂克说：“在单体架构中工作意味着你必须非常小心你的变更，转向子图谱架构让你可以更快地工作。自从我们迁移到Apollo联盟后，我们能够将功能早早推出，速度快了40%。”
下一步是什么
采用超图谱使零售返利网能够不断引入新的团队和服务。零售返利网计划通过继续模块化其架构来进行创新。目前，他们正在构建一个与内容管理系统集成的模板化系统。通常，他们的运营团队创建新页面需要花费高达1个月的时间。这需要编写特定的功能代码，可以用模板化方法来替换。不久，他们的运营团队将能够无需请求新的功能即可自助创建新页面和体验。从长远来看，这将使他们能够更改模板并将其传播到所有不同用例，使实验变得更加容易。
随着零售返利网工程团队继续扩展他们的超图谱，他们的重点是帮助教育和引入新团队。在博客文章中总结了迁移到超图谱的优势，卡蒂克指出以下优势：
- “加快产品迭代：用户界面应用团队可以更快地移动，因为从单个“GraphQL API团队”的瓶颈被移除了。”
- 基于关注的分离：转向联邦架构使不同的团队能够在不影响/阻塞彼此的情况下工作在不同的产品领域，同时为单一图做出贡献。
- 服务之间相似的技栈：转向联邦架构帮助我们标准化了RetailMeNot中多个服务的技栈。这也导致了团队之间的紧密协作。
- 开发者体验：得益于标准化的工具和共同的技栈，开发者体验得到了大幅提升。
想了解更多关于RetailMeNot如何转向超图的信息？观看这个网络研讨会，讨论他们的历程。
下一个故事
分享文章
