近几年，微服务（Microservices）概念火热，在各类技术沙龙、会议上不断被提及。及至当下，很多大厂小司已经有了成功实施案例，也有些正在艰难的摸索过程，或是保持观望。
微服务是一种比较“年轻”的架构理念，而在它之前，有类似江湖地位的是SOA（Service Oriented Architecture-面向服务的架构）这位大佬。
相信很多小伙伴我一样，在刚接触到微服务概念的时候会不自觉的想到SOA，进而产生一些困惑：它们分别描述的是啥？是不是一种理念的不同表述？如果不同，架构思想是扩大或是聚焦还是存在借鉴重叠，简单来说是有超集或交集的关系？
本文将作者的理解与大家分享探讨，尝试对“SOA”和“微服务”的概念做更清晰的解读。
SOA和微服务是不同的
我们知道，软件工程和传统工程的显著区别之一是扩展性。为大家熟知的一些建筑工程在历经几百、几千年的风雨后，其建筑架构、功能依然不会偏离最初的设计。而软件项目第一版的交付往往就是第二版改动的开始，甚至第一版设计的时候业务已经对第二版第三版等未来充满了各种美好的设想。
而SOA和微服务都是在解决扩展性问题的过程中对可扩展软件架构的一种模式的思想总结。它们应对“可扩展”这个问题的的拆分方式都是“面向服务拆分”。这也是我们很难区分它们的原因之一。
我的观点是，“SOA和微服务是不同的”。“SOA”的概念要远远早于“微服务”的概念出现，从它们出现的历史背景和最初要解决的问题，可以发现它们架构思想的主要区别。
SOA
1996年，Gartner公司最早提出了SOA的概念
2000年之后，基于XML的WEB服务协议（soap、wsdl、uddi）和标准促进SOA发展
2002年12月，Gartner提出了SOA是“现代应用开发领域最重要的课题”
2005年后，soa推广和普及工作加速，各大厂商通过协作组织开始合作制定soa标准，涉及后续的sca、sdo、ws-policy
可以看到SOA的概念在很久前就被提出了，而当时并不是如当下的互联网蓬勃发展期。其背景是传统企业内部的各个IT系统中有大量重复建设工作，系统扩展困难，用于IT整合的预算占比太过庞大。比如，营销、财务、生产、办公等各个系统可能采购于不同的厂商，各自都有独立的人员管理等功能。企业又希望信息能够在各个系统间互通，需要这些异构系统大量的集成改造工作。
为了更好的解决这些问题，SOA中有几个核心概念：服务、松耦合 、ESB（Enterprise service bus-企业服务总线）。我们来看一个典型的架构图来理解SOA的核心概念：
（图片来自于网络）
SOA的架构中，原各个系统通过可以被ESB理解的协议开放自己的系统功能作为服务，或者使用其他系统开放的服务。ESB屏蔽各个系统间的异构性，并有公共的服务路由、异常处理、协议转换等功能，满足不同系统服务间的互联互通。各个服务间要尽量的松耦合，降低互相依赖和影响。
将系统功能通过协议暴露为服务不算复杂。松耦合就是对服务的业务设计层面解耦要求。但是技术层面，实现SOA架构的重任主要都在ESB上面。它要求ESB全知全能，协议转换更是要求对HTTP、WS、RPC、JMS等协议，XML、JSON、HTML、二进制等数据格式通通都能够解析和转换。其工作量、复杂度、计算量要求都很高，尤其当参与的系统增多，消息量愈大的时候，ESB往往成为架构瓶颈，也是SOA架构中被诟病的点。
之所以有ESB这样的设计，也是现实的无奈。正如我们上面提到的背景所述，企业IT系统中往往有很多的遗留系统，采购自不同的厂商，各家企业完全去重写或改造的成本非常巨大,自然而然，需要引入ESB这样的中间件作为核心的解决方案。
Gartner公司当初曾预言，“预计到2009年，SOA将成为占有绝对优势的软件工程实践方法， 2008年全球将有近7成企业导入SOA”。而实际上，在08、09年，各家厂商联合制定的soa标准趋于成熟的阶段，它们（厂商）预想的SOA在互联网企业中的应用依然很少，更多的是借鉴一些概念和思路。主要的应用还是在传统行业。
微服务
现在普遍认为微服务是由Martin Fowler 与 James Lewis 在2014年提出来的。实际上微服务这几年的兴起的确主要归功于两位大师在14的合写的文章，其中详细阐述了微服务的概念。Google Trends也很明显，在14年后，“microservices”一词热度上升趋势明显。
但是向前追溯的话，早在2005年Peter Rodgers在Web Services Edge大会上就提到了“Micro-Web-Services”的概念，在11和12年，一个软件架构工作组就直接使用了“microservice”这个词来描述架构模式了。12年3月ThoughtWorks的James Lewis分享了一些关于微服务的想法。
可见，微服务这种架构是也是历经很多年的演进，在一个适当时机由Martin Fowler在文章中明确定义被被大家广泛熟知。在Martin Fowler的这篇原文 https://martinfowler.com/articles/microservices.html 中，开篇就说明了此事：
The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
而关于微服务，文中的定义为:
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
把上面的定义简单翻译如下：
简而言之，微服务架构风格是将单应用开发分为一组小的服务，每个服务运行在独立的进程中，并使用轻量级的机制（通常是HTTP资源API）通讯。这些服务围绕业务功能构建，并通过自动化的部署机制被独立部署。这些服务可以用不同的编程语言编写，使用不同的数据存储技术，只需要最低限度的集中管理。
（下面引用流传甚广的一个单体应用和微服务应用架构的对比图，方便直观理解）。
Martin Fowler对微服务的定义可以说简单清晰，典型的面向服务拆分的架构。但要弄清楚和SOA的区别需要特别注意几点：
首先，微服务考虑的核心场景是将单体应用开发拆分为一组小的服务。是解决业务场景愈来愈复杂的情况下，单体应用不仅业务过重架构难以保持良好模块清晰，同时人员配合困难、变更应用影响太大，无法匹配业务发展等问题。这些问题在快速发展的互联网企业架构中愈来愈凸显。
其次，微服务间的通讯要求轻量级，各种服务采用相同的，通用的协议。Martin Fowler 文章中有一节的标题即“Smart endpoints and dumb pipes”（智能端点和愚蠢的管道/富终端瘦通信），并用 ESB做了对比。微服务推崇的消息通讯仅根据约定的协议做消息传输，其他依赖的各项功能由客户端或客户端使用其他更“纯粹”的中间件各自负责。
更重要的，微服务围绕单应用中业务功能的细粒度的拆分强依赖于自动化的部署机制，也可以讲很是依赖于现代的DevOps 基础设施。微服务之所以可以在近些年有很多成功案例并火热，也得益于容器化、DevOps的发展，否则要求快速响应，持续交付，细粒度拆分且不断增长的微服务应用对开发、部署、测试、上线等流程就是无底深渊。
总结来讲，不同于SOA为了应对传统IT企业的多系统集成场景，微服务从高速发展的互联网单体应用拆分场景演进而来，架构思想的出发点不同，形似但神不似；不同于SOA由各大厂商主推，核心解决方案中主要的产品ESB做服务间通讯，微服务倾向于简单统一的协议，简单纯粹。可以直接采用HTTP或采用开源方案甚至自己实现，也不必向厂商购买重量级的中间件产品；不同于SOA主要关注与系统集成、通讯等技术层面，微服务思想本身包括了团队组织、基础设施等DevOps领域的理念，并且不可或缺。
微服务和SOA是承继的
上一节，我们从SOA和微服务的历史背景和最初要解决的问题，相对严格的将SOA和微服务思想的差异做了分析。此节，我们再来看看他们之间的关联。
其实，从上一节的内容中我们都能体会到，两种架构的核心思想中很重要的一点，都是面向“服务”进行可扩展的设计。微服务概念出现的土壤也是SOA中这种“服务化”的思想已经深入人心，并且这种思想被更彻底贯彻在微服务理念中。所以，目前很多人认为微服务就是SOA实现的一种，甚至称之为“细粒度的SOA”。不讲绝对意义上的是或不是，总归，微服务承继了SOA的核心理念的主要部分是没错的。
上文也提到，SOA中的ESB被广为诟病，它是在那当时特定场景下一种解决方案。随着发展，在更多新的场景中，ESB并无必要，加之一些弊端，自然而然就被新的方式替代，也就是现在的“富终端瘦通信”。所以，从历史来看，微服务是慢慢从SOA演化而来，去掉其中的ESB，也没错。
在SOA架构思想向微服务演化过程中，容器化相关技术高速发展，DevOps也愈来愈火热。应用运行环境可以整体打包交付，资源调度简单高效，自动化智能化的部署、监控运维在愈来愈多的场景中实施。这些使得服务更微型化，并作为应用被自动化独立部署，需要人工参与管理却更少，这些都变的可行和合理。自然，面向服务的拆分思想吸收了营养后生长也就更加“野蛮”、“激进”。所以，不仅新理念中在服务粒度上可以更“微”，也考虑了在这种架构中开发组织和基础设施的一些转变。
总结来讲，就是微服务承继了SOA面向服务拆分的核心思想，并随着演化，去掉了ESB，结合了新兴的DevOps理念和容器化等基础设施发展优势，将服务拆分做的更彻底。所以他们的关系大概如下，是交集的关系。
微服务既然可以说是从SOA演化而来，将其定义为新的，特殊的SOA也并无不可，通常来讲，现在大家说的SOA也不是特指最初的狭义的SOA概念了。但毕竟微服务和最初的SOA理念方向有差异，在演化到一个新的阶段有明确的区分后，使用新的名词作也很合理。相信我们在搞清楚其差异和联系后，就不用过于纠结两个名词是否一个含义了。
本文只是讲述了作者自己的理解，难免会有错漏，欢迎留言讨论。作者在接触相关概念至今参考了很多朋友的资料文章，难以在此处清晰细致的一一回忆，就在此一并感谢所有愿意分享的同行，谢谢！
