我们正处于微服务大热的时代，几乎所有的公司都在谈论微服务。谈论微服务的时候，往往都会拿SOA来作比较，得出的结论往往是：SOA是一个“过气”明星。真的是这样吗？文本将从架构的三个层次、架构内容两个角度来分析SOA与微服务的异同，并简单探讨微服务时代下SOA该何去何从。
一、微服务为王的时代？
先来看看一些有趣的场景。
经典采购场景：
甲方：”你们这个系统用的是什么技术？“
乙方：”我们用的是最新的微服务！“
一句”微服务架构“，就能让人两个还不太熟悉的人互通心意。而且”微服务“的传染性特别强，忽如一夜春风过，大家都谈微服务。无论你是技术还是业务，或多或少你都听说过微服务。
在此有些心疼SOA，虽然SOA在90~00年代就已经被提出，但是还没等到它真正火起来，就半路杀出了个“微服务”，一时间竟变成了“过去式”。当有人说他们公司还在用SOA的时候——太落后了！
那么，SOA真的过时了吗？二者描述的难道不都是服务吗？SOA同微服务的关系是怎样的？
我们先抛出两个问题：
SOA和微服务都是基于“服务”的架构风格，那么它们之间是否存在什么关联和异同？
某一种技术或者架构的出现，都是为了解决问题。那么他们是否有相似的目标、相似的作用范围、相似的内容呢？
接下来，围绕着这两个问题来寻找一些思路。
二、什么是架构
首先来看看什么是架构。
一般来说，架构包含了三个层面的含义：
- 组件与组件的关系
组件与组件的关系、组件与环境的关系很好理解，因为一个架构体系是由不同的组件构成的，组件之间的相互作用，为业务场景提供了必要的支持。
- 组件与环境的关系
组件依赖于特定的场景，脱离场景去描述组件是毫无意义的。“月落乌啼霜满天，江枫渔父对愁眠” 和 “春江潮水连海平，海上明月共潮生”，虽然都描写了月亮，但月亮的意义已然不同。
- 架构方法、指导原则
现在问题来了，为什么架构要把方法和原则包含进来？
首先明确一个前提：由于公司战略、业务、需求的不确定性，系统的建设也是一个渐进明细、慢慢演变的过程，它是一个动态的过程。若要适应这样的前提，架构就一定不能是静态，因为组件和组件、组件和环境之间的关系都会变化。所以，若架构需要能够维持环境适应性，就必然要将方法、原则包含进来；当有新的组件加入架构体系中，这些方法和原则能够指导我们如何将新的组件放置进来，当组件与组件的关系发生了变化，它们应该也能够指导我们，能够变化的最大边界是什么。
说到架构的时候必然会涉及到上面三个层次的探讨，所以在接下来的分析中，我们也适当地从架构的目的、架构的三个层面去考虑。
三、架构参考模型
在这里我不想给出SOA的定义，因为SOA并没有所谓的官方的、标准的定义。而架构参考模型是基于某一种架构风格提供的参考模型，我们希望能够透过参考模型找到一些线索。
先来看看IBM的SOA的参考模型
上图从左至右，分别是从开发（建模、装配）、部署、管理三个角度来描述。
再来看一下微服务的一种参考架构
上图将架构划分为接入层、业务层、支撑层、基础设置层。
我们结合架构的三个层次来分析一下。
组件与组件的关系
SOA参考架构图可以找到很多组件，如ESB、交互服务、接入服务、合作服务等服务组件。这些基础服务由ESB用线关联起来，所有服务之间的通信都要经过ESB。所以ESB即SOA的核心枢纽。因为这些组件都是围绕着开发、部署、实施来归集的，所以可以推测，SOA的这个参考架构考虑的是也企业范围，考虑的是企业内部之间各个组件的组织、通信和管理问题。
微服务参考架构图中，有服务框架、注册发现、服务助理、监控等众多的组件。其中，业务层的实心小圆点表示的就是具体的服务，服务之间是直连的，不需要经过类似ESB的代理。如果看的更仔细一些你会发现微服务架构还有一个特殊的组件——API网关。有三个外部箭头直接指向API网关，说明有外部流量进入。所以可以推测，微服务不仅仅考虑企业的内部结构，还关注了 企业与企业外部的通信问题。
所以，似乎是 微服务架构的范围 > SOA架构的范围。
实际上，通过查阅一些资料，我们能找到一些相反的描述：
SOA是企业范围，微服务是应用程序范围
给出的对比图大概是这样的
上图说明了SOA横向作用于企业，考虑了企业范围内所有的系统之间的关系;而微服务从纵向作用于某个应用程序，将一个程序划分为众多的“微”服务。
这里看来微服务的范围要更小的呀，是不是和我们上面的分析有冲突呢。
其实二者并没有冲突。SOA是企业范围这一点可能没有太多分歧，但为什么说微服务是应用程序范围？
——这是因为这是从服务划分的角度去看待的。SOA考虑的是企业范围内的服务划分，而微服务是把应用程序划分为更小的服务。所以一般都说SOA的粗粒度的服务，而微服务是细粒度的服务。更细的粒度也说明了微服务对于企业的整个软件生态具有更大的破坏性。
总结
从这个角度来看，SOA和微服务完全是可以共存的。在企业范围内，用SOA来做总体的规划和布局，对企业“服务化”。然后再根据系统特性，将系统分解为不同的“微”服务组合，对服务“微服务化”。
组件与环境的关系
常见的环境要素有组件作用范围、内外部技术环境、企业文化。
组件作用范围
这个上面谈过了，SOA的各个组件是在企业内部生效的；微服务的组件的作用范围会延伸到同企业外部环境对接。内外部技术环境
SOA和微服务都依赖于特定技术环境。
从外部技术大环境看
技术的发展对架构的影响是必然的。架构是演进式的，技术的变化必然会影响到企业的架构。
这里拿协议的发展作为切入点举例。
SOA的提出大约是1996年，那时正处于各种不同的协议大肆横行，并没有相对统一的协议标准，不同的系统可能都有自己的一套协议，所以导致系统之间的直接调用变得困难。所以其实不难理解，为什么以往的ESB都提供了协议转换的功能。
微服务的集成运行时采用了完全不同的模式，它不再采用中心化的集成方式，不用ESB作通信代理，而是巧妙地将服务的 注册寻址和 服务调用分离，注册中心只负责提供寻址，实际的调用是依然是系统间的正常调用。
这样的原因很大程度上是因为这些年服务之间的协议开始走向HTTP这种简单、json这种轻量化的协议。标准化的通信协议为微服务的发展提供的大好的环境。
从内部技术环境看
受限于企业的财力和技术能力。从服务划分的角度上看，服务间的远程通信都要求企业具备分布式的信息处理能力。但是相对于粗粒度的SOA，微服务的细粒度意味着更多的服务，这意味着更多的硬件资源，而运维成本也会变得更高。
- 企业文化
架构反映了企业在某一个阶段中的架构模型，架构是企业的架构，所以企业的事业环境因素必然也会反过来影响到架构本身。
企业组织架构
SOA是面向服务的架构，其内容上对企业的组织架构并没有硬性要求。但是因为将服务上升到企业高度，所以对架构上也会适当做一些轻微的调整。
微服务则不同，从微服务参考模型中可以看到，图的右上角将“企业组织与文化”单独列了出来。
微服务将系统拆成较小的服务，并且其“自管理性”也要求了在管理上需要有一套与之对应的模式与之匹配。所以在很多微服务的书籍里，都能看到“康威定律”的影子。
康威第一定律：组织沟通方式会通过系统设计表达出来。
“自管理性”意味着服务要能独立开发、测试、部署。“独立”以为着负责某个服务的团队要具备所有的能力——开发、测试、运维、DBA等。但是实际上我们的企业环境往往是标准的职能型组织架构。这正是微服务比较特殊的地方。而实际上很多公司也没有这样的能力、人才、或者人数。所以这往往是各个企业实施微服务最喜欢忽略的一点。
企业IT管理能力
SOA的参考架构中的开发设计建模、管理服务，反应了对IT的开发管理有一定要求。但是微服务强化了对IT基础能力的要求。
从微服务参考架构来看，微服务架构对Devops、服务治理、服务监控等均是单独列出，这说明微服务对于企业IT基础设施和开发管理流程均有较高的要求。
总结
从组件与环境的角度上看，SOA的适用场景和微服务的确有所不同。SOA的破坏性相对低一些，对IT基础设施的要求也要相对低一些。微服务则相反，具有高破坏性，对IT基础设施具有高要求。
指导方法、原则
SOA中有九大服务，服务之间通过ESB通信。九大服务中包含了业务的改进，这也说明了在SOA架构中，业务需要参与进来，这也体现了SOA的一个重要特征——以业务为中心。
微服务中，服务之间是直连的，服务又依赖于其他的众多组件、流程来做支撑。对企业的组织、开发管理流程均有要求。
总结
通过参考架构模型，我们可以查缺补漏，看我们现阶段缺少什么，应该加入什么组件，新的组件和其他组件之间的关系是怎样的，未来应该朝哪个方向努力。而这正是一套指导方法和原则。
从架构的三个层面去分析SOA和微服务的时候，我们初步窥探到了二者之间的异同。他们最大的差异是关注点的不同。谈到关注点，不得不提及两种架构的内容，从内容上可以知道他们在到底在关注什么，具体在做什么，这能够为我们寻找二者之间的协同关系提供一些线索。
四、SOA和微服务的内容
目标
SOA的目标
一旦将目光放到整个企业，自然就离不开成本因素。而SOA的目的其实就是从企业战略的高度去布局，让业务引领服务，让服务推动技术。提高服务的复用性，从而降低软件成本。
换个角度看，这实际上是一种外部可替代性，只不过它关注的是：在保证服务接口不变的前提下，服务本身在外部不知情的情况下，服务可以替换掉自己。微服务的目标
程序自身的可替代性！微服务架构将隔离性做的比较彻底，要求每个微服务都能够独立部署、测试、发布。这个特性让每个程序能够轻易地被替代，从而能很容易剔除故障服务实例、对服务实例数量进行横向拓展并且用户无感知，这能够极大地增加系统的敏捷力。
从架构的目标可以发现，SOA和微服务的关注点是完全不同的。他们各个所谓的“服务”，也不是相同的概念。SOA重点是将业务服务上升到战略的高度，是以业务为中心；而微服务的重点是如何拆分服务，并且要让我们的应用更有“弹性”。
既然目标不相同，那么其实他们都是在做自己擅长的领域做自己擅长的事情而已，也就是说，同时使用它们虽然有可能有一些冲突，但只要划清界限，并不是完全不可接受。
内容
通过看不同对SOA的介绍，可以发现它在业务和技术角度均作了诠释 。
SOA 的内容
- 服务公开
SOA改变了以往业务人员只对系统交付负责的局面，让业务人员也参与到了系统的规划层面。也说明了服务开始也变成了同企业战略架构、业务架构同样重要的一部分，对服务的管理和规划开始变得重要起来，也需要业务人员一起参与进来一同思考：
- 什么样的服务才是有用的服务？
- 自己到底需要什么样的服务？
- 服务应该提供哪些有用的信息屏蔽哪些信息？
通过服务公开，并持续对服务进行改进与优化，让企业享受到“可重用”的红利。
- 集成运行时
集成运行时的可以理解为：是将不同系统的服务/API集成到一起的方法。对于SOA而言，集成运行时就是考虑要如何暴露服务接口，如何进行服务间的通讯。
目前SOA通常都是采用ESB（注意，ESB不是一个软件，ESB是一种模式，它可能包含了许多的组件）来做的，它将不同系统的服务接口集成起来，系统通过ESB暴露出自己的服务，对服务的调用统一通过ESB来代理和分发。ESB通常提供了服务发布、协议转换、路由等功能。
但SOA不一定非ESB不可（实际上在OMG、Open Group给出的参考模型中也没有提及ESB）。服务如何暴露？服务之间的通讯怎么做？所以SOA并没有选择ESB，是我们习惯性选择了ESB。
微服务的内容
微服务的内容相对于SOA似乎要更多一些。目前归纳出来的，以下四个方面在几乎大多数的书籍里都有提及。
- 服务建模
大多数微服务的书籍都会告诉我们Eric的《领域驱动设计》很适合微服务。其中的限界上下文（bounded context）的概念最为经典。它指出，任何一个领域都办含许多限界上下文，每个限界上下文中，都可以划分为两部分：需要同外部沟通的，与不需要同外部沟通的。不同的限界上下文通过“模型”来进行沟通，而模型又分为内部模型和外部模型。
说白了，微服务的划分重点就是要找到这些限界上下文，并梳理出不同限界上下文通信的“模型”。
组织架构
服务建模会受到组织架构因素的影响，组织架构又会影响到软件体系。基本都会谈到康威定律。康威定律在上面已经介绍过，故在此不继续展开。服务集成
微服务的细粒度决定了其服务的管理的复杂性，所以，服务如何做集成十分重要。一般必须的组件如服务注册、服务发现、服务监控、链路跟踪、配置中心是必不可少的；而对外基本都采用API网关模式。Devops
持续集成/持续部署/持续交付同样是微服务的关注点。微服务提倡开发运维一体化的原因是同它的目标一脉相承的。微服务以“可替代性”为整个系统生态带来隔离性和敏捷力，而Devops正是对敏捷性的进一步提升。退一步来说，微服务的服务数量的爆炸性增加也使得原本的人工、分散的开发运维体系倍感吃力，自动化成为必然趋势。
总结
从内容上看。
- 微服务的“服务集成”和SOA的“集成运行时”，其实是一个东西，都是对服务的通信和管理，只不过微服务进一步细化了服务的治理方案。
- 都考虑到服务的划分，但侧重点略有不同。SOA考虑的是以业务为中心去划分服务，微服务考虑的是寻找限界上下文，并且不强调“以业务为中心”。
- SOA同样可以上Devops，特别是系统复、服务数量大的时候；反过来说，如果服务数量没有暴增，那么微服务也可以不上Devops。
- 无论微服务还是SOA，组织架构都会发生一些变化，但是要求不一样。
由此可见，SOA和微服务其实是一脉相承的。它们是两个不同时代的产物，有着相似的目标，不同的关注点。时代使然，所以它在人们的眼中也印上了不同时代的烙印。但技术持续发展的脚步不会停止，而SOA也同样在响应积极响应时代的变化
所以，SOA没有过时，架构是不断演进的，它会不断的注入新的内容。
很多人非要在SOA和微服务之间争执一个高下，或者争论二者是否是一个东西。而实际上它们只不过是是通过类似的手段和工具，去达成不一样的目标罢了。而手段和工具就在那，谁都可以使用。
所以讨论到现在，我们大致上也可以得出我们的结论了。微服务时代下，SOA将要何去何从呢？
——它们可以分别存在，不同的企业根据自身的实际情况和目的进行选择到底是SOA还是微服务；它们也将同在，你能在SOA中看到微服务的影子，也能在微服务中看到SOA的影子。
参考文献
SOA (Service-Oriented Architecture)
SOA vs. Microservices: What’s the Difference?
微服务、SOA 和 API：是敌是友？
SOA（Service-Oriented Architecture）面向服务的分布式架构详解
《微服务设计》
《面向服务的企业应用架构》
大型企业微服务架构实践与运营