转载

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

大多数应用程序（可能是其中的 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）或类似的技术。

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