微服务与单一整体式架构的优劣浅析
开发者要么出于本能，要么很快就能在痛苦中发觉：即便一个很小的变化也能改变一切。就像攀岩那样，每次挪移都会影响到未来的抉择，因此如果在开始时考虑不周的话，可能会在今后突然导致致命的危机。随着对开发生命周期和上市时间缩短这方面需求的增长，在架构初期的任何决定都比以前更加重要。
想要定义合适的软件架构，不应仅仅搭出高级架构的框架，还应联合所有利益相关者，包括程序员、管理员、市场推广人员等，最终一同得出走向成功的愿景规划。
新一场“客户端与服务器端之辩”架构师需要决定将繁重的任务放在哪边。无分软件架构模式与风格，大众都在就这个问题争论不休。
Battery Ventures风投的Adrian Cockcroft在推特上就这个主题引发了一次 著名的公众辩论 ：“Etsy 让我知道了为什么单一整体式应用是一条死路，请在可持续扩展部署中使用微服务架构。”
Etsy’s CTO John Allspaw回应道：“在这点上你缺少批判性思考，因为你想象不到它能带来的所有好处。”
而Allspaw在另一条推特中解释道：“选择变少了，机会却扩大了。只留几个人们有着深刻理解的工具和模式，反而更有优势。”
下面是相关的一点背景。单一整体式架构指的是传统的“一切归于主机”的软件开发方法。所有的进程与子程序都是庞大代码库的一部分，它们运行在不同的服务器上，以便最小化延迟，最大化正常运行时间。
较新的架构是微服务，它包括了一系列独立进程，彼此实时协调运作。最初，这听起来就像是重启古老的“客户端与服务器端之辩”。基本上这个比喻很直观，不过还有来自移动市场约束的三个显著差异。这三点差异与面向服务架构（SOA）的更新、企业服务总线（ESB）调用这些服务、以及进行一定程度的集中管制（CG）以避免复杂程度难以控制这三点相关。
SOA、ESB和CGSOA从世纪之交就已存在，它是一种处理web服务更为有效的方式。这些年来，许多不同的方面都在使用SOA。也就是说需要取决于特定情况下使用哪种定义的SOA，才能确定微服务相关的方法。
Oracle的技术网络经理Bob Rhubart这样 总结SOA的关系 ：“就现状来讲，微服务并不是SOA的替代品，更像是随着SOA逐渐过于严格和整体单一化，为了保留灵活度而采用的一种方式。”随着大量服务开始向上扩展，趋势逐渐明显：快速直接的沟通成为噩梦。通常ESB将访问方法或接口与每个服务一一对应。如果要更新系统，比如公司出售，或者供应商的任务重新分配，这时所有开发者必须要更新ESB。
集中式和分散式管制的价值也是有争议的。高级工程师 Martin Fowler和James Lewis 根据开发社区的讨论总结：“集中式管制的后果之一就是出现标准单一技术平台的倾向。根据经验来讲，这种办法过于严苛——并非每个问题都是个钉子，可以用一个锤子（解决方案）来搞定。”然而，有时候使用集中管制的单一整体式架构仍然更有意义。
从单一整体式架构中获益的项目尽管在看法、专业化和细微差异上仍有很大的商榷空间，不过有些指标确实能够表明何种架构更适合某种具体目标。例如，Stack Exchange的工程师VP David Fullerton这样 描述单一整体式架构 ：这是个让人感到乏味的架构，却能造就令人兴奋的结果。他在 纽约QCon的演讲中 这样描述自己的单一整体式架构：“其规模很适合我们。我们每个月要处理40亿个请求，峰值达到3000个/秒；每天处理8亿个SQL查询，峰值达到8500个/秒。”
单一整体式架构在时间有限时，能提供非常清晰的路径，关键是要尽快建立并运行起来。如果整支团队已经集中在一起，并取得同步，就能更有效地协作，继续完成任务。部署很简单，扩展起来也相对简单。团队只需要在大量虚拟机或独立主机上通过负载平衡器运行多个副本。一般来讲，团队最终会构建出单一整体式架构的核心，然后通过微服务手段构建可扩展组件。
从微服务架构中获益的项目关于是否使用微服务，有很多 赞成的论调 ，不过行业分析师指出：无论是应用自身，还是团队磨合，都会有很严重的沟通问题。当然，微服务在文档、测试与解决不兼容问题的时间上肯定有着更高的阈值。
PayPal的CTO James Barrese表示：他们 从单一整体式架构转到了微服务架构上 ，以便能在更短周期内更快地更新。
在新的移动、面向项目团队中，由于工作一般具有独立性、跨时区性、多平台性，因而整体进程安排起来更好一些。这种架构允许团队成员成为某个功能的专家，让应用更新的时间跨度越来越短。想要隔离并下线出现问题的组件非常简单。在企业层面上，公司无需再耗费昂贵的投资来组建特定的开发堆栈。
结论微服务软件架构代表软件开发架构的未来趋势么？ PwC显然是认可这一看法的 ，他们指出：
引用
诸如Netflix、Gilt、PayPal和Condé Nast这样的公司都是以网站可以容纳高吞吐量而著称。然而，尽管他们最近对系统做了大修大改，但那些老旧而更偏向单一整体式的架构无法再快速增加或修改原有功能了。因此，现在他们都在转用基于微服务的架构，采用更模块化、更松散耦合的方式。
不过事实上，单一整体式的结构并未灭亡，而且仍旧在快速原型法中扮演着最有效的角色，尽管到了生命周期后期，团队会逐渐转向微服务。但在切实可用的人工智能出现前，最好的办法就是结合两种架构，一起使用。
原文链接： Microservices vs. Monolithic Architecture（译者/Vera 责编/钱曙光）