Airbnb 架构简史
内容提要
Brave Search API是一个价格实惠、高质量、易于使用和快速的AI项目工具。Airbnb的架构从单体应用程序发展到面向服务的架构（SOA），以解决可扩展性和协调问题。迁移过程中建立了数据服务、派生数据服务、中间层和展示服务。在过渡期间使用了比较框架以确保功能一致性。SOA的优点包括可靠性、可扩展性和增加的业务敏捷性，而缺点包括开发时间较长和复杂的依赖关系图。Airbnb开发了诸如API框架、Spinnaker的自动金丝雀分析和Powergrid用于并行任务执行的工具。通过使用服务块简化服务依赖关系。迁移到SOA需要投资基础设施、简化服务依赖关系和文化变革。
延伸解读
从单体到SOA的迁移策略
Airbnb的迁移并非一蹴而就，而是经历了三个版本：从纯单体，到单体与SOA共存的混合模式，最终完全过渡到SOA。在混合阶段，他们通过比较框架确保新旧路径的功能一致性，读操作采用双读对比，写操作则借助影子数据库。这种渐进式迁移降低了风险，但需要长期维护两套系统，对工程团队是不小的负担。
SOA的收益与代价
采用SOA后，Airbnb的系统可靠性和可扩展性得到提升，服务可独立部署和扩展，业务敏捷性增强。但代价也很明显：工程师需要熟悉更多服务，交付功能的时间变长；逻辑可能在不同服务中重复；缺乏治理时依赖关系图会变得复杂，甚至出现循环依赖，增加调试难度。这些权衡是迁移前必须考虑的。
支撑SOA的关键工具
为了应对SOA带来的复杂性，Airbnb开发了多个内部工具：基于Thrift的API框架统一了服务间通信，自动生成端点逻辑和客户端；Spinnaker支持自动化金丝雀分析，通过对比新旧版本流量决定是否推进部署；Powergrid则用DAG模型并行执行任务，提升端点响应速度。这些工具共同降低了服务化后的开发和运维成本。
服务块：简化依赖的实践
随着服务数量增长，调用图变得错综复杂。Airbnb引入“服务块”概念，将同一业务功能相关的服务（如房源、用户、可用性）打包，对外暴露统一的读写接口，内部则协调数据与业务逻辑服务，并禁止跨块直接调用内部服务。这有效降低了调用图的复杂度，但要求前期有清晰的领域划分和严格的治理。
Q&A
Airbnb 为什么从单体架构迁移到 SOA？
随着工程团队快速增长，单体应用的代码库变得紧密耦合，数据所有权不清晰，部署缓慢且冲突多，开发效率下降。为了解决可扩展性和协调问题，Airbnb 决定迁移到面向服务的架构（SOA）。
Airbnb 的 SOA 架构中服务分为哪几类？
Airbnb 将服务分为四类：数据服务（最底层，负责数据读写）、派生数据服务（基于数据服务应用基本业务逻辑）、中间层（处理不适合放在数据或派生服务中的复杂业务逻辑）、展示服务（聚合数据并应用前端逻辑后返回给客户端）。
Airbnb 在迁移过程中如何确保新旧架构功能一致？
Airbnb 构建了比较框架。对于读操作，进行双读并比较单体和新服务的响应；对于写操作，使用影子数据库，将新服务的写入先导向影子库，然后比较生产库和影子库的强一致读结果。确认一致后，逐步将流量切换到新服务。
Airbnb 的 SOA 架构有哪些优点和缺点？
优点：系统更可靠、高可用，服务可独立扩展，业务敏捷性提高。缺点：工程师交付功能需要更长时间，可能需要在多个服务中重复某些逻辑，依赖关系图复杂，缺乏 API 治理时可能导致循环依赖和调试困难。
Airbnb 开发了哪些工具来支持 SOA？
Airbnb 开发了 API 框架（基于 Thrift，用于定义服务间通信）、Spinnaker 的自动金丝雀分析（用于安全部署）、Powergrid（用于并行任务执行，基于 DAG 模型）。此外，还使用服务块来简化服务依赖。
Airbnb 如何简化复杂的服务依赖关系？
Airbnb 引入了服务块（Service Blocks）的概念。每个块是一组相关服务的集合，对外暴露统一的读写接口，内部协调数据与业务逻辑服务，并严格禁止直接调用块内内部服务。这大大降低了服务调用图的复杂性。
