导读：Airbnb的架构是如何一步步迭代到现在的，欢迎阅读本文。

与大多数初创科技公司一样，Airbnb 最初也是从构建单体应用开始。在其公司内部，它被人们称为“单轨列车” ，因为所有操作都通过这个单一应用进行的。

这个单体应用同时负责客户端和服务端的功能。模型层、视图层和控制器层都被打包到一个单独的代码库中。

此种架构的简单示意图，请看下图所示：

这种整体的架构与方法有几个优点：

• 入门很容易

• 有利于敏捷开发

• 可控制的复杂度

那是一个充满简洁的时代，而这样的“好时光”通常不会持续太久。

Airbnb的发展超级迅猛，其软件工程团队规模翻了一番又一番。很短的时间之内，很多的开发者开始为这个看似简单的系统添加新的代码与功能。

就像人多了反而会把菜做得不好一样，代码库开始变得高度耦合，数据所有权也变得混乱。任何开发人员都可以修改应用程序的任何部分，这使得跟踪和协调这些更改变得十分困难。

Airbnb决定从单体架构迁移到面向服务的架构（SOA）。你也可以将其视为向松耦合微服务架构迈出的一步。

新的游戏规则

当然，Airbnb 颇有远见，并为架构服务制定了一些关键的设计原则。以下列举其中一些重要原则：

• 一个服务应该同时拥有对其数据的读取和写入权限。这类似于每个服务一个数据库的模式，在这种模式下，特定的数据只能由一个服务持有

• 服务应针对具体问题

• 服务应避免功能重复

• 为了促进松耦合，数据变更应该通过标准事件进行

• 每个服务都必须具备适当的告警和可观测性设置

面向SOA的设计

经过几年的迁移工作，Airbnb最终采用了以下的架构：

让我们来详细分析一下。

• 底层由数据服务组成。这些服务是所有与数据库交互的入口点，并且不依赖于任何其他服务。

• 派生服务从其他服务读取数据并应用基本业务逻辑。它们还可以拥有专门的数据存储，用于存储任何派生数据。

• 中间层服务包含关键业务逻辑，这些逻辑不适合放在数据服务层或派生数据服务层。

• 最顶层是展示服务。这些服务汇总来自所有其他服务的数据，并应用前端特定的业务逻辑，然后将数据返回给客户端。

开始迁徙

从单轨列车过渡到崭新的公共交通服务并非一朝一夕之功。此外，读写操作的迁移也遇到了一些问题。

让我们来看看这两种情况以及 Airbnb 是如何处理迁移的。

迁移读取数据

Airbnb 对旧读取路径（通过单轨列车）和新读取路径（服务）进行了双重读取和响应比较。

请来看下图：

每个读取请求都会经过两条路径。响应会被发送到对比框架。软件工程师确认一切正常后，才会逐步增加服务路径的流量。

迁移写入操作

写入操作比较棘手，因为不能同时向同一个数据库写入两份数据。因此，工程师们使用了影子数据库。

请来看下图：

新的服务最初会将数据写入影子数据库。之后，读取请求会发送到生产数据库和影子数据库，并将响应发送到比较框架。

只有在对比结果确认无误后，写入操作才完全切换到新服务。

结语

Airbnb 从整个系统迁移过程中吸取了一些经验教训。对我们来说，其中一些重要的经验教训总结如下：

• 尽早投资通用基础设施组件。例如影子数据库、框架比较等，这些都能在迁移过程中提供帮助；

• 简化服务依赖关系；

• 向服务型组织转型，不仅仅是技术上的变革，也是组织文化上的变革；

• 迁移并非到达固定的目的地，而是一段新的旅程。

那么，你如何看待Airbnb的迁移历程？如果换做你会采取不同的做法吗？

作者：洛逸

参考：

https://newsletter.systemdesigncodex.com/p/airbnbs-move-from-monolith