低风险版本发布的架构设计

### 低风险版本发布的架构设计 #### 1. 架构演变的必要性 几乎每个知名的 DevOps 范例都曾因架构问题经历过生死考验，比如领英、谷歌、eBay、亚马逊和 Etsy 等公司。但它们最终都成功迁移到了更合适的架构，解决了当前问题并满足了组织需求。这就是进化式架构的原则，Jez Humble 指出：“任何成功的产品或组织的架构必然会在其生命周期内不断演变。” Randy Shoup 曾在 eBay 担任首席工程师和杰出架构师，他发现 eBay 和谷歌都已经进行了第五次全面的架构重写。他反思道，从现在的角度看，过去的一些技术和架构选择有的很有远见，有的则目光短浅，但每个决策在当时很可能都是为了最好地服务于组织目标。如果在 1995 年就尝试实现微服务架构，很可能会失败。 #### 2. 架构迁移的挑战与方法 从现有架构迁移到所需架构是一项挑战。以 eBay 为例，当需要重新架构时，他们会先进行一个小的试点项目，以证明自己对问题有足够的理解。例如，2006 年 Shoup 的团队计划将网站的某些部分迁移到全栈 Java 时，他们通过按页面产生的收入对网站页面进行排序，选择了收入最高的区域，直到业务回报不足以证明努力的合理性时才停止。 Shoup 团队在 eBay 采用的是进化式设计的典型案例，使用了“绞杀者无花果应用模式”。这种模式不是直接“拆除并替换”不再支持组织目标的旧服务架构，而是将现有功能放在 API 后面，避免对其进行进一步更改。所有新功能则在使用新架构的新服务中实现，必要时调用旧系统。 #### 3. 紧密耦合架构的问题 许多时候，我们会发现自己处于一个过于紧密耦合和相互关联的架构中，这种架构往往是多年甚至几十年前创建的。其后果很容易察觉：每次尝试将代码提交到主干或发布到生产环境时，都有可能导致全局故障，比如破坏其他人的测试和功能，或者整个网站崩溃。为了避免这种情况，每一个小的更改都需要数天或数周的大量沟通和协调，以及可能受影响的任何团队的批准。 部署也会成为问题，每次部署时批量更改的数量会增加，进一步使集成和测试工作复杂化，并增加出现问题的可能性。即使部署小的更改也可能需要与数百甚至数千名其他开发人员进行协调，任何一个人都可能导致灾难性的失败，可能需要数周时间才能找到并修复问题。这也导致开发人员只有 15% 的时间用于编码，其余时间都花在会议上。 #### 4. 能提高生产力、可测试性和安全性的架构 与紧密耦合的架构不同，具有明确定义接口的松散耦合架构可以促进生产力和安全性。它使小型高效团队能够进行小的更改，并可以安全、独立地部署。每个服务都有明确定义的 API，便于服务测试以及团队之间创建合同和服务级别协议（SLA）。 例如，谷歌的 Gmail 服务下面有五到六层其他服务，每个服务都专注于特定功能，由小团队支持。谷歌云数据存储服务是世界上最大的 NoSQL 服务之一，却只由大约八个人的团队支持，这很大程度上是因为它基于层层可靠的服务构建。这种面向服务的架构使小团队能够在更小、更简单的开发单元上工作，并独立、快速、安全地部署。 #### 5. 主要架构原型：单体架构与微服务架构 大多数 DevOps 组织在其发展历程中都曾受到紧密耦合的单体架构的困扰。虽然单体架构在帮助组织实现产品/市场契合方面非常成功，但一旦需要大规模运营，就会使组织面临失败的风险。例如，eBay 在 2001 年的单体 C++ 应用、亚马逊在 2001 年的单体 Obidos 应用、推特在 2009 年的单体 Rails 前端以及领英在 2011 年的单体 Leo 应用。不过，这些组织都能够重新架构他们的系统，不仅生存下来，还在市场中蓬勃发展。 单体架构并非天生不好，实际上，在产品生命周期的早期，它通常是组织的最佳选择。Randy Shoup 指出，没有一种架构适用于所有产品和所有规模，任何架构都要满足特定的目标、需求和约束条件，如上市时间、功能开发的难易程度、可扩展性等。产品或服务的功能几乎肯定会随着时间的推移而演变，因此我们的架构需求也会发生变化。 以下是主要架构原型的优缺点对比表格： | 架构类型 | 优点 | 缺点 | | --- | --- | --- | | 单体 v1（所有功能在一个应用中） | - 一开始简单<br>- 进程间延迟低<br>- 单一代码库；一个部署单元<br>- 小规模时资源高效 | - 随着团队增长，协调开销增加<br>- 模块化执行不佳<br>- 扩展性差<br>- 全有或全无的部署（停机、失败）<br>- 构建时间长 | | 单体 v2（一组单体层：“前端展示”、“应用服务器”、“数据库层”） | - 一开始简单<br>-