作者 | 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 是一家从事 SEO 优化的公司，其平台于 2012 年在 Python/Django 技术栈上建立。

2016 年头，整个 Botify 平台都是通过 Django 应用法式的负载平衡集群提供服务。2016 年年底，Botify 工程团队想让工程师和产物司理拥有更多的局部所有权，从而可以快速轻松地将他们的产物和技术栈投入使用。为此，他们决议将他们的 Django 应用法式拆分为微服务。

其时，他们的团队约莫为 15 人。他们从身份验证和授权入手实现第一个微服务，将 Django 应用法式当前的一部门功效转移到微服务中。微服务模块也需要和其他的 Django/Python 单体模块举行通讯。

Botify 的平台是一个企业级 B2B 服务，资助网络上最大的网站改善他们的 SEO，主要挑战在于对客户数据的分析。处置惩罚用户相关数据的微服务架构旨在服务于高流量的 B2C 平台，而 Botify 的挑战在于动态地聚合数以 GB 的 SEO 数据，使其在几秒钟内可用。

对约莫一万名客户的元数据以毫秒为单元举行响应，这项任务不需要高度可伸缩的微服务架构。恰恰相反，Botify 的后端到后端通信减慢了这些简朴的检索历程，花费了更多的时间。鉴于天天都要在 JavaScript 身份验证后端和 Django 模块之间频繁地往返切换，权衡架构的优缺点以及潜在的迁移成本后，他们做出了斗胆的选择，将身份验证后端重新加入到 Django 单体中。

Botify 于今年 2 月停用了微服务。其团队卖力人 David Wobrock 表现：“每一种技术都自有其用途，但我们相信，要在正确的时间选择正确的解决方案来构建我们的产物。如今，我们不必往返切换了，也不用维护两个后端了，显然，我们已经从中获益。““我们公司也从单体转向了微服务，但最后在二者之间找到了一个平衡点。

”在 2017 年的时候，办公治理软件公司 Managed by Q 的技术团队或许有 20 名工程师，应用法式是一个部署在 ECS 上的 Django 单体。为了遇上现代化开发实践的程序，他们开始转向了微服务架构。但随着微服务数量的增长，事情不像之前那么顺利了。每多一个新服务，就会增加一些基础设施。

好比，一个 ECS 服务、一个 Postgres 实例或一个 RabbitMQ 实例。CI/CD 的设置也会增加，还需要举行第三方服务（好比 Rollbar/Sentry）设置。依赖也需要更新，而且需要更新依赖的地方越来越多。

基础设施团队在项目上花了许多时间，为每一个服务重复着枯燥无味的事情。而且小型的服务容易被人忽略，在运行起来之后，基本上会被搁在一边，最后就会过时。如果服务界限没有搞清楚，还会显著降低功效的开发速度，这是微服务的一个很大的风险点。

开发一个跨多个服务的功效需要做更多的事情，而重构一个跨多个服务的功效是一个噩梦。如果服务界限很清晰，大部门项目只会影响到一个服务。可是，对于初创公司来说，它们的生长偏向是不行预测的。一个产物的两个部门在一开始可能是完全独立的，但一年之后可能会变得精密耦合起来。

所以，要完全清晰地界说服务界限不是件容易的事。最后，在转向微服务两年之后，他们开始合并微服务。一些微服务被合到了单体中，其他的则合并成较大的服务。在一年中总共移除了 9 个微服务。

巨细合理的服务负担着相当大的责任，大多数功效开发都可以在单个服务中完成。不能固然地认为微服务就是正确的选择。微服务已经被这代人当成银弹，不外，上面提到的这些企业已开始用更挑剔的眼光来看待它。这些例子中，他们认为转向微服务的工程开销太大，不值得。

而这样的案例另有许多。每个系统实现都市有一些错误的选择。

可是，他们所犯的最大的错误与他们的微服务实现无关。他们所犯的最大错误是在只有 20 名工程师的情况中实现了几十个微服务。如果你认为，“在一个只有 20 名工程师的团队中实现大量的微服务简直是疯了！”那么，我同意你的看法。

但这种情况随处可见，这至少讲明没有一种单一的架构模式适合所有的人。我从三年前就开始写这篇博文了，期间，我无数次听说有中小型团队在微服务上陷入了挣扎，现在，我终于准备好揭晓了。我写这篇文章不是因为我讨厌微服务，而是因为我担忧微服务正在成为新的默认选项。“你不用微服务吗？那么显然，你没把软件工程当回事。

”人们不再做决议，他们只是想固然地认为微服务就是正确的选择，我认为这是有问题的。1规模决议一切你的系统有几多人在开发？五个？十个？五十？一百？还是一千？如果你的应用法式、平台、应用法式套件或其他任何工具，有凌驾 500 人在开发，那么我认为，你大可以放心地关掉这篇博文并继续前进。你们的问题不是我们这里要讨论的问题。

可是，如果你的应用法式开发工程师不足 100 人，那么请别走，我们聊一会儿。如果你的情况介于两者之间，那么这就要看实际情况了，也请不要走开，看看是否能发现一些有用的工具。

我职业生涯的大部门时间都服务于做小工具的公司。我在大公司做过不少咨询事情，但我事情过的大多数公司（或者是部门）都总共只有不到 100 名软件工程师。通常，这类工程组织有一个配合的关注点：建立可靠且稳定的系统，为业务交付价值——所有这些都需要借助紧张的工程资源。

我所处置惩罚的问题都不是在谷歌、Facebook 或 Uber 那种规模上。在有些人看来，我似乎不知道自己在做什么，但就我小我私家而言，我认为这是一种资产。我认识的在这类机构中事情的人都很智慧，但他们不是邪术师。

在一个大型工程情况中事情，意味着用险些无法估量的工程资源大规模地解决问题。通常，他们有大量的内部工具和库可以使用，这使他们能够编写大规模的软件。

与来自大型工程情况配景的人交流得越多，我就越意识到，对于我们这些人来说，在一家初创企业或中小型企业中，与由 5 名、10 名甚至 50 名工程师组成的团队打交道是何等难题。2建议是要看上下文的在如此大的规模下，相同和协调是迄今为止最大的挑战之一，这是有原理的。淘汰团队之间的依赖关系，或者让应用法式扩展到每秒处置惩罚数百万个请求，规模这么大，这样的需求完全值得支付如此庞大的工程开销。可是，对于中小型企业，我经常听到这样的建议：你需要重新构建一个更现代化的软件栈；你应该使用扩展性更好的数据存储；你的数据工程团队可以切换到 Kafka 吗？你应该重组成一系列的微服务；你需要用 Go、Rust 或其他高可扩展的语言举行重写。

通常，这些中小型团队发现，仅仅是满足特性请求和提供支持就很难题，更不用说思量重写整个应用法式了。这个建议合适吗？固然，在很少一些情况下可能是合适的。可是，有小企业和创业公司一再告诉我，他们从导师或照料那里听说过这些。3是不是有的建议听着很熟悉？当你需要应对一个小型团队和一个大型应用法式时，这可能会让人胆怯。

你会感受到种种压力，协调特性公布，随着系统庞大性的增长开发速度下降，你开始阅读许多文章，相识如何将应用法式剖析成许多小块，从而资助你降低庞大性，提高部署频率，简化开发事情。所以，你决议从只有 20 人的工程师团队里抽出一大部门人，和少量的工程承包人员一起，在接下来的两年里重新计划设计你的应用法式，拆分你的系统，并构建出几十个微服务，可能另有一些微前端。在新构建的应用法式上线后，你很快就会发现，部署确实越来越频繁。

每个微服务的代码库都很小，推断也比力容易。小型的更新和 Bug 修复可以更快地完成、测试和上线。

你对自己说：“太棒了！这肯定会提高开发团队的开发速度！”新挑战可是，接下来的几个月里，你开始遇到一些挑战。协调每当需要举行较大的更改时，你就会发现自己需要更新许多服务，而且要协调这些服务的公布。当你向同事提起这件事时，他们总是说：“你弄错了。

你的服务在逻辑上应该是分散的。”逻辑上分散，听起来很好，可是，你已经将系统拆分成许多小块，所以这些小块之间有许多依赖关系。有人曾经说过，如果你的服务之间有一堆依赖关系，那么你的拆分界限就有问题，可是，除了大幅淘汰微服务的数量外，你并不知道其他的拆分方法。数据一致性你还会注意到，泛起了一些数据一致性的新问题。

看起来，应用法式中一些已往在单个操作中完成的操作现在被拆分到几个差别的服务中，其中一个服务有一些写入失败。同样，你的同事会告诉你，这样做是差池的，可是，将库存服务与订单服务拆分成单独的服务似乎是正确的，是切合微服务的精神的。你告诉自己，“也许，我们需要着手设计跨所有这些操作的多阶段提交，或者我们需要构建工具来确保数据一致性。”再一次，这让你以为会显着增加一些工程庞大性和开销。

性能挑战性能问题也开始悄然泛起——应用法式中的一些页面需要挪用六个服务来出现，加载时间很长。看起来，你需要为其中一些服务实现一个内部缓存层，以加速页面出现速度。

简朴的缓存层不会特别贫苦，只是需要再添加一层。漫衍式跟踪随着时间的推移，你还会开始注意到，团队记载的处置惩罚某些 Bug 的时间显著增加。

当你与团队讨论这个问题时，他们会说，某些问题在系统中很难定位。纵然他们找到了，也很难再现它们，因为在工程师的机械上让多个服务进入同样的状态会是一项庞大的挑战。你默默地记了下来，你需要从整体上做个计划，以便提供更好的系统级可跟踪性，这样，你就可以看到请求在整个系统中的流转历程。又多了一个待服务项。

重复现在，设计和构建某些比力大的特性需要花费更长的时间了。它们需要多个差别的服务来实现差别的功效，并在差别的数据存储中协调更改。你会发现，自己在差别的服务中复制了某些业务操作的逻辑，只管你已经尽了最大的努力来保证每个服务在逻辑上是独立的，可是，你没法完全做到这一点。

这给表带来了种种差别的风险，因为现在需要在服务之间保持业务逻辑的一致性。这是否意味着建立共享服务？手动保持逻辑同步？一声叹息。宁静面另一个关键点 CVE 呢？谢天谢地，你花时间在构建历程中引入了工具，使你能够知道哪个服务受了影响，因为为所有这些服务打补丁是很是难题的。手工审计每一个服务将是一项困难的任务。

只管如此，因为一个 CVE 版本而部署 24 个服务是一种你没有真正思量到的痛苦。报表挑战如果将数据拆分到多个数据存储，一些查询就会变得很是庞大。

因此，你聘请了一些照料来资助你构建一个专用的数据堆栈并建立一个 ETL 历程，将其转换为让你的团队可以轻松生成陈诉的形式。这种设置提供了一些预期的优点，可是，现在每次举行重要的模式更改都必须同时维护 ETL 历程。又多了一件事要处置惩罚。

稳定性最后，稳定性开始泛起问题。其中一个服务有点不稳定，在会见它时会导致系统的其他部门挂起。现在，你看到的不是抛出的错误，而是请求悄悄地阻塞在那里，直到失去响应。

你知道，你的团队没有花足够的时间来确保服务之间良好的容错能力，因此你意识到，可能需要使某些交互异步举行，这将进一步增加工程开销。这很是令人沮丧，因为你的团队做了大量的研究，并试图遵循所有可接受的模式来实现良好的微服务，但这种转变带来的开销似乎并不值得。是的，单个服务的开发和部署更容易，可是，系统整体的庞大性高了许多。

其中一些痛点可以通过分外的工程和一些更好的模式来缓解，可是，这就违背你最初的目的了——你应该提高速度，用更少的资源做更多的事情，而不是增加系统的工程开销。也许你在寻找灵丹妙药，并做出了一些轻率的决议。

4思量下你面临什么问题？也许你已经履历过一些这样的痛苦，而且深有感慨，或者你转到了微服务，这对你的团队来说是一个庞大的进步。在许多情况下，都有须要拆分出一些服务，但这完全取决于你面临的问题。你的痛苦是为了有效地协调多个团队对同一个单体应用法式所做的更改吗？你的痛苦是否无法通过其他计谋（如基于主干的开发）来解决？你可能需要将其拆分，建立一些服务，并思量微服务的意义所在。

你是否感应很是痛苦，因为你谁人有着数百万行代码的庞大单体需要做出一些牺牲并需要几天的时间来部署？你需要把它拆分并开发成服务。在你的应用法式中，是否有大量不相关的功效混杂在一个系统中？你可能需要一些服务，或者更小的应用法式。你那拥有 30 名工程师的团队是否深陷庞大性，开发速度很低，而大家都把原因归罪于单体应用法式？你可能需要首先关注一个更好的单体，然后再思量迁移到一些服务或一组较小的应用法式。

正如 Simon Brown 曾经说过的那样：“如果你不能构建一个结构良好的单体，你凭什么认为微服务就是谜底？”5庞大性被转移，但并未被消除通过接纳微服务或微前端，你是在转移庞大性，而不是消除庞大性。在一些地方，这种转变是值得的，可是，如果你的系统不够大，你的团队成员不够多，而你面临的问题不是来自于协调大量的开发人员，那么将应用法式拆分成许多小块可能会弊大于利。我并不是说，小型团队不应该把业务剖析为巨细合理的服务，也不是说你不应该将那些功效过多的应用法式拆分。但多年来，我看到太多的人提出这样的建议：把你的系统剖析成许多许多的小块，就能神奇地解决你所有的问题。

你需要清楚地相识你的系统所面临的挑战，看看整个团队不停增加的速度是否可以抵消构建漫衍式系统所带来的分外庞大性，然后再做出决议。如果你有证据证明这种取舍是值得的，那么凭据你的业务领域和团队规模来拆分出合理的服务。务须要很是关注微服务的最佳实践，否则你最终将构建一个漫衍式的单体，这将是最糟糕的效果。请注意，本文还没有涉及从单体迁移到微服务的庞大性，不要低估了这种庞大性。

这是一个需要很是审慎的历程，而且应该增量地完成。6严格考察，审慎行事我建议你严格地考察权衡。

思量一下，你的团队是否会从中受益，然后从小规模实验入手，拆分出一些服务，看看效果如何。克服挑战，以为有意义再继续前进。然后，重复上述历程。我知道，这可能与如今科技行业“快速行动，改变一切”的理念不符，但你最终会为自己接纳了慎重的做法而兴奋。