著名的推特论战：Microservices vs. Monolithic
【编者按】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 3月6号
@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 （翻译/蔡仁君 责编/仲浩）