Airbnb统一协作托管架构设计与构建总结

Airbnb最近详细介绍了其如何设计和构建一个统一的协作托管架构，该架构简化了新产品的开发流程。通过这一架构，工程师只需了解一个核心框架，即可覆盖所有托管用例，从而无需关注具体的协作托管类型。

背景与动机

最初，Airbnb的每个房源由单一房东管理。随着业务发展，Airbnb引入了“共同托管”模式，允许房东与信任的人（如家人或邻居）共享托管责任。如今，托管已成为许多房东的主要职业，他们作为业务的一部分管理团队并为每个成员分配角色。

Airbnb工程师Angeline Rao指出，随着协作托管模式的增加和新协作形式的引入，支持这些模式的工程工作变得越来越复杂。她总结了封装这些业务需求的动机：工程师在构建新功能时需要了解所有现有的协作托管类型，并决定协作托管者如何与功能交互。如果没有统一的框架，产品开发过程将变得繁琐。

单一托管模型的局限性

在单一托管模型中，工程师可以通过在房源上存储房东ID来轻松确定谁有权对房源进行操作。但随着协作托管模式（如共同托管和团队托管）的引入，权限检查代码变得复杂，难以维护。

统一架构的设计

在新框架中，Airbnb使用“用户组”来表示任何人群。每个用户组由一个ID、组类型（如共同托管、团队等）和成员列表定义。每个成员在组中都有一个角色（如所有者、共同托管者等）。一个中央位置负责维护用户组与系统资源（如房源、预订等）之间的所有关联。

事件驱动的更新机制

当协作托管关系或资源更新时，系统会触发一个事件来更新相关关联。该事件不包含变更的详细信息，仅指定了特定资源或组已发生变更及其ID。系统随后获取数据并以最终一致的方式计算正确的关联。

这种事件处理方式允许工程师通过并行化和批量更新来优化性能。由于每次资源更新事件都会触发与具体更新类型无关的关联重新计算，整个更新过程是幂等的。

开发简化与查询模式

在这一系统的基础上，Airbnb创建了多个模式，允许开发者查询特定操作的权限、每个用户允许的资源以及每个资源允许的用户，从而进一步简化开发。这些模式包括使用Himeji查询权限，以及使用ElasticSearch将用户与资源关联与资源数据连接以便于查询。

通过这一统一架构，开发者无需了解协作托管的具体细节，而是可以依赖这一单一位置的数据来理解特定用户与资源之间的关系。