对于微服务，大多数开发者的态度都是鲜明的，要么热爱，要么痛恨，很少有人怀抱着比较“暧昧”的态度。所以，当 Uber 中的一个技术团队宣布，放弃微服务，转而使用宏服务，网友们就炸锅了。
1. Uber 团队放弃微服务，转为使用宏服务
不久之前，Uber 支付体验平台的工程经理 Gergely Orosz 发布推文表示我们的架构方向已经发生了变化。
声明一下，在 Uber，我们正将许多微服务转移到 @copyconstruct 所称的宏服务（大小适中的服务）。
确切地说，B/C 测试和维护成千上万的微服务不仅很难——它可能会带来更多的长期麻烦，而不是解决短期问题。
微服务确实可以帮助团队在早期快速推进。
等你意识到服务越少越好时，已为时已晚。你需要解决很多服务的“困难”部分。
我们在不断增加更多的服务，但也在停止使用服务，并且会更慎重的思考新的服务。
@GergelyOrosz:
是的，我们正在这样做，这个方法触及到了很多微服务的痛点。每项服务都需要支持租户，包括很多无状态的租户。
我们还需要对现有的服务来进行改进，而针对新的服务，我们只需从头开始添加即可。
@GergelyOrosz:
微服务之前能够帮助企业（并且现在仍然帮助）快速行动、实现自治、便于实验。
一个领域越成熟，“大小适中的的服务”就越有意义，就越容易论证。
@GergelyOrosz:
我可能早就该发一篇关于微服务缺点的帖子了。有关微服务幸福的蜜月期话题很多，但人们却很少谈及后来与微服务如何发生激烈的争吵，然后又和好，但又改变了一些事情。就只为了一劳永逸。
Gregdoesit:
我写的那条推文，已经流传开来。一条推文最多只能发 280 个字符，写不了什么太多的东西，而且在 Twitter 上一旦发布推文就无法编辑，因此，无法再修改补充新的东西，所以我在论坛中详细说明一下。
以下内容只代表我自己的经验，代表我所在的团队，而不代表整个 Uber。Uber 有数百支团队，其中 95% 我都不认识。而且，团队有自治权，可以决定自己如何做、做什么，所以我也不能一概而论。
Uber 目前仍然拥有成千上万的微服务。上一次我查看的时候，大概有 4000 个。而且，需要明确的是，这一数字还在继续增长。
我在 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/ 优步那样的微服务。
宏服务？
宏服务：
不是整体式系统
每 3 个团队最多只有 20 名开发人员在开发服务（5 个披萨规则？）
是否拥有 / 需要整体式代码仓库（monorepo）不好说。服务 / 代码仓库数量较少，依赖项管理就变得容易得多（不过仍并非易事）
更好的可观察性和调试
2. 网友评论炸锅了，有人批评有人赞扬
世界会因为我们有了一个类似于宏服务的新品牌术语，而为之疯狂。
宏服务和我们几十年来所知道的普通服务有什么不同？几乎没有人在乎这个问题。名字是时代的产物，大多数人都在为“微服务的终结”而欢呼，认为这才是微服务的最终归宿。
@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 成熟、学习、重构是一件好事，这并非是承认失败，甚至是早期决策失误的证据。
坦率来讲，我们对如何构建软件几乎一无所知。我相信，微服务之所以能够迅速发展，部分原因在于它为程序员提供了一个关于如何构建程序的连贯理论。
每个人都给出自己的微服务替代方案，但目前并没有达成共识，我们没有系统的理论。希望这次Uber的尝试，能够给到我们更多的启发。
软件真是一团糟啊。
