Airbnb 的微服务质量工程之旅
原文：Airbnb’s Microservices Architecture Journey To Quality Engineering
平衡是一个无止境的追求。企业对软件交付质量和交付速度的极度依赖，让平衡更加困难。公司面临着不断提供高质量速度软件的挑战，而质量工程在软件生命周期中就起着约束作用。Airbnb 在加速和扩展其价值主张时，尤其是在信息系统的演进过程中面临了许多挑战。本文分享了 Airbnb 在质量工程方面的架构迭代过程，并给出了实际经验。文章结尾处有参考文献。关注QE 小组，了解更多来自社区的质量工程。
从单体到微服务，新瓶旧酒
起初，和很多软件公司一样，Airbnb 凭借较少的积极的工程师构建了一个最小可用产品，以此进入市场。
这个产品是一个单代码仓的单体架构软件。Airbnb 从 2008 开始逐步增长，用小型团队、少量依赖来完成构建。
但是在 2017 年，这种中心化架构遭遇了瓶颈：
软件迭代变慢
并行演化受阻
组件所属关系混乱
Airbnb 决定拥抱微服务。
现存的单一代码仓被分为 front 和 back-office（注重速度的 Hyperloop 和专注于稳定性的 Treehouse）。微服务各有各的仓库，出现了负责组件转型的迁移团队。
3 年后，也就是 2020 年，业务营收将达到 50 亿美金。团队增长，并持续进行服务迁移。但是老问题又来了——有些功能的进展需要触及多个服务，以及背后的多个团队。
架构的口号是“不影响业务增长”，工程团队退让一步，为了这些重复出现的问题，找到可持续的解决方案。
Airbnb 架构演进的挑战
Airbnb 面临的挑战在于，架构方案不但要解决当下的问题，还要支持未来的规模；质量工程需要面对这个事情。
公司依赖迭代增长的过程：
定义问题
发掘增长方案
解决方案落地
推广解决方案
克服解决方案的规模问题
这种方法分离了各个问题的关注点，找到了结构化的方案，并在后期解决规模问题。但是这种方法只有在工作范围较小且必要的情况时才奏效。
迁移的挑战
针对迁移，Airbnb 采取了如下措施：
实现 IaC，提升开发生产力
利用工具和可观测性能力，理清所属权
用新的结构和方法来定义新架构
建立专注淘汰工作的组织，从而加速迁移进程
接下来看看我们是如何解决问题的。
实现 IaC，提升开发生产力
业务的变化依赖软件，软件进展缓慢或者缺陷会直接对公司的竞争力产生影响。
根据对微服务架构的认识，Airbnb 聚焦于自动化和工具化的建设。更快的节奏要求技术进步。
这里用 IaC 作为一种务实的解决方案，逐步增加增加服务的采用率。随着服务运维规模的增长，高度的复杂性和规模化的挑战就出现了。
利用工具和可观测性能力，理清所属权
太多的微服务纠结在一起，牵一发而动全身，难于掌控。
Airbnb 致力于生产力的提高，重点是在 3 个方面为新架构提供支持：
所有权
可观测性
工具
所有权
Airbnb 部署了 Scry Ownership 应用，以此掌握技术组件的所属关系数据，例如所属权、维护者、通信方式等：
可观测性
建立了一系列的可观测性仪表盘，系统性的对系统行为进行审视。下面的例子展示了对所有权的统计：
工具
数据方面的挑战非常明显。Thrift 在序列化和数据描述方面非常有效，但是在产品中还需要其它组件来使用这些数据。
Airbnb 利用 GraphQL 构建了统一的数据访问层，直接提供查询能力：
代码生成是增进开发生产力的最后一环。更多的技术，为各个层面的标准组件提供模板支持。
逐一击破之后，我们发现，中央数据聚合组件成了新的瓶颈。
用新的结构和方法来定义新架构
中央数据聚合组件的迭代节奏太慢了。就算是有了前面的生产力提升措施，经过长期积累，结构性的复杂度也日益增长。因此需要新的结构。
随着时间的迁移，系统复杂性天然就有增长的趋势，要抵抗这种趋势，需要支持和反制。
质量工程开始进入了架构、组织和方法等领域。
支撑增长的架构
在这种复杂的环境下，要在不同领域、不同团队之间进行同步，会是一个高成本、高耗时的过程。
分析一下微服务架构的问题树：
复杂度分布在细粒度的服务之中
细粒度服务之间缺乏稳定的合作关系
组件和团队的关系支离破碎
微小的变更也可能引发复杂的问题
不管微服务还是单体架构，模块化和关注点分离都是必要的。
Airbnb 采用了新的架构方式：Micro+Macroservice：
这种架构中，每种复杂性都被分布在清晰的层次之中：
统一 API 是微服务，支持快速的产品迭代
中央数据聚合组件是一个稳定的单体，其中包含了紧密的耦合关系
服务块 API：抽象的微服务