为什么 Segment 从微服务回归单体

几乎每个工程团队都考虑过在某个时候转向微服务，它们在带来好处的同时也让团队付出了代价。

在 QCon 伦敦大会上，Alexandra Noonan讲述了Segment如何将单体分解成微服务，然后几年后又回归单体架构。用 Noonan 的话说，“如果微服务的实现不正确，或者在没有解决系统中一些根本缺陷的情况下，把微服务当创可贴使用，那么你将无法进行新产品开发，因为你将淹没在巨大的复杂性中。”

微服务的引入首先是为了解决 Segment 单体应用的有限故障隔离问题。然而，随着公司的发展壮大，外部服务集成越来越多，支持微服务的运营开销变得难以承受。在决定回归单体时，他们提出了一个新的架构，充分考虑了公司发展过程中的扩展之痛。尽管在模块化、环境隔离和可见性方面做出了牺牲，但单体解决了运营开销这个主要的问题，让工程团队可以重回新特性开发。

Noonan 解释了 Segment 架构发展的几个关键点。在任何有经验的软件工程师看来，他们所面临的问题以及当时所做的决定都不陌生。事后，我们才能清楚哪些决定本可以更好。Noonan 通过一个时间轴逐个介绍了主要的决策点，并指出了系统架构每个状态的优缺点。

2013 年，Segment 开始采用单体架构。它运营开销比较低，但缺少环境隔离。Segment 的功能基础是集成来自许多不同提供商的数据。在单体中，到一个提供商目的地的连接有问题，就可能会对到所有提供商目的地的连接和整个系统产生不利影响。

迁移到微服务（每个目的地一个 worker 服务）解决了单体内部缺少隔离的问题。微服务还改进了整个系统的模块化和可视性，使团队可以轻松地查看队列长度和识别有问题的 worker。Noonan 指出，可见性也可以构建在单体应用上，但在微服务中不需要付出额外的成本。然而，微服务带来了更多的运营开销和代码重用相关的问题。

在 2016 年至 2017 年间，Segment 的市场飞速增长，新增 50 多个目的地，平均每月新增 3 个。对于少数目的地 worker 来说，每个服务一个代码库是可管理的，但是随着规模的扩大，这就变成了一个问题。对于所有 worker 中都有的类似行为，他们创建了共享库。然而，这产生了一个新的瓶颈，对共享代码的更改可能会花掉开发人员一周的时间，这主要是由于测试限制。创建多个版本的共享库可以加快代码更改的实现速度，但是也会抵消共享代码所带来的好处。

Noonan 指出了他们在微服务中采取一刀切方法的局限性。因为仅仅是添加新服务就需要大量的工作，所以其实现不是定制化的。尽管每个服务的负载和 CPU 资源需求有很大的不同，但所有服务都应用了同一个自动扩展规则。此外，对于真正的故障隔离，恰当的解决方案应该是每个客户每个队列一个微服务，但这将需要超过 1 万个微服务。

2017 年，在做了各种权衡之后，包括失去微服务所带来的好处，他们重归单体。新架构被命名为Centrifuge，它能够处理每天发送给数十个公共 API 的数十亿条消息。现在，他们有一个代码存储库，所有的目的地 worker 都使用共享库的同一个版本。较大的 worker 能够更好地处理峰值负载。新增目的地不会再增加运营开销，而部署只需几分钟。对企业来说，最重要的是，他们能够重新开始开发新产品。与微服务相比，新架构的模块化、环境隔离和可见性降低了，但 Segment 的团队认为，上述所有这些好处值得他们这样做。

这个演讲听起来就像是一名传统的工程师加入了一个有着悠久历史的项目。与会者对此展开了讨论，有人说，“好啦，很明显你不应该做他们做过的事”，类似这样的短评遭到了经验丰富的人士的反驳，他们认为，Segment 的大多数决定都是基于当时所能获得的最佳信息做出的。其中一个重要的结论是，花几天或几周时间做更多的分析，可以避免出现需要几年时间才能纠正的情况。

原文链接：

To Microservices and Back Again - Why Segment Went Back to a Monolith