微软Azure△App△Service开发团队负责人Stefan△Schackow表示，相比单套式架构，微服务对开发者的价值在于“可以快速尝试及快速失败”，即使发现该功能有缺陷，也不会对核心系统产生影响。（图片来源／iThome）
微服务一词究竟是新概念，抑或只是服务导向架构（Service△Oriented△Architecture，SOA）在云端时代的的浴火重生？“在众多软件架构中，又蹦出微服务这个新词汇”，知名架构设计圣经《Refactoring》作者也是ThoughtWorks首席科学家Martin△Fowler认为，服务微服务架构没有一套明确的定义。
前平安保险首席架构师蔡学鏞则表示，曾有中国企业CIO询问他该如何定义每个微服务的颗粒度（granularity），“这也显示微服务架构非常的不成熟”，就如90年代开始爆红的物件导向，开发者也争论物件该有的大小，或函数长度为何。
不过，从这个名称的第一个字“微”，还是可以一窥其特性。Martin△Fowler表示，微服务架构是一种开发应用程序的方法，将单一应用程序划分成多个小型服务。各服务各自执行独立的程序，并且利用API沟通。同时，各服务功能都是以企业业务逻辑为基础发展、开发，必须具备自动化、独立部署的特性。
而微软Azure技术长Mark△Russinovich在自家博客上也点出微服务架构的最大价值，他认为，微服务具备敏捷、弹性扩充等特性，“非常适用于当代云端应用程序。”而微服务这一词背后的意涵在于，应用程序被拆解成各自独立运作的小型服务，每个服务只负责单一功能，“每个微服务必须能独立更新，这样的松散耦合架构让应用程序能够快速的创新。”
微软Azure△App△Service开发团队负责人Stefan△Schackow表示，比起整套系统水平扩充，“将处理大量任务的微服务各自水平扩充，效率会更好”，前平安保险首席架构师蔡学鏞也认为，凭借这个优点，微服务可以解决促销、抢购等系统爆量事件。
此外，大型企业应用程序常见的痛点，也就是结构盘根错节的应用程序平台，想要修改部分程式码，都可能牵一发动全身。相比之下，应用程序架构复杂度比不上这些大企业的公司，碰上转型时，反而体质上有先天优势。Stefan△Schackow认为，这些企业没有过多包袱，“新创公司开张第一天就可以使用微服务了”，他认为，相比单套式架构，微服务对开发者的价值在于“可以快速尝试及快速失败”，因为该元件只专注于单一任务，即使发现该功能有缺陷，也不会对核心系统产生影响。
而蔡学鏞也认为，业务系统复杂度会影响企业导入微服务的成功机率，“而新创公司有机会导入微服务架构，像是一些专注开发社交、社群应用程序的新创，应用程序可能只需要十多个类别就可以完成。”
传统应用系统多半采用单套式（Monolithic）架构，Martin△Fowler举例，企业常用的是经典三层式系统架构，只有简单的客户端应用程序、资料库，以及伺服器端应用程序。
Mark△Russinovich表示，三层式架构中，每个元件各自是一个单套式的应用程序。一般遇到工作负载超过硬件负荷时，解决方法通常是垂直扩充或升级硬件，“避免重新开发软件。”但是，他认为，三层式架构会限制了基础资运架构的敏捷度，开发者只能在同个应用程层内，开发更多彼此互相依赖的服务，“导致任何一个服务的小更动，都必须重新部署整套应用系统。”
虽然单套式架构也可以利用负载平衡，执行更多Instance，完成水平扩充的任务，“不过大家开始对它感到挫败，因为现在许多应用程序都部署在云端上执行”，受限于此架构本身的僵固性，Martin△Fowler也同意，即使是些微的程式码异动，开发者也都必须重新部署、建置，随时间过去，“单套式架构不易维持良好的模组架构。”
微服务是颗粒度更精细的SOA架构
许多人认为，微服务跟传统SOA并没有特别差异，仅是新瓶装旧酒。像PHP之父Rasmus△Lerdorf就认为：“在架构上，微服务跟SOA并没有差异”，即使其名称有所更动，核心理念仍然是建立模组化、可替用的元件。
Martin△Fowler也同意，微服务的确跟SOA相当类似，但他认为，SOA一词背后有许多意义，原因是许多人利用企业服务汇流排（ESB）整合单套式应用程序，“我看过有些人利用ESB隐藏系统的复杂性，最后得到很差劲的SOA”，因此他认为，微服务可谓是实作确实的SOA架构。
蔡学鏞则从应用规模来看，SOA的焦点在于设计出对外的API，让外部使用者也能介接使用，“颗粒度不是SOA的重点”，但是微服务架构则不然，设计微服务的重点正是精密的颗粒度，为了让元件具有有高度自主性（Autonomy），各服务都有独立的资料库，“微服务就是颗粒度更小的SOA。”他强调。
导入微服务不只有好处，也伴随着三大代价
诚然，相较单套式架构，微服务确实能解决许多传统应用程序的开发痛点，开发者看到微服务具有独立部署、开发弹性大，可以混用多种开发工具的优点时，Martin△Fowler也提醒，导入微服务会带来3种代价。
第一种代价就是分散式系统带来的复杂度。他表示，分散式系统开发难度高，“远端呼叫很慢，而且存在失败风险。”再者，将每个应用程序划分成独自运作的分散节点，“系统更新有许多来源，开发者必须要谨慎处理系统一致性的问题。”最后的挑战则是让维运工作更加复杂，“如果没有自动化，根本不可能管理一大堆的微服务”，必须要导入持续整合、系统监控。
红帽云端应用程序开发首席架构师Christian△Posta表示，当今企业在业务领域及系统规模，都一定会碰上复杂度所带来的挑战，对企业来说，“导入微服务是趟长途旅行，无论是企业组织、应用程序规模，或是业务领域都要有所变革。”
Christian△Posta也认为，微服务的做法因每家公司而异，没有非遵守的铁则或规定，重点在于是否愿意付出代价。
但是，企业想要尝试微服务的好处，到不一定得将资讯架构一次砍掉重练。Stefan△Schackow表示：“想要一次到位，很容易跌倒。”他观察，企业已经投入许多资源在旧有应用程序之上，想要重新开发整套业务应用程序，多半会发生许多问题。他建议，企业在现有平台上叠加微服务应用程序是比较恰当的做法，“适应一段时间后，就可以将部分核心任务改用微服务提供。”
拥抱微服务要先做的三件事
企业在采用微服务之前，Martin△Fowler建议，要先做到三件事，才能顺利导入新架构。第一项是，他建议，应用程序必须具备快速建置的能力，想要达到更严谨的微服务架构，应用系统开发阶段，就必须高度自动化。
第二项则是必须要导入应用程序监控机制。他解释，由于微服务是靠着许多松散耦合（Loosely-Coupled）的服务组成，“系统运作时必定会故障，而且不容易发现问题在哪”，基本必须监控的项目包含系统出错的次数以及服务可用性。最后一项则是要能快速部署应用程序，“无论是测试环境、正式环境，开发者都要可以快速部署服务”，他认为，在早期阶段导入阶段中，可以容许些微人为介入，但是最终还是要设法达到全部自动化。
而这三项建议也意味着，开发团队与维运团队得更密切合作，“这也和DevOps文化有关联”，Martin△Fowler表示，这样合作模式的必要性，就是要确保应用程序能快速建置、部署，也能提早一步发现系统故障，“如果无法满足这三个基本条件，你不应该将微服务架构列入考虑。”他建议。
图片来源／Ade△Oshineye
ThoughtWorks首席科学家Martin△Fowler提醒，导入微服务必定有其代价，第一是系统复杂度。再者，应用程序划分成分散节点后，得谨慎处理系统一致性的问题。最后是维运工作会更加复杂。