也许在某个丛林深处的某个地方，有一个未被发现的部落还没有对微服务下定决心，但我很怀疑这一说法。因为人们对微服务的态度是非爱即恨。这两者之间并没有什么太多的中间地带。

所以，当 Uber 这样的公司的一支团队宣布从微服务转向其他东西时，这意味着什么？什么？宏服务。但我们会讲这个问题的。想想看，你对 Uber 这家公司是怎么看的？但从软件的角度来看，Uber 一直是个“好公民”。

Uber 支付体验平台的工程经理 Gergely Orosz 在一条推文中表示，架构方向已发生变化：

@GergelyOrosz:

声明一下，在 Uber，我们正将许多微服务转移到 @copyconstruct 所称的宏服务（大小适中的服务）。

确切地说，B/C 测试和维护成千上万的微服务不仅很难——它可能会带来更多的长期麻烦，而不是解决短期问题。

微服务确实可以帮助团队在早期快速推进。
等你意识到服务越少越好时，已为时已晚。你需要解决很多服务的“困难”部分。
我们不断增加更多的服务，但也有退下来的，并在新的服务中投入更多的考虑。

@GergelyOrosz:

是的，我们正在这样做，这个方法触及到了很多微服务的痛点。

每项服务都需要支持租户，包括很多无状态的租户。

我们还需要对现有的服务来进行这方面的大部分工作。对于新的服务，我们只需从头开始添加它。

@GergelyOrosz:

1.微服务帮助（并且现在仍然帮助）快速推进、自治和实验。

2.一个领域越成熟，“大小适中的的服务”就越有意义/越容易推理。

看来以后我得用更长的篇幅将我的想法写出来。

@GergelyOrosz:

我可能早就该发一篇关于微服务缺点的帖子了。有关幸福的蜜月期话题很多，但人们却很少谈及后来与微服务如何发生激烈的争吵，然后又和好，但又改变了一些事情。就只为了一劳永逸。

Gregdoesit:

我写的那条推文，已经流传开来。一条推文最多只能发 280 个字符，写不了什么太多的东西，而且在 Twitter 上一旦发布推文就无法编辑，因此，没有多少东西可以让你回去进一步澄清。所以，让我在这个论坛上详细地说明一下。

我只代表我自己的经验，代表我的团队，而不代表整个 Uber。哎呀，我们 Uber 有数百支团队，其中 95% 我都不认识。而且，团队有自治权，可以决定自己如何做、做什么（包括部分或完全遵循指导原则或或完全忽视指导原则）——即使我想这样做，我也不能一概而论。
Uber 已经并且仍然拥有成千上万的微服务。上一次我查看的时候，大概有 4000 个。（https://eng.uber.com/optimizing-observability/）。而且，需要明确的是，这一数字还在（并将继续）增长。
我在 Uber 工作快四年了，看到了我所在的组织/领域（支付）的一些趋势。在过去，我们会构建一个微服务，它可以完成一件很小的事。我们有一批由一个人构建并维护的小型服务。这对于自治性、迭代速度、学习和使 DevOps 成为一个无需动脑的事情都是极好的。你可以随时启动一项服务，但你必须随叫随到。
现在，随着我的领域逐渐成熟，展望未来变得更加容易，随着我们创建新的平台，我们正在对新的服务进行更深思熟虑的规划。这些服务并不仅仅只做一件事：它们服务于一项业务功能。它们是由一个团队（5~10 名工程师）构建并维护的。与一些早期微服务公司相比，它们更具弹性，在开发和维护方面得到的投资要多得多。Cindy 调用了这些宏服务，我说我们也在做类似的事情。我们所做的事情唯一的区别是，一个服务是一个团队的，而不是多个团队的。
虽然很多微服务都是这样发展的，但坦率地说，大部分微服务还是保持了原样。成千上万的微服务带来了很多需要解决的问题。监控、测试、CI/CD、SLA、所有版本的库（安全、时区问题）等等。一直以来，我们做了一些很好的举措，并分享一些行之有效的方法，并在问题出现时，将我们用来解决问题的一些工具进行开源。比如用多租户方法测试微服务、跨服务的分布式跟踪。所有这些都是一笔巨大的投资。只有在你准备好进行这项投资的时候，才能进行规模化的微服务。

所以，Uber 并不是像我看到很多人解读的那样，没有使用微服务。Uber 甚至都不会减少微服务的使用。因此，当我说 “我们要迁移” 的时候，这一措辞并不很确切。在我的团队和组织中，新的微服务的构建都是经过深思熟虑才构建的。这些新的微服务比那些早期的、小型的、专注的微服务“更大”。

微服务在 Uber 的很多方面都运行得很好，并且在其他领域也不断地提供帮助。当然，问题是存在的，但你可以一边处理问题，一边解决问题。例如，有数千名开发人员的一个单体，有数千名开发人员的 SOA，或者有数千名开发人员的{你管它叫什么名字都可以}。随着业务的发展，服务的数量整体上还是在增长的：虽然在一些组织中，比如我的组织，它们的服务数量处于同一水平，甚至略有下降（尽管这不是目标本身）。但并不是所有的微服务都是平等的。关键的微服务看起来不太像经典的微服务，或者至少是我几年前所说的那种微服务。

另外说一下，每个人对 “微服务” 这一名字的理解都不一样。我将会撰写一篇帖子，总结我在微服务领域的经验。

译注：SOA（Service-oriented arhitecture），面向服务的架构，是构造分布式计算的应用进程的方法。它将应用进程功能作为服务发送给最终用户或者其他服务。它采用开放标准、与软件资源进行交互并采用表示的标准方式。

Gregdoesit:

Uber 在 2015 年从一个巨型企业转变成了一个 SOA。这个 SOA 遵循了一个基于微服务的架构。而我们也一直在分享我们在这一路上所学到的东西：构建微服务通常需要的步骤，用多租户的方法解决测试问题，或者我们如何以及为何使用分布式跟踪等等。我们还开源了一些工具，比如 Jaeger，它和 Kubernetes、Prometheus 都是云原生基金会（Cloud Native Foundation）的毕业项目的一部分……所有这些都可以作为灵感：但最后，你需要在自己的环境中做出你认为最有效的决定。任何抄袭 Google、Uber/SHopify、Stack Overflow 或其他公司的人，当他们的设置完全都不一样时，都会很失望的。

@copyconstruct:

微服务很难。
构建可靠、可测试的微服务比大多数人想象的要难得多。
有效地测试微服务需要大量的工具和远见卓识。
Netflix/Uber 风格的微服务并不是许多（大多数？）组织所需要的。
宏服务？

宏服务：

不是单体应用。
服务的开发只有不超过 20 个开发人员/3 个团队（五个披萨原则？）
可能有，也可能没有，或者不需要 monorepo（单体仓库）。服务/仓库越少，依赖项管理就越容易（尽管仍然很不平凡）。
更好的可观测性、调试能力

世界会因为我们有了一个新的半正式品牌术语，比如宏服务，全世界都会为之疯狂。

宏服务和我们几十年来所知道的普通服务有什么不同？没人在乎这个问题。名称是他们时代的产物。名称只是一个讨论的脚手架。这不是魔术。名称并不是一个什么秘密的象征，必须保密，以免黑魔法师把你变成他们的肉食傀儡。名称只不过是一个聚集地，一个标记，帮助我们找到方向。深吸一口气，让任何因名称而产生的烦躁情绪消失吧！

正如你可以想象的那样，人们的反应非常热烈。他们当中的大部分人都在欣喜若狂地颂扬微服务这一祸害的终结，认为微服务这样的结局是 “理所当然” 的。微服务一直以来都是个坏主意，这是反对派的普遍共识。

@sandofsky:

2016 年的 Uber：“我们有成千上万的微服务。”

每个人都说：“这听起来很疯狂。”

2020 年的 Uber：“事实证明，这太疯狂了。”

@dhh:

过度采用微服务给人们带来的痛苦是巨大的。

除了 Majestic Monolith 之外，还应该有人写下 Citadel 的模式：单一 Majestic Monolith 抓住了大部分的应用程序，少数辅助前哨应用程序满足高度专业化和多样化的需求。

但也不全是负面的。

@saikishore001:

我们发现 Bayer 在微服务方面取得了相当大的成功。对我们来说，唯一一个大型的单体应用就是一场噩梦……现在，使用微服务架构就好多了。

@Carnage4Life:

Uber 在 2016 年就大力支持微服务，但现在却放弃了，这其中有两点重要的教训：

大公司在规模化上所做的权衡，可能并不适合你的初创公司。
大公司也会做出糟糕的架构选择，所以要小心“船货崇拜”（Cargo cult）。

译注： 船货崇拜（Cargo cult）是一种宗教形式，特别出现于一些与世隔绝的原住民中。当货物崇拜者看见外来的先进科技物品，便会将之当作神祇般崇拜。最为知名的货物崇拜，是瓦努阿图塔纳岛的 “约翰布鲁姆教”（John Frum Movement）。第二次世界大战太平洋战争时，美军于塔纳岛创建一临时基地。当时岛上的原住民看见美军于 “大铁船”（军舰）内出来，皆觉得十分惊讶。此外，他们也看到，有一些 “大铁鸟”（军用飞机）运送穿着美军军服的人及许多物资。这些原住民看见这种情况均感到很惊讶，并觉得这些 “大铁船” 及 “大铁鸟” 十分厉害。加上美军也提供部份物资给原住民，而这些物资对原住民来说十分有用，结果令这些原住民将美军当作神。此处暗指那些大公司此前也没有见过或者应用过微服务架构。

@adamzethraeus:

Uber 真的只是为了避免协调成本，才会这么做。大致来说，Uber 明确鼓励不考虑重用或整合的构建。例如，Uber 的中国团队复制了一堆三级架构，以更快的速度推进。（这在短期内很有效！）

对于架构炒作周期，也有一个值得考虑的经济学论据：

@ridingwithrails：

在互联网崩溃和经济衰退期间，单体应用总是赢家。人们意识到，十个使用十种不同系统的团队是很难保持的……再见，Felicia！

@sandofsky：

每一次科技谈论都应该披露他们的风险投资资金消耗率。当你把别人的钱花在自己的问题上时，你什么都能逃过一劫。

对微服务行业来说，对微服务可能衰落的幸灾乐祸并不是什么好兆头。我们需要的是集中精力把事情做正确，而不是做对。我知道，正确是学霸竞争的核心。

改变是我们进步的方式，在改变过程中人为制造摩擦对谁都没有帮助。Uber 成熟、学习、重构是一件好事。这并非承认失败，甚至是早期决策失误的证据。当你有了很多钱，并且有了统治世界的宏伟蓝图，微服务就有了很大的意义。当你的成长阶段走到尽头时，你也可以采取紧缩和巩固的措施。当实际情况发生变化时，你会怎么做？

面对现实吧，我们对如何构建软件几乎一无所知。我相信，微服务之所以能够迅速发展，部分原因在于它至少为程序员提供了一个关于如何构建程序的连贯理论。

每个人都给出了自己个人爱好的替代微服务，但并没有达成共识，我们没有系统的理论。见证整个讨论，作为证据吧。

软件真是一团糟啊。

原文链接：

http://highscalability.com/blog/2020/4/8/one-team-at-uber-is-moving-from-microservices-to-macroservic.html

创作场景

Uber 一团队正从微服务转向宏服务