# Airbnb 的微服务质量工程之旅 原文：[Airbnb’s Microservices Architecture Journey To Quality Engineering](https://medium.com/qe-unit/airbnbs-microservices-architecture-journey-to-quality-engineering-d5a490e6ba4f) 作者：[Antoine Craske](https://qeunit.com/) 平衡是一个无止境的追求。企业对软件交付质量和交付速度的极度依赖，让平衡更加困难。公司面临着不断提供高质量速度软件的挑战，而[质量工程](https://qeunit.com/blog/quality-engineering-is-about-surviving-the-digital-transformation/)在软件生命周期中就起着约束作用。Airbnb 在加速和扩展其价值主张时，尤其是在信息系统的演进过程中面临了许多挑战。本文分享了 Airbnb 在质量工程方面的架构迭代过程，并给出了实际经验。文章结尾处有参考文献。关注[QE 小组](https://qeunit.com/follow)，了解更多来自社区的质量工程。 ## 从单体到微服务，新瓶旧酒 起初，和很多软件公司一样，Airbnb 凭借较少的积极的工程师构建了一个最小可用产品，以此进入市场。 这个产品是一个[单代码仓](https://qeunit.com/blog/airbnbs-monorepo-journey-to-quality-engineering/)的单体架构软件。Airbnb 从 2008 开始逐步增长，用小型团队、少量依赖来完成构建。 ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745824551472/ce4c5e90-70d3-41f5-ba89-959a92ba85bf.png align="center") 但是在 2017 年，这种中心化架构遭遇了瓶颈： * 软件迭代变慢 * 并行演化受阻 * 组件所属关系混乱 Airbnb 决定拥抱微服务。 现存的单一代码仓被分为 `front` 和 `back-office`（注重速度的 `Hyperloop` 和专注于稳定性的 `Treehouse`）。微服务各有各的仓库，出现了负责组件转型的迁移团队。 ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745824570321/52662f35-16f4-41a1-b5fa-21e1401eeb3f.png align="center") ![mono-and-vs](images/mono-and-ms.png align="left") 3 年后，也就是 2020 年，业务营收将达到 [50 亿美金](https://www.statista.com/statistics/1193134/airbnb-revenue-worldwide/)。团队增长，并持续进行服务迁移。但是老问题又来了——有些功能的进展需要触及多个服务，以及背后的多个团队。 架构的口号是“不影响业务增长”，工程团队退让一步，为了这些重复出现的问题，找到可持续的解决方案。 ## Airbnb 架构演进的挑战 Airbnb 面临的挑战在于，架构方案不但要解决当下的问题，还要支持未来的规模；质量工程需要面对这个事情。 公司依赖迭代增长的过程： 1. 定义问题 2. 发掘增长方案 3. 解决方案落地 4. 推广解决方案 5. 克服解决方案的规模问题 这种方法分离了各个问题的关注点，找到了结构化的方案，并在后期解决规模问题。但是这种方法只有在工作范围较小且必要的情况时才奏效。 ## 迁移的挑战 ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745824627311/8655bcc7-a389-4cfc-b0ac-19ff41763d45.png align="center") 针对迁移，Airbnb 采取了如下措施： 1. 实现 IaC，提升开发生产力 2. 利用工具和可观测性能力，理清所属权 3. 用新的结构和方法来定义新架构 4. 建立专注淘汰工作的组织，从而加速迁移进程 接下来看看我们是如何解决问题的。 ### 实现 IaC，提升开发生产力 业务的变化依赖软件，软件进展缓慢或者缺陷会直接对公司的竞争力产生影响。 根据对微服务架构的认识，Airbnb 聚焦于自动化和工具化的建设。更快的节奏要求技术进步。 ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745824640829/d53bbfac-147b-4c6e-99e1-dd16d78bc4af.png align="center") 这里用 IaC 作为一种务实的解决方案，逐步增加增加服务的采用率。随着服务运维规模的增长，高度的复杂性和规模化的挑战就出现了。 ### 利用工具和可观测性能力，理清所属权 太多的微服务纠结在一起，牵一发而动全身，难于掌控。 ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745824763523/e9637545-bb85-43a9-9d63-c1f08686ee61.png align="center") Airbnb 致力于生产力的提高，重点是在 3 个方面为新架构提供支持： * 所有权 * 可观测性 * 工具 #### 所有权 Airbnb 部署了 `Scry Ownership` 应用，以此掌握技术组件的所属关系数据，例如所属权、维护者、通信方式等： ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745824679152/288934e3-6cb4-48ed-bee7-e4bd19120ae0.png align="center") #### 可观测性 建立了一系列的可观测性仪表盘，系统性的对系统行为进行审视。下面的例子展示了对所有权的统计： ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745824722797/2376d9ba-4951-47f4-a3b4-7c83257ef724.png align="center") ![dashboard](images/dashboard.png align="left") #### 工具 数据方面的挑战非常明显。[Thrift](https://thrift.apache.org/) 在序列化和数据描述方面非常有效，但是在产品中还需要其它组件来使用这些数据。 Airbnb 利用 GraphQL 构建了统一的数据访问层，直接提供查询能力： ![graphql](images/graphql.png align="left") ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745824689903/7e4fc581-3112-4b7b-a3d3-0fc27d7748ae.png align="center") 代码生成是增进开发生产力的最后一环。更多的技术，为各个层面的标准组件提供模板支持。 ![codegen](images/codegen.png align="left") ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745824694652/19ff736c-ae3c-4b69-bca9-5a576949bd42.png align="center") 逐一击破之后，我们发现，中央数据聚合组件成了新的瓶颈。 #### 用新的结构和方法来定义新架构 中央数据聚合组件的迭代节奏太慢了。就算是有了前面的生产力提升措施，经过长期积累，结构性的复杂度也日益增长。因此需要新的结构。 随着时间的迁移，系统复杂性天然就有增长的趋势，要抵抗这种趋势，需要支持和反制。 质量工程开始进入了架构、组织和[方法](https://qeunit.com/blog/this-is-why-you-need-methods-for-quality-at-speed/)等领域。 ### 支撑增长的架构 在这种复杂的环境下，要在不同领域、不同团队之间进行同步，会是一个高成本、高耗时的过程。 分析一下微服务架构的问题树： * 复杂度分布在细粒度的服务之中 * 细粒度服务之间缺乏稳定的合作关系 * 组件和团队的关系支离破碎 * 微小的变更也可能引发复杂的问题 不管微服务还是单体架构，模块化和关注点分离都是必要的。 Airbnb 采用了新的架构方式：`Micro+Macroservice`： ![micro+macroservices](images/macro-micro-service.png align="left") 这种架构中，每种复杂性都被分布在清晰的层次之中： * 统一 API 是微服务，支持快速的产品迭代 * 中央数据聚合组件是一个稳定的单体，其中包含了紧密的耦合关系 * 服务块 API：抽象的微服务