什么？你的团队没有100人，那就不要用微服务了！

作者 | Justin Etheredge

译者 | 平川

编辑 | 万佳、Tina

行业新趋势？这些公司微办事没用上 3 年就放弃了！

微办事正在统治世界，甚至有可能正在成为新的默认选项。

O'Reilly 查询拜访了 1283 个企业，有 52％的受访者表示他们正在应用微办事进行软件开辟。个中跨越 28％应用微办事跨越三年，跨越 55％应用微办事的时光为一到三年。O'Reilly 还指出企业对微办事的兴趣可能达到或接近巅峰。

这几年，有无数的中小团队在微办事上陷入了挣扎。微办事有好处但也存在弊病和风险，营业赓续成长，微办事也加倍复杂，一些企业衡量利弊后甚至选择了退回单体架构。本年有好几个公司总结了他们放弃微办事实践的工作。

Uber 付出体验平台放弃了微办事，转而应用了合理范围办事。

4 月 6 日，Uber 付出体验平台的工程经理 Gergely Orosz 宣布推文表示其团队的架构偏向已经产生了变更，放弃微办事，转而应用宏办事。

为什么会做出如许的选择呢？Gergely Orosz 表示：“最早，Uber 经由过程构建微办事来完成很小的需求或功能，以至于出现了很多由一小我构建保护的微办事。这些微办事的存在给我们带来了新的复杂性和挑衅，例如监控、测试、持续集成 / 持续交付（CI/CD）、办事级别协定（SLA）、跨所有微办事的库版本（安然和时区问题）等等。”

是以，在创建新平台的时刻，Uber 付出体验团队对新办事进行了加倍沉思熟虑的筹划：不再只是完成一件事，而是使其办事于一项营业功能，由 5-10 个工程师负责保护。Gergely Orosz 把如许的办事筹划称之为宏办事。

要在精确的时光选择精确的解决筹划来构建产品。

Botify 是一家从事 搜刮引擎优化 优化的公司，其平台于 2012 年在 Python/Django 技巧栈上创建。2016 岁首?年代，全部 Botify 平台都是经由过程 Django 应用法度榜样的负载均衡集群供给办事。

2016 年事尾，Botify 工程团队想让工程师和产品经理拥有更多的局部所有权，从而可以快速轻松地将他们的产品和技巧栈投入应用。为此，他们决定将他们的 Django 应用法度榜样拆分为微办事。当时，他们的团队大年夜约为 15 人。他们从身份验证和授权入手实现第一个微办事，将 Django 应用法度榜样当前的一部分功能转移到微办事中。微办事模块也须要和其他的 Django/Python 单体模块进行通信。

Botify 的平台是一个企业级 B2B 办事，赞助收集上最大年夜的网站改良他们的 搜刮引擎优化，重要挑衅在于对客户数据的分析。处理用户相干数据的微办事架构旨在办事于高流量的 B2C 平台，而 Botify 的挑衅在于动态地聚合数以 GB 的 搜刮引擎优化 数据，使其在几秒钟内可用。对大年夜约一万名客户的元数据以毫秒为单位进行响应，这项义务不须要高度可伸缩的微办事架构。恰好相反，Botify 的后端到后端通信减慢了这些简单的检索过程，花费了更多的时光。

鉴于天天都要在 Java 身份验证后端和 Django 模块之间频繁地往返切换，衡量架构的优缺点以及潜在的迁徙成本后，他们做出了大年夜胆的选择，将身份验证后端从新参加到 Django 单体中。Botify 于本年 2 月停用了微办事。其团队负责人 David Wobrock 表示：“每一种技巧都自有其用处，但我们信赖，要在精确的时光选择精确的解决筹划来构建我们的产品。如今，我们不必往返切换了，也不消保护两个后端了，显然，我们已经从中获益。”

“我们公司也从单体转向了微办事，但最后在二者之间找到了一个均衡点。”

在 2017 年的时刻，办公治理软件公司 Managed by Q 的技巧团队大年夜概有 20 名工程师，应用法度榜样是一个安排在 ECS 上的 Django 单体。为了赶上现代化开辟实践的办法，他们开端转向了微办事架构。

但跟着微办事数量的增长，工作不像之前那么顺利了。

每多一个新办事，就会增长一些基本举措措施。比如，一个 ECS 办事、一个 Postgres 实例或一个 RabbitMQ 实例。CI/CD 的设备也会增长，还须要进行第三方办事（比如 Rollbar/Sentry）设备。依附也须要更新，并且须要更新依附的处所越来越多。基本举措措施团队在项目上花了很多时光，为每一个办事反复着逝世板无味的工作。并且小型的办事轻易被人忽视，在运行起来之后，根本上会被搁在一边，最后就会过时。

假如办事界线没有搞清楚，还会明显降低功能的开辟速度，这是微办事的一个很大年夜的风险点。开辟一个跨多个办事的功能须要做更多的工作，而重构一个跨多个办事的功能是一个恶梦。假如办事界线很清楚，大年夜部分项目只会影响到一个办事。然则，对于始创公司来说，它们的成长偏向是弗成猜测的。一个产品的两个部分在一开端可能是完全自力的，但一年之后可能会变得慎密耦合起来。所以，要完全清楚地定义办事界线不是件轻易的事。

最后，在转向微办事两年之后，他们开端归并微办事。一些微办事被合到了单体中，其他的则归并成较大年夜的办事。在一年中总共移除了 9 个微办事。大年夜小合理的办事承担着相昔时夜的义务，大年夜多半功能开辟都可以在单个办事中完成。

不克不及当然地认为微办事就是精确的选择。

微办事已经被这代人当成银弹，不过，上面提到的这些企业已开端用更抉剔的眼光来对待它。这些例子中，他们认为转向微办事的工程开销太大年夜，不值得。而如许的案例还有很多。

每个体系实现都邑有一些缺点的选择。然则，他们所犯的最大年夜的缺点与他们的微办事实现无关。他们所犯的最大年夜缺点是在只有 20 名工程师的情况中实现了几十个微办事。

假如你认为，“在一个只有 20 名工程师的团队中实现大年夜量的微办事的确是疯了！”那么，我赞成你的看法。但这种情况到处可见，这至少注解没有一种单一的架构模式合适所有的人。

我从三年前就开端写这篇博文了，时代，我无数次据说有中小型团队在微办事上陷入了挣扎，如今，我终于预备好揭橥了。我写这篇文章不是因为我憎恶微办事，而是因为我担心微办事正在成为新的默认选项。“你不消微办事吗？那么显然，你没把软件工程当回事。”人们不再做决定，他们只是想当然地认为微办事就是精确的选择，我认为这是有问题的。

范围决定一切

你的体系有若干人在开辟？五个？十个？五十？一百？照样一千？假如你的应用法度榜样、平台、应用法度榜样套件或其他任何器械，有跨越 500 人在开辟，那么我认为，你大年夜可以宁神地关掉落这篇博文并持续进步。你们的问题不是我们这里要评论辩论的问题。然则，假如你的应用法度榜样开辟工程师不足 100 人，那么请别走，我们聊一会儿。假如你的情况介于两者之间，那么这就要看实际情况了，也请不要走开，看看是否能发明一些有效的器械。

我职业生活的大年夜部分时光都办事于做小器械的公司。我在大年夜公司做过不少咨询工作，但我工作过的大年夜多半公司（或者是部分）都总共只有不到 100 名软件工程师。平日，这类工程组织有一个合营的存眷点：创建靠得住且稳定的体系，为营业交付价值??所有这些都须要借助重要的工程资本。

我所处理的问题都不是在谷歌、Facebook 或 Uber 那种范围上。在有些人看来，我似乎不知道本身在做什么，但就我小我而言，我认为这是一种资产。我熟悉的在这类机构中工作的人都很聪慧，但他们不是魔法师。

在一个大年夜型工程情况中工作，意味着用几乎无法估计的工程资本大年夜范围地解决问题。平日，他们有大年夜量的内部对象和库可以应用，这使他们可以或许编写大年夜范围的软件。与来自负年夜型工程情况背景的人交换得越多，我就越意识到，对于我们这些人来说，在一家始创企业或中小型企业中，与由 5 名、10 名甚至 50 名工程师构成的团队打交道是多么艰苦。

建议是要看高低文的

在如斯大年夜的范围下，沟通和调和是迄今为止最大年夜的挑衅之一，这是有事理的。削减团队之间的依附关系，或者让应用法度榜样扩大到每秒处理数百万个请求，范围这么大年夜，如许的需求完全值得付出如斯巨大年夜的工程开销。

然则，对于中小型企业，我经常听到如许的建议：

• 你须要从新构建一个更现代化的软件栈；
• 你应当应用扩大性更好的数据存储；
• 你的数据工程团队可以切换到 Kafka 吗？
• 你应当重构成一系列的微办事；
• 你须要用 Go、Rust 或其他高可扩大的说话进行重写。

平日，这些中小型团队发明，仅仅是知足特点要乞降供给支撑就很艰苦，更不消说推敲重写全部应用法度榜样了。这个建议合适吗？当然，在很少一些情况下可能是合适的。然则，有小企业和创业公司几回再三告诉我，他们从导师或参谋那边据说过这些。

是不是有的建议听着很熟悉？

当你须要应对一个小型团队和一个大年夜型应用法度榜样时，这可能会让人恐怖。你会感到到各类压力，调和特点宣布，跟着体系复杂性的增长开辟速度降低，你开端浏览很多文章，懂得若何将应用法度榜样分化成很多小块，从而赞助你降低复杂性，进步安排频率，简化开辟工作。

所以，你决定从只有 20 人的工程师团队里抽出一大年夜部分人，和少量的工程承包人员一路，在接下来的两年里从新筹划设计你的应用法度榜样，拆分你的体系，并构建出几十个微办事，可能还有一些微前端。在新构建的应用法度榜样上线后，你很快就会发明，安排确切越来越频繁。每个微办事的代码库都很小，揣摸也比较轻易。小型的更新和 Bug 修复可以更快地完成、测试和上线。你对本身说：“太棒了！这肯定会进步开辟团队的开辟速度！”

新挑衅

然则，接下来的几个月里，你开端碰到一些挑衅。

调和

每当须要进行较大年夜的更改时，你就会发明本身须要更新很多办事，并且要调和这些办事的宣布。当你向同事提起这件事时，他们老是说：“你弄错了。你的办事在逻辑上应当是分别的。”逻辑上分别，听起来很好，然则，你已经将体系拆分成很多小块，所以这些小块之间有很多依附关系。有人曾经说过，假如你的办事之间有一堆依附关系，那么你的拆分界线就有问题，然则，除了大年夜幅削减微办事的数量外，你并不知道其他的拆分办法。

数据一致性

你还会留意到，出现了一些数据一致性的新问题。看起来，应用法度榜样中一些以前在单个操作中完成的操作如今被拆分到几个不合的办事中，个中一个办事有一些写入掉败。同样，你的同事会告诉你，如许做是纰谬的，然则，将库存办事与订单办事拆分成零丁的办事似乎是精确的，是相符微办事的精力的。你告诉本身，“也许，我们须要着手设计跨所有这些操作的多阶段提交，或者我们须要构建对象来确保数据一致性。”再一次，这让你认为会明显增长一些工程复杂性和开销。

机能挑衅

机能问题也开端悄然出现??应用法度榜样中的一些页面须要调用六个办事来出现，加载时光很长。看起来，你须要为个中一些办事实现一个内部缓存层，以加快页面出现速度。简单的缓存层不会特别麻烦，只是须要再添加一层。

分布式跟踪

跟着时光的推移，你还会开端留意到，团队记录的处理某些 Bug 的时光明显增长。当你与团队评论辩论这个问题时，他们会说，某些问题在体系中很难定位。即使他们找到了，也很难再现它们，因为在工程师的机械上让多个办事进入同样的状况会是一项巨大年夜的挑衅。你默默地记了下来，你须要从整体上做个筹划，以便供给更好的体系级可跟踪性，如许，你就可以看到请求在全部体系中的流转过程。又多了一个待干事项。

反复

如今，设计和构建某些比较大年夜的特点须要花费更长的时光了。它们须要多个不合的办事来实现不合的功能，并在不合的数据存储中调和更改。你会发明，本身在不合的办事中复制了某些营业操作的逻辑，尽管你已经尽了最大年夜的尽力来包管每个办事在逻辑上是自力的，然则，你没法完全做到这一点。这给表带来了各类不合的风险，因为如今须要在办事之间保持营业逻辑的一致性。这是否意味着创建共享办事？手动保持逻辑同步？一声太息。

安然面

另一个关键点 CVE 呢？谢天谢地，你花时光在构建过程中引入了对象，使你可以或许知道哪个办事受了影响，因为为所有这些办事打补丁是异常艰苦的。手工审计每一个办事将是一项艰苦的义务。尽管如斯，因为一个 CVE 版本而安排 24 个办事是一种你没有真正推敲到的苦楚。

报表挑衅

假如将数据拆分到多个数据存储，一些查询就会变得异常复杂。是以，你聘请了一些参谋来赞助你构建一个专用的数据仓库并创建一个 ETL 过程，将其转换为让你的团队可以轻松生成申报的情势。这种设置供给了一些预期的长处，然则，如今每次进行重要的模式更改都必须同时保护 ETL 过程。又多了一件事要处理。

稳定性

最后，稳定性开端出现问题。个中一个办事有点不稳定，在拜访它时会导致体系的其他部分挂起。如今，你看到的不是抛出的缺点，而是请求静静地壅塞在那边，直到掉去响应。你知道，你的团队没有花足够的时光来确保办事之间优胜的容错才能，是以你意识到，可能须要使某些交互异步进行，这将进一步增长工程开销。

这异常令人沮丧，因为你的团队做了大年夜量的研究，并试图遵守所有可接收的模式来实现优胜的微办事，但这种改变带来的开销似乎并不值得。是的，单个办事的开辟和安排更轻易，然则，体系整体的复杂性高了很多。个中一些痛点可以经由过程额外的工程和一些更好的模式来缓解，然则，这就违背你最初的目标了??你应当进步速度，用更少的资本做更多的工作，而不是增长体系的工程开销。也许你在寻找灵丹妙药，并做出了一些草率的决定。

推敲下你面对什么问题？

也许你已经经历过一些如许的苦楚，并且深有感触，或者你转到了微办事，这对你的团队来说是一个巨大年夜的进步。在很多情况下，都有须要拆分出一些办事，但这完全取决于你面对的问题。

你的苦楚是为了有效地调和多个团队对同一个单体应用法度榜样所做的更改吗？你的苦楚是否无法经由过程其他策略（如基于骨干的开辟）来解决？你可能须要将其拆分，创建一些办事，并推敲微办事的意义地点。

你是否认为异常苦楚，因为你那个有着数百万行代码的宏大年夜单体须要做出一些就义并须要几天的时光来安排？你须要把它拆分并开辟成办事。

在你的应用法度榜样中，是否有大年夜量不相干的功能混淆在一个体系中？你可能须要一些办事，或者更小的应用法度榜样。

你那拥有 30 名工程师的团队是否深陷复杂性，开辟速度很低，而大年夜家都把原因归咎于单体应用法度榜样？你可能须要起首存眷一个更好的单体，然后再推敲迁徙到一些办事或一组较小的应用法度榜样。

正如 Simon Brown 曾经说过的那样：“假如你不克不及构建一个构造优胜的单体，你凭什么认为微办事就是谜底？”

复杂性被转移，但并未被清除

经由过程采取微办事或微前端，你是在转移复杂性，而不是清除复杂性。在一些处所，这种改变是值得的，然则，假如你的体系不敷大年夜，你的团队成员不敷多，而你面对的问题不是来自于调和大年夜量的开辟人员，那么将应用法度榜样拆分成很多小块可能会弊大年夜于利。

我并不是说，小型团队不该该把营业分化为大年夜小合理的办事，也不是说你不该该将那些功能过多的应用法度榜样拆分。但多年来，我看到太多的人提出如许的建议：把你的体系分化成很多很多的小块，就能神奇地解决你所有的问题。

你须要清楚地懂得你的体系所面对的挑衅，看看全部团队赓续增长的速度是否可以抵消构建分布式体系所带来的额外复杂性，然后再做出决定计划。假如你有证据证实这种弃取是值得的，那么根据你的营业范畴和团队范围来拆分出合理的办事。务须要异常存眷微办事的最佳实践，不然你最终将构建一个分布式的单体，这将是最糟糕的成果。

请留意，本文还没有涉及从单体迁徙到微办事的复杂性，不要低估了这种复杂性。这是一个须要异常谨慎的过程，并且应当增量地完成。

严格考察，谨慎行事

我建议你严格地考察衡量。推敲一下，你的团队是否会从中受益，然后从小范围实验入手，拆分出一些办事，看看后果若何。克服挑衅，认为有意义再持续进步。然后，反复上述过程。我知道，这可能与如今科技行业“快速行动，改变一切”的理念不符，但你最终会为本身采取了慎重的做法而高兴。

Netflix 是如何做体系监控的？