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

标签: | 发表时间:2020-04-20 14:22 | 作者:
出处:https://www.infoq.cn

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

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

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

@GergelyOrosz :

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

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

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

@GergelyOrosz :

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

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

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

@GergelyOrosz :

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

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

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

@GergelyOrosz :

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

Gregdoesit :

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

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

  1. 大公司在规模化上所做的权衡,可能并不适合你的初创公司。
  2. 大公司也会做出糟糕的架构选择,所以要小心“船货崇拜”(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 团队 微服务] 推荐:

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

- -
也许在某个丛林深处的某个地方,有一个未被发现的部落还没有对微服务下定决心,但我很怀疑这一说法. 因为人们对微服务的态度是非爱即恨. 这两者之间并没有什么太多的中间地带. 所以,当 Uber 这样的公司的一支团队宣布从微服务转向其他东西时,这意味着什么. 想想看,你对 Uber 这家公司是怎么看的. 但从软件的角度来看,Uber 一直是个“好公民”.

从Uber微服务看最佳实践如何炼成?

- - 程序猿DD
导读:Uber成长非常迅速,工程师团队快速扩充,据说Uber有2000名工程师,8000个代码仓库,部署了1000多个微服务. 微服务架构是Uber应对技术团队快速增长,功能快速上线很出色的解决方案. 本文偏向微服务的入门篇,以Uber微服务为例,进行了深入浅出的讲解. 对于微服务没有适当的定义,你可以说它是一个框架,由小型的、独立的可部署的服务组成,执行不同的操作.

Chaperone:来自Uber工程师团队的Kafka监控工具

- -
发布了开源项目Chaperone(中文意为监护人),这是一个. 在Uber,它被用于监控多个数据中心和大容量Kafka集群中数据丢失、延迟以及重复的问题. Uber现在的Kafka数据管道跨越了多个数据中心. Uber的各个系统会生成大量服务调用和事件的日志信息. 这些服务在多个数据仓库间以多活模式运行.

微服务全链路跟踪:jaeger集成istio,并兼容uber-trace-id与b3 - lipeng的个人空间 - OSCHINA

- -
微服务全链路跟踪:grpc集成zipkin. 微服务全链路跟踪:grpc集成jaeger. 微服务全链路跟踪:springcloud集成jaeger. 微服务全链路跟踪:jaeger集成istio,并兼容uber-trace-id与b3. 微服务全链路跟踪:jaeger集成hystrix. 公司有自己的一套基于k8s的paas系统,并且集成了istio,这里主要是想讲解下springcloud服务如何集成istio.

小团队中微服务的可怕之处

- - DockOne.io
微服务听起来很棒,每一个团队可以彼此独立工作而不影响其他团队. 你也可以在同一项目中使用不同的技术. 它们如此稳定,所以,你的产品会有极好的扩展. 在 2021 年,不应该把任何应用作为单体来构建,对吧. 很遗憾,微服务并非在每一种环境下都可以发挥作用,在盲目使用之前,你必须确定它们提供了你所需要的价值.

爱奇艺视频后台从“单兵作战”到“团队协作”的微服务实践

- - DockOne.io
系统越做越大,功能越加越多,我们是否有如下经历:. 一次小的需求,评估由此产生的影响成本超过开发需求本身. 系统几经交接或升级,接口文档丢失或跟代码严重不符. 每天疲于排查线上问题和修复线上数据,没有精力代码优化. 由于创建/开发/部署新服务的成本,不断的将无关的功能添加到臃肿的服务. 线上服务一个功能或者中间件的中断,导致整个系统不能提供服务.

Uber 是如何利用大数据的

- - 博客 - 伯乐在线
这篇文章概述了 Uber 是如何利用大数据分析实现商业上的成功. 文章首次发表于作者在 Data Science Central 的专栏中. Uber 是一款基于智能手机应用的出租车预定服务,将需要出行的用户和愿意提供驾驶服务的司机联结起来. 由于传统出租车的司机认为这破坏了他们的生计,而且大众对 Uber 对司机在管理上的不足也有所顾虑,这项服务已经引起了巨大的争议.

关于Uber机制的思考

- - KantHouse 追从本心,笑斩荆棘
昨天写了一篇关于滴滴打车改版的文章(文章链接),引发了一些关于Uber和滴滴的对比讨论. 质疑明显歪了楼,大家主要讨论的是,Uber忽略目的地的问题和它的派单机制,而我在昨天文章中说的是Uber的首页设计的一些问题,具体来说,是它的出发地和开始用车的按钮不在一起的问题,以及出发地带搜索icon带来误解的问题.

Uber 在运营策略上到底厉害在哪?

- - 知乎每日精选
感谢各位知友提醒,博客昨两天访问量太大,一下子冲挂了. 已经升级服务器配置,现在可以正常访问了:). 看不下去了,一些事实+各种吹捧+美化缺点+你学会了吗. 明显的朋友圈文章居然有700多人点赞,特别是还有一个敬佩的前辈点赞,心碎……我觉得真的要学习的话,应该在好的地方辩证思考,在不好的地方承认并且想解决办法,而不是一通乱夸.

Uber火了!它改变了哪些营销游戏规则?

- - 互联网的那点事
一面是专车司机揽客被抓罚款弄得人尽皆知,一面又被媒体视为宠儿上着各大媒体、自媒体的头条要闻. 作为与Airbnb、facebook等同样令人瞩目的创新先锋,为了拉动车源和客源,Uber表现出了许多灵光乍现的创意,如“一键呼叫英雄”、“一键叫高管”、“一键叫人力三轮”、“打船”等,那么除了被媒体曝光的看的见的那些创意噱头,还有哪些Uber修炼的真功夫值得市场营销者学习借鉴的呢.