Airbnb的架构演进

Jessica Tai 是 Airbnb 的一名工程经理，负责平台基础设施方面的工作。她在 QCon上就 Airbnb 的架构以及这些年来它是如何转变的做了一场精彩的演讲。
摘要如下：
自公司成立以来，Airbnb 的架构经历了三个主要阶段。
Airbnb 最初是一个 Ruby on Rails 单体，然后过渡到微服务架构，现在已经迁移到微服务和宏服务的混合体（一个宏服务聚合多个微服务）。

单体（2008 - 2017）
Airbnb 开始使用 Ruby on Rails 单体，它对公司非常有效。
大多数工程师都是全栈工程师，可以处理代码库的每个部分，自己执行端到端的功能。功能可以在一个团队内完成，这有助于公司非常快速地构建新产品。
然而，随着 Airbnb 进入高速增长期，工程师、团队和代码行的数量迅速增加。
单个工程师/团队不可能理解并共享整个代码库的上下文，因此需要所有权和团队边界。
由于单体应用非常紧密耦合，Airbnb 一直在努力划定这些团队边界。
一个团队中的代码更改对另一个团队产生了意想不到的后果，并且谁拥有对代码库不同部分造成混淆的东西。
还有其他扩展痛点，例如极其缓慢的部署，有时需要一天多的时间才能完成一次部署。
这些问题导致开发人员速度变慢，Airbnb 决定转向面向微服务的方法来减少这些痛点。

微服务（2017 - 2020）
在从单体应用的经验中学习之后，Airbnb 的工程师们希望在他们的微服务方法上更加自律。
他们决定有 4 种不同的服务类型

读取和写入数据的数据获取服务
能够应用功能并将不同的数据组合在一起的业务逻辑服务
用于编写编排的工作流服务。这处理涉及跨多个服务接触数据的操作。
一个 UI 聚合服务，将所有这些放在一起为 UI

为了避免单体应用出现所有权问题，每个微服务只有一个拥有它的团队（每个团队可以拥有多个服务）。
通过这些变化，Airbnb 也改变了工程团队的结构方式。
以前，工程团队是全栈的，能够处理任何事情。但是现在，有了微服务，Airbnb 转向了只专注于堆栈的某些部分的团队。一些专注于某些数据服务，而另一些则专注于特定的业务逻辑。
Airbnb 也有一个专门的团队负责将单体应用迁移到微服务。该团队负责构建工具以帮助迁移，并向 Airbnb 工程师传授微服务构建和运营的最佳实践。
经过几年的微服务迁移，新的挑战开始出现。
管理所有这些服务及其依赖项非常困难。团队需要更加了解服务生态系统，以了解任何依赖关系可能存在的位置。
构建端到端功能意味着在整个堆栈中使用各种服务，因此不同的工程团队都需要参与其中：所有这些团队都需要围绕该功能有类似的优先级，这很难管理，因为每个团队都拥有多个服务。

微 + 宏服务 (2020 - )
为了应对这些协作挑战，Airbnb 现在正在采用微服务和宏观服务之间的混合方法。该模型侧重于 API 的统一和整合，以便为某些数据或功能提供明确的位置。
他们正在创建一个系统，他们的内部后端服务从数据聚合服务中获取数据。
然后，数据聚合器与各种服务块进行通信，其中每个服务块都封装了一组微服务。
Airbnb 工程师预见到这种方法的一个挑战是数据聚合器可以成为一个新的单体。
为避免这种情况，他们对哪些数据/服务属于哪里的边界非常自律。
对于服务块层，工程师需要确保他们以干净的方式定义模式边界。
有许多数据/逻辑可以跨越多个实体，因此需要明确定义。

欲了解更多详情，您可以在此处观看 Jessica 的完整演讲。