初始版本

与大多数初创公司一样，Airbnb 的第一个 Web 应用程序版本是一个单体应用程序。它使用 Ruby-on-Rails 构建，内部称为monorail。

在 Airbnb 看来，Monolith 是一个负责客户端和服务器端功能的单层单元。

这在实践中意味着什么？

这意味着模型、视图和控制器层被组合在一个单一的存储库中。

下图显示了这种方法。

这种整体式方法有几个优点：

• 单体应用很容易上手，这也是 Airbnb 最初的需要
• 它们有利于敏捷开发
• 复杂性是可控的

随着 Airbnb 工程团队的快速发展，问题也随之而来。Airbnb 的规模逐年翻倍，这意味着越来越多的开发人员在单体应用程序中添加新代码，并更改现有代码。

随着时间的推移，代码库开始变得更加紧密，数据所有权变得不明确。例如，很难确定哪些表属于哪个应用程序功能。任何开发人员都可以对应用程序的任何部分进行更改，跟踪和协调更改变得困难。

这种情况导致了多个问题，例如：

• 在任何时候，都有数百名工程师在单轨列车上工作，因此部署变得缓慢而繁琐。
• 由于 Airbnb 遵循民主部署的理念（每个工程师负责测试和部署他们的更改以投入生产），这导致其变更相互冲突，陷入混乱。
• 工程效率下降，开发人员的挫败感日益增加。

为了缓解这些痛点，Airbnb 开始了从单体架构向面向服务架构（SOA）的迁移之旅。

Airbnb 的 SOA

Airbnb 如何看待面向服务架构（SOA）？

对于他们来说，SOA 是一个松散耦合的服务网络，其中客户端向某种网关发出请求，网关将这些请求路由到多个服务和数据库。

采用 SOA 使 Airbnb 能够单独构建和部署服务。此外，这些服务可以独立扩展，所有权也变得更加明确。

然而，构建服务是一回事。以规范的方式设计这些服务也极其重要。

Airbnb 决定采用一些关键原则来以规范的方式设计这些服务：

• 服务应拥有对其数据的读取和写入。这与每个服务一个数据库的模式非常相似，其中特定的数据库应由一个且仅一个服务拥有，从而更容易维护数据一致性。
• 每项服务都应解决一个特定的问题。Airbnb 希望确保单体不会分解成另一个巨型服务，随着时间的推移，该巨型服务又会变成另一个单体。此外，他们还希望避免走上只擅长一件事的传统细粒度微服务之路。相反，Airbnb 转向构建专注于特定业务功能的服务。可以将其视为高内聚设计。
• 服务应避免功能重复。通过共享库和共享服务可以共享部分基础设施或代码，从而更易于维护。
• 数据变更应通过标准事件进行。例如，如果预订服务创建了新行，则可用性服务应通过事件了解此预订，以便将房屋的可用性标记为繁忙。
• 每项服务都必须像任务关键型服务一样构建。这意味着服务应该具有适当的警报机制、内置可观察性和基础设施最佳实践。

在 Airbnb 看来，这些原则极其重要，它们有助于创建一条所有工程师都可以遵循的逻辑路径，以建立对服务架构的共同理解。

职场攻略与副业指南，成就你的IT人生。快扫描下面二维码关注吧！

Airbnb 的迁移之旅

秉承着上述原则和目标，Airbnb开始了从单轨模式向全新服务型模式的迁移之旅。

这是一个漫长的迁移过程，一路上经历了多次迭代。

版本 1

在这个版本中，每个请求都通过单轨进行。

单轨主要负责表示视图、业务逻辑以及数据访问。

你可以将其视为 Airbnb 架构的初始状态。

版本 2

下一个版本是单轨与面向服务的架构共存的混合版本。

主要区别在于单轨仅处理路由和视图层。它的工作是将传入的 API 流量发送到负责业务逻辑、数据模型和访问的新服务网络。

我们在这里谈论的是什么样的服务？

Airbnb 将其服务分为四种不同类型，如下图所示。

以下是各类服务的详细信息：

• 数据服务——这是最底层，是所有数据实体读写操作的入口点。数据服务不能依赖于任何其他服务，因为它只访问数据存储。
• 派生数据服务 — 派生服务位于数据服务之上一层。这些服务可以读取数据服务，也可以应用一些基本的业务逻辑。
• 中间层——用于容纳不适合数据服务级别或派生数据服务级别的大量业务逻辑。
• 演示服务 — 结构最顶层是演示服务。它们的工作是汇总来自所有其他服务的数据。此外，演示服务还会在将数据返回给客户端之前应用一些前端特定的业务逻辑。

有了这些服务定义，Airbnb 开始构建数据服务层。

例如，他们从家庭数据服务开始，这是 Airbnb 业务的基础层。当​​前的单轨设置使用 Rails 中的 Active Record 数据访问库从表中访问数据。

他们在 Active Record 级别拦截传入的请求，并且不路由到数据库，而是将这些请求发送到新的家庭数据服务。然后，家庭数据服务负责路由到数据存储。

下图显示了这种方法。

在创建核心数据服务之后，Airbnb 还将核心业务逻辑迁移到了 SOA 方法。

例如，迁移定价派生数据服务等服务，该服务需要来自家庭数据服务以及其他存储（如离线价格和趋势）的有关房屋的一些信息。

下一步涉及迁移演示服务，例如依赖于派生数据服务和核心数据服务的定价信息和房屋信息的结帐演示服务。

所有这些变化都是版本 2 的一部分，其中单轨列车和新服务在同一个请求周期内共存。

版本 3

在这个版本的迁徙之旅中，单轨列车被彻底淘汰了。

客户端向 API 网关发出请求，该网关充当负责中间件和路由的服务层。网关填充请求上下文并将请求路由到 SOA 网络，其中各种服务负责表示逻辑和数据访问逻辑。

Web 客户端的处理方式略有不同。有一个专门的服务来处理 Web 请求。

为什么需要它？

此服务通过调用 API 网关并以所需格式填充收到的响应，将 HTML 返回到 Web 客户端。API 网关负责所有中间件功能并通过 SOA 网络传播请求。

下图试图展示这种情况：

迁移读取和写入

到目前为止，您可能已经意识到，从单一架构转变为面向服务的架构并不是一朝一夕的过程。

对于 Airbnb 来说，中间阶段花费了大量时间，其中必须将单轨列车和新服务作为一等公民来支持。

请求可以通过单轨或服务进行。这意味着，确保两条路线的功能不会中断并且响应相同是一项关键要求。

为了支持这一点，Airbnb 建立了读取和写入的比较框架。

阅读

这些比较框架的首次使用是在读取操作中，因为读取是幂等的。您可以发出多个读取请求并获得相同的响应。

这个想法是发出双重读取，并将通过单轨的读取路径 A 的响应与通过新服务的读取路径 B 的响应进行比较。然后将捕获的响应作为标准事件发出，这些事件被使用并发送到离线比较框架。

比较框架被置于管理工具后面，这样无需更改代码和部署即可控制流量。响应调整完成后，Airbnb 工程师可以通过服务路径缓慢增加流量，并监控比较结果是否存在差异。

一旦比较看起来清楚，所有读取请求都会移动到新服务。

写入

对于写入，必须采取不同的做法，因为无法对同一个数据库进行双重写入。因此，我们利用了影子数据库。

假设单轨列车正在调用访问生产数据库的演示服务。这是写入路径 A。

现在，引入了中间层服务来减轻演示服务的一些验证负担。最初，此中间层服务将写入影子数据库，而不是主生产数据库。

此时，可以轻松地向生产数据库和影子数据库发出强一致性读取请求并比较结果。

一旦比较清楚，我们就可以通过新服务将写入内容移至生产数据库。

SOA 的优点和缺点

随着 Airbnb 从单轨铁路向基于 SOA 的架构的迁移，一些优点和缺点开始变得明显。

一些优点如下：

• 系统变得更加可靠和高可用。即使一个服务出现故障，面向服务架构的其他部分仍可正常运行。
• 服务现在可以单独扩展，允许根据系统的实际需求对资源分配进行微调。
• 由于将产品的不同部分划分为不同的服务，因此提高了业务敏捷性。每个团队可以并行迭代。

然而，也存在一些缺点：

• 工程师可能需要更多时间才能在面向服务架构中发布一项功能，因为他们需要首先熟悉各种服务。此外，任何变更都可能涉及多项服务
• 即使服务是松散耦合的，某些逻辑模式也必须在不同的服务之间重复。
• 依赖关系图复杂，尤其是在缺乏 API 治理的情况下。这也可能导致循环依赖，并使工程师难以调试错误。

支持 SOA 的工具和技术

正如我们从上一节看到的，迁移到 SOA 为 Airbnb 工程团队带来了多重挑战。

例如，单个请求现在会分散到多个服务，从而增加失败的几率。此外，将数据模型分离到多个数据库中有利于服务级别的一致性，但这会使事务性更难以实施。

随着时间的推移，服务编排也变得越来越复杂。由于有数百名工程师在构建服务，Airbnb 需要更多的 EC2 实例。最终，这促使其转向使用 Kubernetes。

为了让工程团队轻松构建服务，Airbnb 的基础设施团队在此过程中创建了许多构建模块。

API 框架

Airbnb 创建了一个使用 Thrift 语言构建的内部 API 框架。

所有 Airbnb 服务均使用该框架来定义可以相互通信的清晰 API。

例如，假设服务 A 想要与服务 B 通信。服务 B 工程师只需使用简单的 Thrift 语言定义端点，框架就会自动生成端点逻辑来处理常见内容，例如模式验证、可观察性指标等。

此外，它还创建一个多线程 RPC 客户端，服务 A 可以使用它来与服务 B 通信。该客户端处理各种功能，例如重试逻辑、错误传播和传输。

这有什么好处呢？

工程师可以专注于处理核心业务逻辑，而不必花时间担心服务间通信的细节。

为了提高开发人员的工作效率，Airbnb 基础设施团队还开发了 API Explorer，工程师可以在其中浏览不同的服务，确定要调用哪些端点，甚至使用 API 游乐场来了解如何调用这些端点。

使用 Spinnaker 进行自动 Canary 分析

Airbnb 还利用了开源持续交付平台 Spinnaker。

Spinnaker 用于跨各种云平台进行应用程序管理和部署。它支持所有主流平台，例如 AWS、Azure、Kubernetes 等，因此可以非常轻松地启动新的部署环境。

您可以在 Spinnaker 中创建管道来表示特定的交付过程，该过程从创建构建工件开始，一直到在环境中部署该工件。

借助 Spinnaker，Airbnb 能够轻松设置执行自动金丝雀分析的环境。

基本上，他们将新旧快照都部署到两个临时环境中，然后将一小部分流量路由到它们两个。

根据流量分析和错误率，为金丝雀环境生成一个总体分数，帮助决定是否失败或将金丝雀提升到部署过程的下一阶段。

Powergrid

Airbnb 还建立了一个名为 Powergrid 的内部库，使并行运行任务变得容易。

通过 Powergrid，他们能够将代码执行组织为有向无环图 (DAG)。

这个 DAG 的每个节点都是一个函数或任务。利用这个，Airbnb 工程师可以将每个服务端点建模为一个数据流，其中请求为输入，响应为输出。

由于 Powergrid 支持多线程和并发，因此可以用来并行运行任务。

下图显示了 Powergrid 的概念。

例如，假设主人想给客人发送特别优惠。然而，在发送之前，需要进行多次检查和验证。

借助 Powergrid，各个服务可以并行执行这些验证。汇总响应后，即可向客户发送特别优惠。

简化服务依赖关系

一旦 Airbnb 开始走上 SOA 之路，就再也没有回头路了。

然而，最初缺乏服务治理和依赖管理，导致服务交互图复杂。在面向服务的方法中，调用图变得极其复杂总是一种危险的情况。

• 任何新的改变都会导致开发速度减慢。
• 此外，维护也变得困难。

为了处理这种情况，Airbnb 决定使用服务块的概念来简化服务依赖关系。

基本上，您可以将每个块视为与特定业务功能相关的服务的集合。

例如，列表块封装了与核心列表属性相关的数据和业务逻辑。同样，您还可以拥有其他块，例如用户块和可用性块。

然后，Block 可以向上游客户端公开一个干净整洁的外观，并具有一致的读写端点。在底层，外观会根据需要协调数据和业务逻辑服务之间的协调。此外，还会实施严格的检查，以防止直接调用块内的任何内部服务。

这种方法大大降低了面向服务调用图的复杂性。

结论

总而言之，Airbnb 在从单轨迁移到 SOA 的整个过程中得到了几个重要的教训。

以下是一些需要注意的重要事项：

• 尽早投资公共基础设施
• 优先简化服务依赖关系
• 进行必要的文化变革以实现面向服务的方法
• SOA 不是一个固定的目的地，而是一个不断改进和完善的旅程。

职场攻略与副业指南，成就你的IT人生。快扫描下面二维码关注吧！