AirBnb架构简史

             2007 年，布莱恩·切斯基 (Brian Chesky) 和乔·加比亚 (Joe Gabbia) 搬到了旧金山。他们一边想为本身的创业想法筹集资金，一边又需要付出房租。
    可巧的是，当时城里正要举行一个设计会议，这意味着很多设计师都会寻找住处。他们想出了在客厅里放一个充气床垫，把它变成一个提供过夜和早餐的旅馆的主意。
    2008 年，Nathan Blecharczyk 参加 Brian 和 Joe 的公司，继承首席技术官和联合创始人，他们创办了名为 AirBed and Breakfast 的企业。
    这就是 Airbnb 的诞生。
    如今，Airbnb 已覆盖 200 多个国家，400 万房东在全球范围内欢迎了超过 15 亿客人。
    随着 Airbnb 的突飞猛进，其软件架构也不停发展以跟上期间的变革。
    在这篇文章中，我们将回顾 Airbnb 架构多年来的演变、他们一路走来所获得的经验教训以及他们为支持这一愿景而开发的工具。
             初始版本

   与大多数初创公司一样，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人生。快扫描下面二维码关注吧！
   

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。