15、低风险发布的架构设计

低风险发布的架构设计

在软件开发领域，架构的选择和演进对于企业的成功至关重要。许多知名的DevOps范例都曾因架构问题面临生死考验，但最终都成功迁移到更合适的架构，以满足当前的问题和组织需求。

1. 架构演变的必要性

几乎每个知名的DevOps范例都经历过因架构问题导致的濒死体验，如领英、谷歌、易贝、亚马逊和Etsy等公司。这体现了进化式架构的原则，即任何成功的产品或组织的架构在其生命周期中必然会不断演变。

易贝前首席工程师兼杰出架构师兰迪·肖普（Randy Shoup）指出，易贝和谷歌都已经对其架构进行了五次全面重写。回顾过去，有些技术和架构选择具有前瞻性，而有些则显得短视，但每个决策在当时很可能都是为了最好地服务于组织目标。如果在1995年就尝试实现微服务架构，很可能会因自身负担过重而失败，甚至可能拖垮整个公司。

面临的挑战是如何从现有的架构迁移到所需的架构。以易贝为例，当需要重新架构时，他们会先进行一个小的试点项目，以证明自己对问题有足够的理解，才会投入精力进行大规模改造。例如，2006年肖普的团队计划将网站的某些部分迁移到全栈Java时，他们通过按页面产生的收入对网站页面进行排序，选择了能带来最大收益的区域，当业务回报不足以证明努力的价值时就停止。

2. 紧密耦合架构的问题

我们常常发现自己处于一个过于紧密耦合和相互关联的架构中，这种架构往往是多年（甚至数十年）前创建的。这种架构的后果很容易察觉：每次尝试将代码提交到主干或发布到生产环境时，都有可能导致全局故障，如破坏其他人的测试和功能，或者整个网站崩溃。为了避免这种情况，每一个小的更改都需要数天或数周的大量沟通和协调，以及任何可能受影响的团队的批准。