Airbnb复盘微服务

实现平衡是一个永无止境的追求。

当业务依赖软件质量和速度来生存时，这种平衡就更难维持了。

许多公司都面临着持续快速交付高质量软件的挑战，这些软件通过质量工程限制生命周期。

Airbnb 在加速和扩展其价值主张的过程中面临着众多挑战，尤其是其信息系统的发展过程。

本文分享了 Airbnb 在质量工程方面的架构迭代之旅，并附有实用要点。

Airbnb 和许多软件公司一样，也是由一些积极进取的工程师发起构建最小可行产品以进入他们的市场从而发展起来的。

该产品最初是单仓内的单体架构（在此处访问完整的 Airbnb 单仓旅程[1]）。Airbnb 在这种模式下从 2008 年开始发展，其功能由各小团队完成，小团队之间的依赖及其有限。

但在 2017 年，这个集中式架构达到了它的极限：

• 软件变更速度降低

• 平行演进面临限制因素

• 组件所有权混乱

Airbnb 决定采用微服务。

现有的单体应用被拆分为前台和后台（分别是为了速度的Hyperloop和为了稳定性的Treehouse）。微服务出现在各自仓库中，而专门的服务迁移团队负责组件的转换。

3 年后的 2020 年，该业务的收入达到 50 亿美元（直到 COVID 爆发）。团队和微服务持续增加。但是，原来的问题又回来了：功能需要由多个服务和不同团队同时开发。

在他们的架构口号“我们不能影响业务增长”的推动下，工程团队跳出原有方式，为这些反复出现的问题寻找可持续的解决方案。

Airbnb 面临着架构解决方案的挑战，不但要解决现在的问题，同时要支持未来的扩张；这就是质量工程要解决的问题。

Airbnb 采用了增量和迭代过程：

1. 定义问题

2. 找到改进的解决方案

3. 使用解决方案

4. 提高解决方案采用率

5. 处理解决方案的扩展挑战

这种方法能够分离每个问题的关注点，找到结构化的解决方案并在以后扩展它们。

Airbnb 在采用上述方法过程中实施了以下做法：

• 提供基础设施即代码以提高开发人员的生产力

• 明确所有权并通过工具和可观察性进行改进

• 定义由组织和方法支持的新架构

• 引入一个弃用工作组以加速迁移

让我们看看前述问题是如何解决的。

提供基础设施即代码以提高开发人员的生产力

当业务变革能力依赖于软件时，缓慢和错误的软件开发直接影响公司的竞争力。

凭借在微服务架构方面的经验，Airbnb 投资了自动化和工具化。但在一系列不断发展的技术中需要更快的迭代周期。

务实的解决方案是在单个仓库中投资基础设施即代码，从而逐步并行提升各个服务的采用率。

当运行更多服务时，就会出现理解这种复杂性的扩展挑战。

明确所有权并通过工具和可观察性进行改进

有太多的微服务相互捆绑；即使很小的变化也会导致相互依赖的变化和影响，掌握起来很复杂。

Airbnb 投资于提高生产力，重点支持三个领域的新架构：

1、所有权

Airbnb 部署了“Scry Ownership”，它是技术组件所有权数据（如所有者、维护者、通信渠道）的应用管理者。

2、可观察性

Airbnb 设置了一系列可观察性仪表板，以系统地审查实施过程。下面是一个仪表板示例，用于跟踪正在设置的所有权：

3、工具

数据空间仍然存在挑战。定制的 Thrift[2] 模式是有用的序列化器和数据描述符，但它们需要其他组件来检索产品中的数据。

Airbnb 利用 GraphQL 构建了统一的数据访问层，直接提供查询能力。

代码生成是提高开发人员生产力的最后一步。随着技术的增加，Airbnb 为每一层的标准组件提供了模板。

通过设计指明数据类型和访问类型的代码注释，数据的访问甚至直接就被嵌入在了代码中。

当星号看起来对齐时，就会出现另一个速度问题。这一次，中央数据聚合器组件成为了限制因素。

定义由组织和方法支持的新架构

中央数据聚合器的构建和部署时间太慢，团队无法按时迭代。

即使提高了生产力，累积的结构复杂性仍然太高而无法在中央组件中处理。需要一个新的组织。

熵是系统随着时间的推移变得更加复杂的自然趋势，需要支持和反作用力来平衡生态系统。

质量工程力量在架构、组织和方法领域发挥作用。

1、支持增长的架构

太复杂了，团队必须对不同领域执行缓慢且成本高昂的影响分析，协调多个团队并纠正副作用错误。

让我们分析一下“纯微服务架构”级联问题树：

• 复杂性过度分布在细粒度服务中

• 这些细粒度的微服务缺乏稳定的协作点

• 缺失的粘合剂最终分布在组件和团队之间

• 即使是很小的变化也往往会导致混合影响

核心问题是缺乏城市化，导致单体或微服务架构缺乏模块化和关注点分离。

Airbnb 采用了一种新的架构风格 Micro macroservices：

在这样的架构中，每种类型的复杂性分布是一个清晰的层：

• 统一 API是支持产品快速迭代的微服务

• 中央数据聚合器是具有紧密耦合的稳定单体

• 服务块外观 API抽象了提供实体块的微服务。

阅读本文[3]，了解有关速度和质量架构的价值的更多信息。

2、组织一致性支持新架构

旨在支持业务目标的组织可以改变游戏规则。这种调整对于 Airbnb 的加速发展至关重要。

该组织与不断发展的架构保持一致，产品团队在统一 API 之上工作，数据聚合团队在中央数据层（即“胶水”），以及每个数据方面的域平台团队（预留、用户）。

3、方法强制通往新架构的铺平道路

架构审查、IT 委员会、工艺治理——这些都是用于根据当前环境和未来架构审查提出的解决方案的方法。

这种方法的价值在于作为一种反力量，在由其他目标驱动的项目环境之外，以平衡选择。

Airbnb 使用这些方法为 Micro macroservices 架构铺平了道路。

即使不包括在内，Airbnb 的管理层肯定对领导转型和发展新模式的文化以及发展技能产生了巨大影响，从而完成了 MAMOS 的范围。

有了这些变化，Airbnb 能够引领平行的迁移轨道。但是弃用 Monolith 仍然需要太多时间。

引入弃用工作组加速迁移

单独更改我们的银行账户已经是一场噩梦。当需要数年时间与多个团队协调才能完成时，这项任务就更加复杂了。

Airbnb 就像许多其他拥有遗留系统和持续业务的组织一样：他们无法在建造新房子的同时炸毁他们居住的房子。

一个特定的组织单位致力于加速从单体架构中迁移出来，领导以下工作：

• 移动应用程序弃用达12个月以上

• 提升和跟踪整体债务以获得可见性

• 日落低使用率的终端以加速删除

• 迁移的长期所有权

• 认识到折旧对估值有影响

这个团体有游说的反击力量，但对于实现迁移目标至关重要。反对单体应用不能是“每个人的责任”。

当这项任务完成时，将面临其他挑战。

Airbnb 架构演变的这一观点为 Quality at Speed 软件提供了具体的质量工程要点。

首先，区分局部问题或扩展问题可以更好地识别潜在原因，从而更好地采用增量解决方案。

在精益方法中，Airbnb 的团队在遇到问题时解决问题，避免不必要的预优化等浪费。

从我的角度来看，一个可行的要点在于架构，MAMOS 的其他元素是这个结构块的对齐。

从单仓内的单体应用出发，然后根据业务发展对其进行划分，就像他们对两个存储库所做的那样。

然后，他们的故事举例说明了“纯微服务架构”的问题，并被具有延迟的反馈循环的 Micro macroservices 架构所取代。

你将使用哪种架构风格？

相关链接：

1. https://qeunit.com/blog/airbnbs-monorepo-journey-to-quality-engineering/
2. https://thrift.apache.org/
3. https://qeunit.com/blog/how-architecture-contributes-to-quality-at-speed/

推荐阅读：

《老去的MongoDB，未来在哪里？》

《我在Uber创立SRE团队的故事》

有想一起学习K8s、考CKA证书吗？来，这里有最好的学习方案，线下3天封闭式培训，15人小班课，考不过免费复训。Kubernetes实战班，7月22日在深圳开课，扫描下方二维码咨询详情。