为什么 Uber 一个团队直接放弃微服务，改用宏服务？

点击“开发者技术前线”，选择“星标?”

在看|星标|留言,  真爱

人们要么爱微服务，要么恨微服务，没多少人既爱又恨微服务。

因此，当优步（Uber）这种公司的哪怕一个团队宣布从微服务改用宏服务，这颇能说明问题。想想你对优步公司有什么看法，不过从软件角度来看，优步一向是良好的企业公民。

优步支付体验平台的工程经理Gergely Orosz在一条推文中暗示了架构方向发生变化：

@GergelyOrosz：郑重申明一下，我们优步正将许多微服务转移到@Cindy Sridharan 所说的宏服务（macroservice，即大小适中的服务）。

对成千上万个微服务进行测试和维护不仅很棘手，长期造成的麻烦比短期解决的麻烦还要多。

微服务确实可以帮助团队尽早迅速行动。

等到你意识到数量更少的服务会很好时，已为时已晚。你需要解决许多服务的“棘手”部分。

我们不断添加更多的服务，但也在停止使用服务，并更慎重地考虑新服务。

@GergelyOrosz：

是的，我们正在这么做，这种方法触及许多微服务的痛点。

每个服务都需要支持租约，包括许多无状态的租约。

我们还需要针对现有服务改进这方面的许多工作。至于新服务，我们一开始就添加该方法。

@GergelyOrosz：

1. 微服务曾经帮助（仍会帮助）快速行动、保持自主并便于试验。

2. 某个方面变得越成熟，使用“大小适中的服务”就越明智/越容易论证。

稍后，我会以更长的篇幅总结一下想法。

@GergelyOrosz：

我可能早该写一篇文章来介绍深有感触的微服务缺点了。微服务方面关于幸福的蜜月期谈得够多了，但人们很少谈论他们后来如何与微服务打得不可开交，随后和好但改变了几个方面。

Gregdoesit：

我发了那条流传甚广的推特。短短280个字符写不下太多的内容，而Twitter的政策短期内又不会变，所以好多东西你没法回过头去阐明。不妨容我在此作一番更详细的介绍。

1. 以下内容仅代表我的经验，代表我所在的团队，而不代表优步的所有团队。我们优步有数百支团队，其中95%我都不认识。这些团队具有自主权，可以决定自己怎么做、做什么（包括部分或完全遵循准则或忽视准则）——就算我想，也没法发表总括性的说法。

2. 优步现在仍有数千项微服务。我上次清点了一下有约4000项微服务 （https://eng.uber.com/optimizing-observability/）。有必要明确一下：这个数字在增加，而且会不断增加。

3. 我在优步工作了近4年，看到我的组织/部门（支付）出现了一些趋势。想当初，我们会启动一个微服务，它就完成一项小小的任务。我们专门有一个人构建和维护一批小服务。这适合于自主、迭代速度和学习，使得DevOps成为不二的选择。你任何时候都可以启动一个服务，但你得为此而随叫随到。

4. 现在，随着我所在部门日趋成熟，更倾向于从长计议，我们在构建新平台时，在新服务方面做的规划要周到得多。这些服务不仅仅只做一件事：服务于一个业务职能部门。它们由一个团队（5至10位工程师）构建和维护。与那些早期的微服务相比，它们更具弹性，并且在开发和维护方面获得多得多的投入。Cindy称这些服务为宏服务，我说我们在做类似的事情。我们之间所做的唯一区别就是，服务归一个团队拥有，而不是归多个团队拥有。

5. 坦率地说，虽然许多微服务在不断发展，但大多数微服务保持原状。成千上万的微服务带来了许多需要解决的问题。监控、测试、持续集成/持续交付（CI/CD）、服务级别协议（SLA）、跨所有微服务的库版本（安全和时区问题），不一而足。我们在不断采取好的做法——共享切实可行的微服务，并开源我们为处理新出现的问题而构建的一些工具。比如使用多租户方法测试微服务一样，以及跨诸多服务的分布式跟踪。这一切都是大笔投入。如果你准备进行这种投入，才可以搞大规模微服务。

因此，不，优步不会像我见到许多人解读的那样对微服务说不。它甚至不会因此少用微服务。我说“我们在搬迁”，这么说其实措辞并不准确。我的团队和组织在更深思熟虑地创建新的微服务。与一些早期小型专注的微服务相比，它们是“更庞大”的服务。

从许多方面来看，微服务在优步运作良好，并在其他部门继续提供帮助。当然也有问题，你边摸索边处理问题。这就跟成千上万开发人员支持的整体式系统、成千上万开发人员支持的面向服务对象（SOA）或成千上万开发人员支持的其他任何系统一样。总体上，随着公司发展，服务的数量仍在增长——不过在一些组织（比如我所在组织），数量保持稳定，或甚至减少了一点（不过这不是目标本身）。但是所有微服务不再是一个样。关键的服务看起来不太像你的经典微服务（或至少多年前我所说的微服务）。

另一方面，每个人对“微服务”这个名词的解读有所不同。我会撰写一篇文章，总结我在使用大规模微服务方面的感受。

Gregdoesit：

优步在2015年从整体式系统改用SOA。这种SOA遵循基于微服务的架构。而我们一直在分享我们一路所学到的东西：构建微服务通常需要采取的步骤，采用多租户方法解决测试问题，以及我们如何以及为何使用分布式跟踪。我们还开源了自己的一些工具，比如Jaeger（它是云原生基金会的众多毕业项目的一部分），与Kubernetes和Prometheus一样。所有这些都给人带来灵感和启发：但是到头来，你需要在自己的环境中做出你认为最有效的决定。谁要是明明连系统环境都不相似，就盲目照搬照抄谷歌、优步、Uber、Shopify、Stack Overflow或其他公司，只会大失所望。

@copyconstruct：

•微服务很棘手。

•构建可靠且可测试的微服务比大多数人认为的要难得多。

•有效地*测试*微服务需要大量的工具和深谋远虑。

•许多（大多数？）组织不需要Netflix/优步那样的微服务。

•宏服务？

宏服务：

•不是整体式系统

•每3个团队最多只有20名开发人员在开发服务（5个披萨规则？）

•是否拥有/需要整体式代码仓库（monorepo）不好说。服务/代码仓库数量较少，依赖项管理就变得容易得多（不过仍并非易事）

•更好的可观察性和调试

当然，如果我们有一个像宏服务这样新的半品牌术语，世界会为之疯狂。

宏服务与我们几十年来所熟知的老式服务有何不同？谁在乎。名称只不过其时代的产物。名称只是讨论的基础而已。这又不是什么魔法。名称不是必须严加保管的秘密符号，以免魔术师将你变成他们手中的道具。名称只是个聚集地，只是个标记，帮助我们找到出路。叫什么，无关紧要。

你可能也料到了，反响热烈。大多数人热情赞颂微服务这个祸害终于到头了。持异议者的普遍共识就是，微服务向来是个坏主意。

@sandofsky：

优步在2016年声称：“我们有数千个微服务。”

所有人：“这听起来很疯狂。”

优步在2020年声称：“结果证明这太疯狂了。”

@dhh：

过分热情地采用微服务带来了巨大的痛苦。

除了Majestic Monolith外，有人还应详细记述The Citadel的模式：单单一个Majestic Monolith占据了应用程序的大部分，几个辅助性的前哨应用程序用于满足高度专业化和多样化的需求。

但评论不全是负面的。

@ saikishore001：

我们拜耳使用微服务取得了相当大的成功。对于我们来说，维护一个庞大的整体式系统如同噩梦……现在，采用了微服务架构，情况好多了。

@ Carnage4Life：

优步在2016年大力倡导微服务，但随后却迁离微服务，这给了世人两大经验教训

1. 大公司在大规模环境下所做的取舍可能不适合你这家初创公司。

2. 大公司也会做出糟糕的架构选择，所以要提防货物崇拜（cargo culting）。

@adam_zethraeus：

优步这么做其实完全是为了避免协调成本。大体来说，明确鼓励在无须关注重用或合并的情况下构建，比如优步的中国团队复制了一批三级架构，以加快行动速度。（短期内奏效！）

这种架构炒作周期有一个经济层面的观点也值得考虑：

@ridingwithrails

在互联网崩溃和衰退期间，整体式系统总是胜出。人们意识到，很难保持使用10种不同系统的10个团队……

@sandofsky

每次技术讨论都应该披露风险资金的烧钱速度。如果砸别人的钱来处理你的问题，你几乎可以为所欲为而安然无事。

为微服务可能崩溃而欣喜对业界来说不是该有的样子。我们需要专注于把事情做对，而不是暂时做对。我知道，目光短浅的人只想着暂时做对。

变革是我们前进的方式，而变革过程中添加阻力帮不了任何人。优步成熟、学习和重构是一件好事。这不是承认失败，甚至不是表明早期做出错误决策的证据。如果你有大量资金，又有称霸世界这一大胆冒险的目标，微服务大有意义。当贵公司增长的这个阶段告一段落时，裁员和合并也大有意义。实际情况发生变化时，你如何是好？

实话实说，我们几乎不知道怎么构建软件。我确信，微服务之所以大行其道，一方面是由于它至少为程序员提供了关于如何构建程序的一个连贯的理论。

每个人都给出了自己偏爱的方法以替代微服务，但是缺乏共识，我们根本没有系统性的理论。这整个讨论就是明证。

软件是一团糟。

END

历史推荐

当当网的羊毛被网友薅惨了！这一次到底被薅了多少？

2020年六大容器应用趋势

为什么API需要网关？京东API网关实践之路！

阿里巴巴为什么不用ZooKeeper做服务发现？

“中台不就是微服务嘛？有啥区别啊？”

点个在看吧