订阅云计算RSS CSDN首页> 云计算

著名的推特论战:Microservices vs. Monolithic

发表于2014-08-08 14:17| 次阅读| 来源High Scalability| 0 条评论| 作者TodHoff

摘要:当下,面向服务的架构设计已成为新时代大规模应用程序的首要选择。那么这是否意味着单模块软件的消亡?情况显然不是这样,知名网站Etsy使用的就是单模块设计思路。这里,我们一起看Twitter上关于这两个模式的辩论。

【编者按】Microservices和Monolithic的工程思路选择上一直存在着分歧,那么在数据体积暴增的当下,究竟哪一个才能符合实时、敏捷等新时代应用需求?这里我们看HighScalability创始人Todd Hoff对近日“Microservices App vs. Monolithic App”推特论战的总结。


免费订阅“CSDN大数据”微信公众号,实时了解最新的大数据进展!

CSDN大数据,专注大数据资讯、技术和经验的分享和讨论,提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、机器学习、智能算法等相关大数据观点,大数据技术,大数据平台,大数据实践,大数据产业资讯等服务。


以下为译文:

曾经有一场著名的推特论战,争论的主题是“Consensus Best Way to Structure Systems”。竞争双方是Microservices App和Monolithic App。

Microservices大旗下是Netflix与ThougtWorks两大王国,拥护者分别是 Adrian Cockcroft Sam Newman先生。

Etsy王国则挥动着Monolithic大旗,其拥护者是John Allspaw 先生。

除此之外,来自Digital Ocean王国和其他一些独立区域的勇士也出现在这场论战中。论战的冠军将获得“开发者的高度关注和幸运女神的青睐”

最早的论战是Cockcroft先生展开的,他参加了很多论战:

adrian cockcroft ‏@adrianco 3月5号

#qconlondon的Etsy让我很清楚地意识到为什么Monolithicapp要灭亡了。使用Microservices来获得持续的可扩展的部署吧。

Neil Bartlett ‏@nbartlett 3月5号

@adrianco是的,1000个支持。尽管人们在Microservices的部署方面可能意见不同。 @AnneWoof

adrian cockcroft ‏@adrianco 3月5号

@nbartlett @AnneWoof Monolithic app迫使人们做同样的决定。Microservices解放了大家,大家可以按需求进行创新或优化。

John Allspaw ‏@allspaw 3月5号

@adrianco你在这个问题上缺乏批判性思维,因为你不能想到所有的益处。

Sam Newman ‏@samnewman 3月5号

@allspaw @adrianco通常,在如何解决问题方面,Microservices给你更多选择。

John Allspaw ‏@allspaw  3月5号

@samnewman还有更多的限制 @adrianco

John Allspaw ‏@allspaw 3月5号

@samnewman有些时候,更少的选择会带来更多的机会。少数的易懂的工具和模式会带来好处。 @adrianco

John Allspaw ‏@allspaw 3月5号

@samnewman Microservices也有一个别名——“我想坚持自己的方式,不用讨论我的决定的利弊”。 @adrianco

Sam Newman ‏@samnewman 3月5号

@allspaw @adrianco它可以给我们更多自己自由——将我们从标准化的状态转为可以自由选择的状态。

Sam Newman ‏@samnewman 3月5号

@allspaw @adrianco服务的标准化是很重要的(监控,整合)。局限思维?给团队自主权。

Sam Newman ‏@samnewman 3月5号

@allspaw @adrianco这些都基于对组织中的“好成员”有一个好的描述。

Mark Burgess ‏@markburgess_osl 3月5号

@samnewman @allspaw @adrianco关键是你如何测量这些方法在用户/供应商体验和目标适用性上的差异?

Mark Burgess ‏@markburgess_osl 3月5号

@samnewman @allspaw @adrianco一旦你确定谁可以从什么获益后,你可以考虑一个加权优化政策。

Mark Burgess ‏@markburgess_osl 3月5号

@samnewman @allspaw @adrianco这是一个非常有趣的讨论!

adrian cockcroft ‏@adrianco 3月6号

@allspaw我在Netfix工作的头三年,Netfix是一个Monolithic  app。这个团队有100多个工程师,大家的关注点都很分散。

adrian cockcroft ‏@adrianco 3月6号

@samnewman @allspaw中心计划和协商的事情不会扩展,其创新速度也不如高信任度的自由和责任。

John Allspaw ‏@allspaw 3月6号

@adrianco @samnewman在Etsy,我们的架构和流程有高信任度、自由和责任。Conway的条例不能称之为条例。@samnewman

John Allspaw ‏@allspaw 3月6号

@adrianco我想说的是你忽略了一点——你关于Etsy的言论可能是错的。

John Allspaw ‏@allspaw  3月6号

@adrianco谁说Etsy是中心计划的?你闹钟的Etsy开发模型是有缺陷的。

adrian cockcroft ‏@adrianco 3月6号

@allspaw抱歉,我不确定你觉得我说的哪一部分是错误的。我在讨论扩展一个像Etsy和Facebook一样的monolith的替代选项。

John Allspaw ‏@allspaw 3月6号

@adrianco我没有听到“替代选项”,我只听到“不能运行”,“灭亡”和“Microservices在各方面都很优秀”。如果我说错了,我向你道歉。

adrian cockcroft ‏@adrianco  3月6号

@allspaw昨天我去参加了Etsy大会。Php语言的Monolithic导致功能不能用其他语言实施,如clojure

John Allspaw ‏@allspaw 3月6号

@adrianco 是的。而且Clojure语言的Microservices也不具有php的优势。工程是在多种影响之中的权衡。

John Allspaw ‏@allspaw 3月6号

@adrianco我已经在这工作4年多了,我想说,你考虑的不全面。:)

adrian cockcroft ‏@adrianco 3月6号

@allspaw我想来自Etsy的伙计应该谈一谈使用monolith的好处,但我不认为增加独立队伍会阻碍创新。

Alan ‏@AlanMorrison 3月6号

@adrianco @allspaw (链接 http://bit.ly/1nha966 )正确的服务水平应该在微观和宏观之间,如一个过程中的步骤,对不对?

John Allspaw @allspaw 36

@adrianco好主意。

Adam Thody ‏@thody 3月6号

@allspaw @adrianco先生们,这是一场挺好的,但冗长的、过时的辩论。软件和组织中应该避免教条主义。

John Allspaw ‏@allspaw 3月6号

@adrianco 以下是我的想法的整理(链接https://gist.github.com/anonymous/9388472 … /cc) @kellan

  • Monolithic不同应用间架构不同,具体情况需要具体分析。
  • Microservice也是,应用和架构要具体问题具体分析。
  • Microservices和Monolithic架构都有优点。
  • 组织应该充分利用这些优点,避免缺点。
  • 商业的成功是考虑使用何种开发解决方案的要考虑的很大因素。
  • 所有的益处和工作队伍都是环境敏感的。也就是说它们是由所在组织的技术和社会构造的。
  • 路径依赖是一点。历史影响着、也说明了组织中的架构决定和升级。
  • 模式的存在是为了告知实践,不是为了指示实践。一味的依附于架构模式可能会导致实践中忽略文化环境的风险。
  • 架构模式会扩展、收缩、升级和改变来适应组织所要达到的权衡。

Kevin Behr ‏@kevinbehr 3月6号

@allspaw @adrianco很有趣。我读了这个帖子,还把“我热爱多样性和适应性”大声念了出来。

Sam Newman ‏@samnewman 3月6号

@allspaw @adrianco我发现conway定律更多的是定义什么是对的,而不是什么是错的。我把它当做指导,而不是硬性规定。

Sam Newman ‏@samnewman 3月6号

@allspaw @adrianco信任实现自治是关键——有很多种方法可以达到这一点。我们追求的是正确的架构。

Sam Newman ‏@samnewman 3月6号

@allspaw @adrianco 当需要标准化时,我试图使标准化容易、透明,如提供标准化工具。

adrian cockcroft ‏@adrianco 3月6号

@allspaw @kellan 我同意,我还要补充一点:一个Microservice可以看做是一组小monolith的和。

adrian cockcroft ‏@adrianco  3月6号

@samnewman @allspaw反转conways定律的应用有助于影响搭建的架构。

Steve Smith ‏@AgileSteveSmith 3月6号

@samnewman我喜欢看到标准逐渐成为成功的副产品,成为未来改进的基础。/@allspaw @adrianco

Anthony Elizondo ‏@complex 3月6号

@adrianco @allspaw @kellan 基于你们的观点,消费者看到的是Microservice,供应商看到的是monolith。

Sam Newman ‏@samnewman 3月6号

@AgileSteveSmith @allspaw @adrianco我在内部工具链和服务模板中增量变化中发现了这一点。

Sam Newman ‏@samnewman 3月6号

@AgileSteveSmith @allspaw @adrianco 基本同意,不过有些事情需要预先决定。如,避免连锁故障的措施。

如你所见,这里存在很多关于这两个模式的讨论,但似乎都没有掐中要害,然后就变成顾左右而言其他。也许有一天这样的辩论还会继续,但也可能存在大同小异的辩论内容。下面谈谈为什么需要这种论战。

Monolithic APP被视Anti-Pattern

Etsy的开发、部署和整合版块写道:“每天在Etsy有大约150个工程师部署单个Monolithic应用六十多次。”Monolithic应用的 “所有所需的逻辑都在一个“单元”(一个jar,一个应用,一个资源库)。

作为一个公司,Etsy很成功,Etsy可不是什么小站点,2013年2月,Etsy有:14.9亿次页面浏览,169个主题出售,价值9470万的商品出售,2200多万个商品,8000000多个活跃商铺。

Etsy还示范了如何搭建一个好站点,正确的做事:持续的集成;平均每个开发组一个VMs;按钮式部署;良好监控;开发者在第一天部署站点;GitHub;Chef;用IRC控制发布管理;仪表盘;不使用源代码控制分支,总是在主分支有效地部署。那么,Etsy怎么还在使用Monolithic?

这种怀疑是因为Monolithic应用使用Anti-Pattern。关于这一点,请参见《Monolithic架构无法扩展》。这篇文章的主旨是:扩展指的是大的开发者组织成功的修改、测试、发布代码的能力,指的不是系统每秒可处理的请求数量。

俗话说的好:厨师太多反而做不好汤。

我们都知道,要做好汤,我们需要把大厨房分为很多小厨房,每个小厨房都有自己的厨师、人员、货物供应和设备,饥饿的消费者协调各个分离的厨师做出美味的汤。然后得到好汤,这将我们引向了Microservice。

Microservice很棒

解决Monolithic应用的一个问题是将应用分为多个Microservice。Matin Fowler解释道:

2011年5月,威尼斯的一个软件架构工作坊提到了“microserverice”这一术语,这一术语描述了参与者们正在探索的通用架构类型。2012年5月,这个组织决定“Microservice”是最合适的名字。2012年3月,James在波兰以案例学习的形式展示了其中的一些观点,同时期,Fred George也阐述了这些观点。Adrian Cockcroft将这种方法描述为“细纹理SOA”,是网络规模类型的先驱。

Sir Cockroft 先生在DevOps咖啡店的一次访谈提到了Microservice的严格定义。概况如下:

  • 对速度的优化促使开发者将代码整合到Monolithic app。让一个Monolithic app工作很难。当一个功能出问题需要返工时,同期发布的所有功能都需要返工。
  • 当多于100个开发者工作于同一个项目时,就会达到使用Monolithic方法的阈值,搭建一个项目会变得越来越难。只有10个开发者时Monolithic方法可行。
  • 当多于100个开发者时,Netfix的DVD app就出现问题了。于是他们就想把app分为单独的片。最终他们采用了Microservice。Microservice旨在满足速度和敏捷度的需求,通过Microservice,团队可实现独立部署。
  • 与SOA不同,Microservice是松耦合的。如果升级一个服务需要其它服务的协作,那么这个服务不是松耦合。如果你的app需要Google、Facebook和Foursquare  API的升级,那么这个app不是松耦合的。
  • 如果一个服务出了问题,并且导致了连锁反应,相关的服务也开始出问题,那么这就是个大问题。我们需要搭建隔板、断路器和其它企业类型模式。我们在搭建防御式代码。
  • 瀑布式的问题是花费时间太长,反馈路径太不连贯。问题具体化给了其它组。在瀑布式方法中,当问题出现时,最早的团队通常已经解散了。
  • 持续交付,数天或数周调试代码,在产品中运行代码可以产生一个立即的反馈回路。如果开发者代码写的不好,服务会立刻出问题,开发者可以得到立即的反馈。
  • 我们还需要包括失败的波及范围。去耦合的Microservice意味着更高的可用性。如果一个服务失败了,我们很容易识别和包括这个识别。我们可以很容易的判断出谁跟这个服务有关,进而确保问题不会扩散到其它服务。
  • 这和紧密相连的企业模型很不相同,在这些模型中运维的兄弟们告诉开发者一切都很好,开发者不需要为了宕机的事情编程。告诉开发者,任何事情在任何时刻都可能宕机,这是与开发者合作的另一种方式。开发者需要做更多的工作,但最终产品更早进入市场,产品也更可靠。因为开发者自己运行产品,所以他们在与其他组开交接会议上所花的时间更少,因此他们有更多的时间编程。

我们所期待的目标是很好的。避免防御式编程,去耦合,关注点分离,迅速部署,错误隔离,快速反馈回路,开发者责任制,专注做好一件事情的app,独立升级路径,优化的版本控制,团队间分离……这些都是我们的目标。

问题是:Microservice是实现这些目标的唯一办法么?即使不是,Microservice是实现这些目标的最好办法么?

对于第一点,发布非独立功能时,如果一个功能失败了,所有的功能都要返工。这是分支和粒度发布策略(release granularity policies)的架构。Erst推测可以通过不缓存功能的方式来避免这个问题,功能一旦完成就进行发布。一天持续发布很多次意味着一天发布了很多变化,这些发布是独立可复原的,因此就不会有什么问题。功能标识是另一种应对产品功能问题的办法,不过没那么好。

尽管Microservice是解决返工问题的一个解决方案,但这不是唯一的解决方案,也不是最好的解决方案,Microservice只是这场论战中反复提到的一个模式。

服务不是什么新东西

很显然Microservice处于领先地位。故事是不是还有另一面呢?我同意Microservice是对已有服务的再造。我们一定需要一个新词么?我认为这可以让沟通更明晰,因此可以。那么服务的内容有什么变化呢?一个新的绑定需要新的词语。这就像语言方法进行版本控制。10年前Microservice的词也是不同的,所以我们需要用一个新词来描述现在。

真正的对比应该是和Unix和我们的老朋友/etc/services对比,etc/services中有很多独立的服务,例如nfs、ntp、smtp、whois、echo、time、ftp、quote和 hostnames。这些服务的复杂度各不相同,有些很简单,有些很复杂。这些服务都是独立的,因此它们可以都运行在同一台机器上,不需要类似于VM的容器。神奇吧!

服务是怎么创建的?阅读W.Richard Stevens的著作,使用本地TCP/IP和线程库创建自己的信息handler、格式和协议。在此之上你可以搭建Actor,状态机处理器,消息代理,发布和订阅机制,计数器handler,线程池,工作序列和高级CPU调度算法。或者你可以使用雷系ACE的框架帮助你。

很多服务都是按上述描述搭建的,它们性能很快,不需要HTTP、网络服务器或任何其他现代的“改进”。在移动领域,HTTP绝不是助力。因此服务总是在工作,没有什么理由去换新。

捍卫monolith—如上所述,因此:

Monolith总是工作的。一个有任何复杂形式的服务通常也有复杂的现场和内部结构,因为服务是请求会话和响应会话的端点。这意味着服务的内部可以很复杂,需要很大的团队开发这些内容,需要严格的延迟控制和高可用性。

我们所看到的是复杂是保守的。都是你自己的代码时,不会因为简单的把一切都隔离到墙后面而导致复杂。复杂在什么地方。只有本质简单的简单才是真的简单,否则简单只是一种抽象的说法,大家很快就会识破。

去耦合和关注点分离的优点都可以在代码库中实现,如果你不能让复杂的代码工作,你可以查看代码结构,编程语言的选择,程序员,源代码控制策略,分支策略,故障修复策略,发布策略和搭建和部署系统。不要一下子就断定是Monolith的问题。

例如,一直以来去耦合都是通过库机制实现的。我知道这是软件工程,不是算法,请屈尊和我一起从软件工程的角度看问题吧。如果代码库分为了独立的库,有着清晰地接口,那么来自世界各地的上百个人都可以独立的工作于这些库。是的,库可以作为分离的产品放入源代码树,任何需要这些产品的工程都可以使用这些产品。这些产品有自己的发布策略,故障追踪等。接口必须保证真实有效,就像服务接口一样。如果接口变化了,那么另一个版本的库可以创建,就像一个服务。每个库可以单独测试,就像一个服务。每个团队都可以使用自己的流程和策略进行开发,就像一个服务。

不同的组件是如何在流程中协作的呢?

流程中的内部代码应该和将所有库组件聚集起来、安装、配置、管理所经历的引导顺序差不多。

所有运行代码的事项都必须这么做。Microservices一定有内部的方式来解决内部和外部的服务引用,以依赖顺序开启服务,启动时配置服务,运行时重新配置服务,处理失败,处理HA,使用度量监控等。

当OS启动时,OS也做同样的事情,OS上运行的每个流程也做同样的事情。每个服务也做同样的事情。每种情况下为达到目标调整的是机制而不是模式本身。每种情况都受制于自身的困难,这些困难不会藏置于抽象层后。

Monolith不能做的是支持不同语言的开发,因为必须要构建一个图形。不过这是要评估的权衡,不是一个强烈的反对理由。

因此,Microservices运动目标是完美无缺。实现这些目标的机制比支持者预想的灵活。可能成为Big Ball of Mud 。许多敏捷/TDD/极限编程都是管理代码熵的一种方法,服务也可以通过同样的方法,形成自己的Ball of Mud。一个有良好软件工程支持的Monolithic代码库可以良好工作,Etsy就是如此。

原文链接: The Great Microservices Vs Monolithic Apps Twitter Melee (翻译/蔡仁君 责编/仲浩)

0
0