单体到微服务是一个演化过程，别在一开始就过度设计

大多数应用程序（可能是其中的 90％）采用了单体架构。为了避免过度工程化，我们应该从一个简单的架构开始，并根据需求进行演变。在 Reactive Summit 2018 大会上，Randy Shoup 在演讲中分享了他与小公司一起，逐步发展成为大型全球性互联网公司的经验，以及它们的架构是如何进行演变的，并从 IT 专业的角度为创办新公司或推出新产品提出了一些建议。

Shoup 曾在 eBay、谷歌和 Stitch Fix 工作，目前是WeWork的工程副总裁。他例举的第一个例子是 eBay，从 1995 年开始，作为一个为期三天的周末项目，不是作为业务的概念证明（PoC），而是为了弄清楚是否有可能在网上做一些有趣的事情。今天，他们正在对基础设施进行第 5 次完全重写，Shoup 将该公司的架构描述为多语言微服务集，并补充说 Twitter 和亚马逊都经历了类似的演变。

Shoup 认为，从某种形式的单体架构开始，最后得到一组微服务，这是大公司的常见演变模式。Shoup 还指出，这种模式包含了两个部分——没有人从一开始就采用微服务架构，而是达到一定规模后才走向微服务。

Shoup 所提到的公司都非常庞大，他指出，这些公司的架构并不完全适用于大多数其他公司。大多数应用程序采用单体架构就足够了，Shoup 建议，在构建新应用程序或系统时先从简单的架构开始，并根据需要改进架构。他说：

如果你到后面不后悔早期的技术决策，那么你之前可能过度工程化了。

Shoup 认为，大多数公司和产品的常见演化曲线包括构思和启动阶段，分布式系统可能还包含伸缩阶段，以及优化阶段：

在构思阶段，我们不应该考虑架构问题，而只是进行原型设计。为避免过度工程化，我们应该不断问自己：“我们要解决什么问题？”这个阶段的目标是尽可能快地探索解决方案，并以最低成本：

• 找到商业模式；

• 找到契合的产品市场；

• 吸引我们的第一批客户。

他建议我们，如果有可能，尽量避免使用任何技术，但可以使用谷歌广告来验证是否有用户点击，或使用原型或 Excel 电子表格。

进入启动阶段，目标变成了满足近期的客户需求，并尽可能以低成本来实现目标。在这个阶段，团队通常由 4 到 6 个人组成。他们的工作时间很短，可能只需要 3 到 4 个月，因为在这个阶段往往很难预先知道要构建哪些功能。我们只需要少量足以让我们前进的架构。Shoup 强调，它个阶段不要考虑伸缩性问题，我们应该使用简单而熟悉的技术，这绝对是一个单体架构——单个应用程序和单个数据库。基础设施应该尽可能小，而且不需要自己构建。相反，他建议使用平台即服务（PaaS）或类似的技术。

在这个阶段使用单体架构的优势包括：

• 简单；

• 速度快，因为它只有进程内延迟；

• 你将获得单个构建部署单元；

• 节省资源。

除了缺乏可伸缩性和存在单点故障之外，单体架构的主要缺点是缺乏模块化能力。虽然可以进行模块化，但它需要额外的编程和团队纪律。Shoup 指出，在这个阶段，这些都不是问题。但他认为，当我们需要为扩展做准备时，单体架构的组件化或模块化就变得有必要了。这将为在未来修改或替换服务提供便利。

对于我们何时需要重构单体，Shoup 列出了一些指标：

• 速度：由于耦合和缺乏隔离，导致交付速度减慢；

• 伸缩：垂直伸缩不再有效，或者系统的不同部分需要独立伸缩；

• 部署：系统不同部分的演化速度不一样，因此需要独立部署。

在进入扩展阶段时，我们的目标是保持业务的快速增长以及应用程序能够正常运行。在组织方面，我们现在通常会增加团队数量，并扩大工作时间范围。通常还需要引入可重复的过程。

在技​​术方面，扩展阶段通常意味着转向可扩展的技术。通常，我们开始从单体中分离出服务，并且尝试减少单个数据库的负载，例如为某些数据创建只读副本。通常也会将一些服务（如支付和计费等特殊服务）分离出来，并引入事件队列或消息总线。

Shoup 认为，这个时候通常也需要考虑我们是否应该将单体分解成小型的独立组件，也就是微服务。我们还必须考虑现在使用的单个存储器是否仍然合适。在纽约 2017 QCon 大会上，Shoup 展示了如何将单体应用程序增量迁移为微服务和几个独立的存储。

“The Art of Scalability”一书描述了一种三维可伸缩性模型（AKF Scale Cube），其中三个轴分别代表了不同类型的缩放：

• X：水平复制和克隆；

• Y：功能分解和分割（微服务）；

• Z：水平数据分区（分片）。

最后一个是优化阶段，Shoup 强调，这个阶段是成功的标志。此时的目标是保留功能，使用更少的资源，可能会减少团队。工作时间范围更长，可能是 2 到 5 年。

Shoup 总结说，在这种情况下，进行重构其实是一件好事：

重新构建系统是成功的标志，而不是失败。

业务发展得很好，你也有资源去做重构。这并不是说你一定要进行重构，而是你已经到了需要进行重构的时候。

查看英文原文：https://www.infoq.com/news/2019/01/rearchitecture-system-success