微服务与SOA的区别

这个问题被问过有十多次了，写个材料以记之。

SOA这个词汇有二义性，一层含义是指面向服务架构(Service Oriented Architecture)这种架构风格；另一层含义是指多年前IBM/SAP/Dell/Oracle等公司搞的SOA解决方案，例如BPEL + SCA + SDO这套东西，以及Enterprise Service Bus(ESB)、WebSphere Process Server（WPS）、WebSphere Integration Developer（WID）、WebSphere Message Broker（WMB）等产品。你可以认为前者是一种Style，后者是一套Specification + Implementation。微服务可以被视作是SOA架构风格的另外一种实现方式。所以其实我们要对比的是SOA和以前IBM/Oracle等公司搞的SOA的区别。为了叙述方便，下文中的SOA均指IBM/SAP/Dell/Oracle的SOA产品。

核心区别一句话：微服务是更加去中心化的SOA

十多年前提出SOA其实就是为了解耦，解耦的本质就是为了去中心化，但是SOA有个很大的问题是，按照SOA的思路这些系统总会在某个环节上走向集中，所以去中心化做得很不彻底。开始的时候，大家都猛搞ESB，觉得总线好牛逼，流程编排好强大。问题在于系统在开发阶段就走向集中了，服务模块中没有业务，所有的业务逻辑都在ESB中通过BPEL来组装。组装好的流程再交给Struts等Server端MVC框架调用。导致系统开发、集成、测试都很痛苦，存在一个流程编排的Team来掌握所有业务行为，这群人需要具备架构设计、流程分析、系统分析的能力，所以他们很贵，人数也很少，但是所有业务变化都跟他们有关系，所以他们很容易变成大的组织瓶颈。以前搞这类系统的时候WPS在刀片机上重启一次需要40-60分钟，部署几次内存就会溢出需要重启，每天要重启N次，真是不堪回首的过去。

后来大家觉得ESB太烦人了，又难用、又超级耗资源，所以好多人不想再用，我们就开发SCA服务就行了，业务行为往前推，放到Struts Controller里去，你看是不是有点像微服务的搞法了？但是这样的系统还是会在打包环境走向集中，打出一个巨大的EAR包。没错，那时候还在用EJB 2.0，WAR包是不行的。

再后来大家觉得打成一个EAR包也很烦，部署起来不方便，代码版本也不好管，如果有人在Dependency上乱整造成Class loading的问题，那真是人神共愤令人发指。所以后来大家就想拆成多个WAR或者EAR，各搞各的呗，需要集成的时候我们就走SOAP吧。你看又有点像微服务了。但即使这样做，系统还是会在DB层面走向集中。那个年代大家觉得事务是神圣不可侵犯的。哪像现在年轻人成天乱搞！

你可能会说，那把DB也拆开吧，就彻底去中心化了。没错！完全拆开、从前通到后肯定比较爽啊，关起门来自己玩就行了。但是要支撑这种做法，你需要做很多技术准备啊，这套东西做完了，你也就搞出一套微服务了。

彻底的去中心化之后，你的系统结构和开发团队结构就变得非常灵活，你可以根据业务架构、企业组织架构来设计你的系统和团队，所以微服务架构可以视作康威定律的技术基础。