Airbnb爱彼迎开发了一个协作托管基础设施，支持所有类型的房东。这使得构建产品变得更加容易，因为工程师只需要了解一个涵盖所有托管用例的中央框架。合作托管对于 Airbnb 上的许多房东的成功至关重要。为所有房东打造的无缝开发者体验使我们能够让房东为房客提供出色的住宿体验。
Airbnb 的使命是让房东能够提供独一无二的住宿体验，让房客能够以更真实、更互联的方式体验世界。有时托管是由一个人处理的，但在许多情况下托管是一个团队的努力。房东通常会与另一个值得信赖的人分担他们的责任，例如家庭成员或邻居。这些值得信赖的合作伙伴是爱彼迎平台上的联合房东，他们有权访问房东的房源、预订信息以及与房客进行信息交流。
共同托管只是主持协作的一种形式。随着托管成为主流，托管规模也随之增长；事实上，现在很多人都将 Airbnb 房东作为他们的主要职业。从经营自己业务的房东企业家到隶属于知名酒店公司的房东，这些类型的房东通过 Airbnb 上的团队进行合作。在团队内，接待团队成员被授予与其实际接待职责相对应的角色（例如，客人经理）并拥有一组相应的权限（例如，允许向客人发送消息）。
随着协作主机数量的增加和新协作形式的引入，支持它们的工程工作变得越来越复杂。考虑到这一挑战，Airbnb 开发了一个单一的通用基础设施，可以支持所有当前和未来的 Airbnb 协作产品。此解决方案现在可供所有内部团队使用。
在这篇博文中，我们将介绍 Airbnb 协作托管的统一架构，以及我们如何使用这种共享基础架构来简化为房东构建产品的过程。在下一节中，我们将说明为什么在没有共享基础架构的情况下支持协作托管很快变得笨拙。然后，我们将介绍 Airbnb 的协作托管架构。最后，我们将讨论此基础架构如何支持产品工程师的需求。
。。。
协同托管核心架构
我们使用用户组作为数据模型来表示任何一组人。用户组由 id、组类型（例如COHOSTING、TEAM）和用户组成员列表定义。
用户组中的每个成员都由他们的 Airbnb 用户 ID 和用户组角色定义，这使我们能够区分用户组中不同类型的成员。例如，如果主持人（列表所有者）有一个共同主持人，那么相应的用户组将是一个COHOSTING具有两个成员类型的用户组：主持人，拥有LISTING_OWNER角色，共同主持人，拥有LISTING_COHOST角色。
此模型也可扩展到托管团队。我们根据托管团队通常如何分解团队成员之间的职责（例如LISTING_MANAGER角色、FINANCE_MANAGER角色和角色）来支持特定于 Teams 的多个角色GUEST_MANAGER。
在共同主持人或团队的创建和删除流程中，相应的用户组会相应更新。
资源 <> 用户组关联
现在我们有了一个用于任何协作托管组的模型，我们希望将每个组与该组的相应资源相关联。这样，当我们试图回答关于一个人是否与给定资源有关系的问题时，无论具体的协作关系如何，都有一个单一的来源可以给我们答案。我们通过存储 Airbnb 资源 ID、用户组 ID 和创建关联时的时间戳来跟踪这些资源 <> 用户组关联。
需要更新资源<>用户组关联的场景有两种：
- 当协作托管关系更新时。例如，创建托管团队时，团队创建者的所有资源都与团队相应的用户组相关联
- 当协作托管资源更新时。例如，当客人在联合托管房源上预订时，我们需要将联合托管用户组与新预订相关联，以便房源的联合托管人可以帮助房源所有者进行托管。
如果针对这些事件的更新没有及时发生，产品体验可能会过时。例如，如果房东将共同房东添加到列表中，但未更新基础关联，则共同房东将无法访问列表及其预订。
在 Airbnb 这样规模的企业中，保持资源 <> 用户组关联的最新状态可能具有挑战性。事态不断变化，有时是快速连续的；主持人可能会创建一个托管团队，然后改变主意并立即将其删除。结果，竞争条件确实发生了。
在本节的其余部分，我们将介绍 Airbnb 的可扩展系统，以在竞争条件下保持资源 <> 用户组关联的最新状态。在接下来的部分中，我们将详细介绍 Airbnb 在产品开发过程中如何利用这些资源 <> 用户组关联。
点击标题见原文