对于微服务，大部分开发者的态度是明确的。他们要么喜欢它，要么讨厌它。很少有人有更“暧昧”的态度。因此，当优步的一个技术团队宣布放弃微服务，转而使用宏服务时，网友们都惊呆了。1.Uber团队为宏服务抛弃微服务不久前，Uber支付体验平台的工程经理GergelyOrosz在推特上说我们的架构方向发生了变化。澄清一下，在优步，我们正在将我们的许多微服务转移到@copyconstruct所称的宏服务（中等规模的服务）。确切地说，b/c测试和维护数以千计的微服务不仅困难——与解决短期问题相比，它可能会导致更多的长期头痛。微服务确实可以帮助团队尽早快速行动。当你意识到越少越好时，为时已晚。您需要解决许多服务中“难”的部分。我们不断添加更多服务，但也在停止服务并更仔细地考虑新服务。@GergelyOrosz：是的，我们正在这样做，这种方法解决了很多微服务痛点。每项服务都需要支持租户，包括许多无国籍的租户。我们还需要改进现有的服务，对于新的服务，我们只需要从头开始添加。@GergelyOrosz：微服务帮助企业（并且仍在帮助）快速行动、自主和试验。一个领域越成熟，就越有意义，也越容易证明“规模合适的服务”是合理的。@GergelyOrosz：我可能早就该发一篇关于微服务缺点的帖子了。微服务极乐的蜜月期说的很多，但是后来跟微服务大吵了一架，然后又和好，又是怎么改的就不多说了。一劳永逸。Gregdoesit：我写的那条推文在网上疯传。一条推文最多只能发送280个字符，你不能写太多，而且一旦你在推特上发布了一条推文，你就不能编辑它。所以不能修改和添加新的东西，我会在论坛里详细说明。以下代表我自己的经历和我工作的团队，而不是整个优步。Uber有数百个团队，其中95%我不知道。此外，团队拥有自主权，可以决定他们如何做以及做什么，所以我也不能一概而论。Uber仍然拥有数以万计的微服务。上次我检查时，大约有4000个。而且，需要明确的是，这个数字还在继续增长。我在优步工作了将近四年，并且看到了我所在领域的一些趋势。过去，我们会构建一个只做一件小事的微服务。我们有一系列由一个人构建和维护的小型服务。这对于自主性、迭代速度、学习和使DevOps成为明智之选非常有用。您可以随时开始服务，但必须随时待命。现在，随着该领域的成熟，展望未来变得更加容易。我们创建新平台，以便更周到地规划新服务。这些服务不仅仅做一件事：它们服务于业务功能。它们由一个团队（5-10名工程师）构建和维护。与一些早期的微服务公司相比，它们更具弹性，并且在开发和维护方面获得了更多的投资。辛迪称这些宏服务，我说我们正在做类似的事情。我们所做的唯一不同是服务是针对一个团队的，而不是针对多个团队的。虽然许多微服务以这种方式发展，但坦率地说，它们中的大多数保持不变。数以千计的微服务提出了许多需要解决的问题。监控、测试、CI/CD、SLA、库的所有版本（安全、时区问题）等。一直以来，我们做了一些好的举措并分享了一些有效的方法，开源了一些我们用来解决问题的工具，例如使用多租户方法测试微服务，跨服务的分布式跟踪。所有这些都是一笔巨大的投资。仅当您准备好进行该投资时，才应进行大规模微服务。所以，Uber并不像许多人解释的那样，没有使用微服务。Uber甚至不会减少微服务的使用。因此，当我说“我们要迁移”时，措辞并不准确。在我的团队和组织中，新的微服务是在深思熟虑的情况下构建的。这些新的微服务比那些早期的、较小的、专注的微服务“更大”。微服务在Uber的许多领域都运作良好，并继续在其他领域提供帮助。问题当然是有的，但是你可以边解决边处理。例如，拥有数千名开发人员的单体应用、拥有数千名开发人员的SOA或其他由数千名开发人员支持的系统。随着业务的发展，服务的数量总体上还在增长，但在一些组织中，比如我的服务数量几乎没有变化，甚至略有下降。但并非所有的微服务都是平等的。关键微服务看起来不太像经典微服务，或者至少不像我几年前所说的那种微服务。顺便说一下，每个人对“微服务”这个名字的理解都不一样。我会写一篇文章总结我在微服务方面的经验。译注：SOA（Service-orientedarchitecture），面向服务的体系结构，是一种构建分布式计算应用进程的方法。它将应用程序处理功能作为服务发送给最终用户或其他服务。它使用开放标准，一种与软件资源交互和表示软件资源的标准方式。Greg做到了：Uber在2015年从一家巨型企业转变为SOA。这种SOA遵循基于微服务的架构。我们一直在分享我们一路上学到的东西：构建微服务通常需要的步骤、解决测试问题的多租户方法，或者我们如何使用分布式跟踪等。我们还开源了一些工具，比如Jaeger，它和Kubernetes、Prometheus一起，都是CloudNativeFoundation的研究生项目……这些都可以作为灵感：但是，你需要在自己的环境里做自己的环境。被认为是最有效的决定。当业务环境完全不同时，任何技术团队盲目复制Google、Uber/SHopify、StackOverflow或其他公司都会感到失望。@copyconstruct：微服务很棘手。构建可靠且可测试的微服务比大多数人想象的要难得多。有效地测试微服务需要广泛的工具和深思熟虑。许多组织不需要像Netflix/Uber这样的微服务。宏观服务？宏服务：不是一个单体系统，每3个团队最多有20个开发人员开发服务（5个披萨规则？）是否拥有/需要一个单体仓库很难说。依赖管理更容易（仍然不容易），服务/代码存储库更少更好的可观察性和调试类似于宏服务的新品牌术语，并为之疯狂。宏服务与我们几十年来已知的普通服务有何不同？几乎没有人关心这个问题。名字是时代的产物，大多数人都在欢呼“微服务的终结”作为微服务的最终归宿。@sandofsky：优步在2016年：“我们有数以千计的微服务。’每个人都说，‘这听起来很疯狂。2020年的优步：“事实证明，这太疯狂了。”“@dhh：过度采用微服务给人们带来的痛苦是巨大的。除了MajesticMonolith之外，应该有人写过Citadel的模式：单一的MajesticMonolith抓住了大部分应用程序，很少有辅助前哨站满足高度专业化和多样化的需求。但这并不全是负面的。@saikishore001：我们发现拜耳在微服务方面非常成功。对我们来说，只有一个大型整体是一场噩梦……现在，使用微服务架构要好得多。@Carnage4Life：优步在2016，但现在退缩了。有两个重要的教训：大公司在规模方面做出的权衡，可能不适合你的创业公司；大公司也会做出糟糕的架构选择，所以要提防“Cargocult”。译注：货物崇拜是一种宗教，特别是出现在一些与世隔绝的原住民中。货物崇拜者看到国外的先进科技物品，就会将其奉为神明。最著名的货物崇拜是我是瓦努阿图塔纳岛上的“约翰布鲁姆教堂”（JohnFrumMovement）。二战太平洋战争期间，美军在塔纳岛建立了临时基地。当时，岛上的原住民看到美军从“大铁船”（军舰）中出来，非常惊讶，此外，他们还看到有一些“大铁鸟”（军用飞机）在运送人穿着美国军装和大量物资。这些原住民看到这种情况，都是一惊，觉得这些“大铁船”和“大铁鸟”很厉害。另外，美军也提供一些物资给原住民，这些物资对原住民来说是非常有用的。结果，这些原住民把美军奉为神明。这暗指那些大公司之前也没有见过或应用过微服务架构。@adamzethraeus：优步这样做实际上只是为了避免协调成本。粗略地说，优步明确鼓励不考虑重用或集成的构建。比如Uber中国团队复制了一堆三层架构，推进速度更快。（这在短期内效果很好！）对于架构炒作周期，还有一个值得考虑的经济学论点：@ridingwithrails：在互联网泡沫破灭和经济衰退期间，单体总是获胜。人们意识到十个团队使用十个不同的系统是很难保持的……再见，Felicia！@sandofsky：每次技术谈话都应该披露他们的VC燃烧率。当你把别人的钱花在你自己的问题上时，你就可以逍遥法外了。业界对微服务可能的衰落幸灾乐祸并不是好兆头。我们需要做的是把微服务集中精力用在对的地方，用对了才是竞争的核心。改变是进步之道，而在改变的过程中，人为地制造矛盾对任何人都没有好处。Uber已经成熟、学习和重构是一件好事，这不是承认失败的证据，甚至不是早期失误的证据。坦率地说，我们对如何构建软件几乎一无所知。我相信微服务发展如此迅速的部分原因是它为程序员提供了关于如何构建程序的连贯理论。每个人都给出了自己的微服务替代方案，但没有达成共识，我们也没有一个系统的理论。希望Uber的这次尝试能给我们更多启发。软件就是这么乱。
