Microservices和Monolithic的工程思路选择上一直存在着分歧，那么在数据体积暴增的当下，究竟哪一个才能符合实时、敏捷等新时代应用需求？这里我们看HighScalability创始人Todd Hoff对近日“Microservices
App vs. Monolithic App”推特论战的总结。
以下为译文： 曾经有一场著名的推特论战，争论的主题是“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架构无法扩展》。这篇文章的主旨是：扩展指的是大的开发者组织成功的修改、测试、发布代码的能力，指的不是系统每秒可处理的请求数量。
| 
