Agoda的非常规客户端优先迁移：从GraphQL单体到微服务的经验教训
引言： 想象一下，一个每天处理数百万次预订的全球性在线旅游平台，需要将庞大的GraphQL单体架构迁移到微服务架构，而这一切都必须在不中断用户服务的情况下完成。Agoda，这家亚洲领先的在线旅游公司，就面临着这样的挑战。他们没有选择传统的服务器端优先迁移，而是大胆采用了“客户端优先”的策略，并通过一个内部构建的智能编排器（Smart Orchestrator）实现了这一壮举。本文将深入探讨Agoda的迁移历程，分析其策略的优缺点，并从中汲取宝贵的经验教训。
主体：
1. 迁移的动机：单体架构的瓶颈
Agoda的供应商管理系统，由7人团队维护，支撑着70多个客户端服务，其单体GraphQL架构已不堪重负。InfoQ采访了Agoda助理开发经理Numan Hanif，他指出，单体架构导致平均变更交付周期环比增长12%，每月创建40个合并请求，测试时间长达一小时且稳定性仅73%。此外，高昂的运维成本、知识孤岛和陡峭的学习曲线也成为亟待解决的问题。这些瓶颈直接影响了Agoda的业务增长和敏捷性。
2. 客户端优先的策略：风险最小化与敏捷性提升
与传统的服务器端优先迁移不同，Agoda选择优先准备客户端。他们开发了一个内部的智能编排器，这个动态路由层能够在单体GraphQL API和新部署的微服务之间无缝切换。这使得客户端应用程序能够在迁移过程中平滑地处理单体和微服务混合环境，最大限度地减少了中断风险。Hanif强调，这种方法提升了团队对整个堆栈的控制力，并使其架构更符合敏捷开发原则。 他们没有选择类似Netflix的Apollo Federation方案，而是选择了更灵活的内部解决方案。
3. 智能编排器的核心功能：路由、模式管理与增量迁移
智能编排器是Agoda迁移策略的核心。它不仅负责路由客户端请求，还自动管理模式更新和映射，支持增量迁移。最初，所有模式都指向单体，随着微服务的逐步上线，编排器会动态更新映射，将查询路由到正确的微服务。这种增量式迁移，结合严格的单体测试和准确性测试系统（持续比较单体和微服务的输出），确保了迁移的可靠性。
4. 数据驱动的方法：查询分类与拆解
Agoda采用了一种数据驱动的方法，分析了100个应用程序Git仓库中的GraphQL查询，并根据域间依赖程度将查询分为简单、中等和复杂类型。简单的查询无需修改，中等查询被拆分为多个独立请求并在客户端合并结果，而复杂的查询则需要更广泛的重组。这个过程，特别是复杂查询的“拆解”，是迁移的关键步骤，它需要工程师对业务逻辑和数据依赖关系有深入的理解。
5. 经验教训：技术债务与重构的重要性
在迁移过程中，Agoda也遇到了挑战。他们发现，将现有代码原封不动地迁移到微服务，导致一些旧的技术问题被转移到了新的微服务中，例如缺少客户端速率限制。Hanif指出，他们应该在迁移过程中实施重构实践，以确保迁移后的架构更清洁、更高效。这提醒我们，迁移不仅仅是架构的改变，更是一个清理技术债务、优化系统设计的机会。
6. 微服务边界定义：数据驱动而非DDD
Agoda没有采用领域驱动设计(DDD)作为定义微服务边界的默认框架，而是采用了一种数据驱动的方法。他们从数据库模式出发，通过标记将表分类到特定的域中，再将GraphQL端点与相应的表域对齐。这种方法虽然在处理复杂查询时面临挑战，但它与Agoda现有的数据管理模式相一致，确保了服务边界的一致性。
结论：
Agoda的客户端优先迁移策略为其他企业提供了宝贵的经验。这种方法在降低风险、提升敏捷性方面具有显著优势，但同时也需要对客户端进行充分的准备，并重视迁移过程中的重构工作。 智能编排器作为关键组件，有效地处理了单体和微服务之间的过渡。 然而，数据驱动的方法在处理复杂业务逻辑时可能面临挑战，需要结合其他方法进行优化。 最终，Agoda的经验表明，成功的微服务迁移不仅仅是技术问题，更需要周全的规划、敏捷的执行和持续的优化。
参考文献:
- InfoQ 文章: Agoda 的非常规客户端优先迁移：从 GraphQL 单体架构到微服务架构 (需补充InfoQ文章的完整链接)
(注：由于无法访问外部网站，我无法提供InfoQ文章的完整链接。请读者自行搜索该文章。)
Views: 0