SOA是一种软件应用架构方法，基于面向对象，但不是面向对象，整体上是面向服务的架构。SOA是由精确的服务定义、松散的组件服务和业务流程调用形成的一组架构方法。这听起来是不是有点晕？让我们在洪都博客上仔细阅读。

SOA的架构思想

(一)SOA架构是面向服务的，只是基于面向对象。

SOA继承了许多面向对象的特性，比如面向对象的封装，它通常表示封装到一个模块中的许多类，以便为其他对象调用方提供接口调用。好的面向对象设计是公开接口，隐藏实现，类比SOA设计。SOA还需要准确清晰地定义服务接口，具体服务的内部逻辑实现隐藏在后面，但有两个很大的区别:

（1）面向对象的实现都是基于同一个编程语言或平台（同构），但SOA服务彻底隐藏了实现上用何种语言平台的具体细节（异构）（2）面向对象的实现其实大部分都是本地方法之间的调用，当然也具备分布式远程方法调用，但SOA是纯粹提供了独立的服务，面向分布式的远程服务调用。

(B) SOA服务定义是准确的。

这个怎么理解？因为SOA服务一旦发布，很多其他的异构平台服务都会被调用。这个时候，服务接口的修改就不像一个人或者一个小团队之间的协作那么容易了，可能涉及到一个大型企业多个部门的信息协作，或者组件依赖的生态链。所以涉及到SOA的另一个特性，就是服务接口的粒度要设置得粗一些。如果提供了太多的服务接口，并且服务是以细粒度定义的，那么频繁的修改是不可避免的。在这一点上，SOA架构注定存在于更沉重的环境中。

更重的环境是什么？(1)系统健全稳定的管理型企业，(2)业务逻辑复杂，服务独立，开放需求大，服务稳定是刚需。比如医院信息系统架构。

(C) SOA由松散的组件服务组成。

为什么松了？从上面我们可以知道，SOA的服务接口是粗粒度的，组成服务的组件是独立部署的，红豆博客有独立的上下文，这是为了减少与其他组件的强依赖。让每个组件在自己的领域内尽快为客户提供足够的服务。

比如:通知服务，客户端只需要传递通知内容，无论是通知短信、站内信等。这是通知服务与配置库和用户关系库的内在逻辑关系，也可以通过消息从其他服务获取。所以SOA服务在前期更倾向于配置通知通道和通知用户组的逻辑关系，这意味着客户端轻，管理重。

上面提到的松散的、粗粒度的构建服务的例子非常适合SOA架构的胃口，它可以让每个服务的独立性看起来很好，并提供简单的接口外观。而且接口参数越少，频繁更换接口的概率越低，满足服务接口的精准需求，以及服务更面向管理的特点。

ESB和BPM在SOA中的实现

SOA可以根据业务流程调用各种组件服务。这是什么概念？要理解这个概念，我们得从上帝的角度俯视SOA架构！

如上图所示，这是一个SOA架构的解决方案，结合了ESB和BPM的基础中间件。BPM作为一个业务流程管理平台，通过流程建模可以很好地将SOA服务与业务流程逻辑连接起来。然后，在这个过程中，BPM支持SOA架构的业务流程协作，ESB支持SOA架构的数据交换。这个架构看起来完整吗？

比如在应急指挥系统中，我们拟定一个流程计划，可以用BPM工具建模，对不同的独立运行的SOA组件服务进行流程执行调度，形成流程执行库。在应用端，一般客户端手动或通过定时器自动启动流程引擎的实例，流程引擎读取流程模型库，配合应用管理端的操作，实现组件服务的访问调度。在流程引擎调度过程中，SOA的服务组件总是围绕ESB，交换流程数据。调度物资服务、医疗资源服务、通讯设备服务和对外信息披露服务。

那么，在这个架构例子中，你能看出它非常适合复杂应用系统的集成和协作吗？因为很有可能通信设备服务提供C网通信包，材料服务运行在Java平台上，医疗资源服务运行在。Net平台，但是我们基于统一的服务规范提供准确一致的服务接口。所以，对于BPM或ESB来说，复杂的适配集成过程大大减少，各种业务和通信系统成为事实，这就是SOA的本质。

WebService的实现

很多人在对SOA了解不多的情况下，往往会认为Webservice就是SOA，所以这也是为什么我们可以通过上面的SOA思路和架构实现来对SOA有一个全面的了解。Webservice只是实现SOA组件服务的一种手段，如果换成基于RestFul风格的实现是没有问题的。

WebService再次依赖于几个特定的技术规范和协议。我就直接引用具体描述:

SOAP(简单对象访问协议)定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML格式化消息，用HTTP传送消息。使用SOAP，应用程序可以在网络中交换数据和进行远程过程调用(RPC)。

Wsdl (Web服务描述语言)是一种描述服务的语言，它有一套基于XML的语法定义。WSDL关注服务，包括服务实现定义和服务接口定义。

UDDI(Universal Description Discovery and Integration)提供了发布、搜索和定位服务的方法，是服务的信息注册规范，以便需要服务的用户能够找到并使用它。UDDI规范描述了服务的概念，也定义了编程接口。通过UDDI提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询具体服务的描述信息并动态绑定服务。

如何通俗地理解这三件事？

上图，看起来更舒服。如上图所示，SOA中的服务1需要调用服务2的接口，我们来描述一下Webservices模式。

首先虚线部分，也就是开发阶段，服务1需要了解服务2的WSDL描述，知道服务2提供的服务接口是什么样子的，描述语言是XML，这样服务1的程序才能知道设置什么参数，返回什么结果。

然后，在运行时，服务1需要从UDDI服务，即注册发现中心，找出服务2的位置。由于服务2已经在UDDI服务中注册，服务1可以获得服务2的路由地址。然后，要传输的数据以SOAP格式编码。

它是SOAP层之上的传输协议。服务1用xml对传输参数进行编码，并发送参数以满足SOAP协议，形成对服务2的WebService接口调用。服务2接收SOAP协议的数据，解码xml，然后进行内部实现层的逻辑处理。最后，结果仍然以SOAP模式编码并返回给服务1，服务1随后对数据进行解码。这就完成了web服务的请求和响应。当然，服务1也可以是普通客户端。

从上面举例说明的例子中，我们可以看到WebService使用XML作为中间交付格式，它兼容异构平台的数据格式。SOAP协议多基于HTTP协议(SOAP的设计不限于HTTP)，兼容异构平台的数据传输。

因此，WebService的技术实现方案非常符合SOA架构中服务的异构平台兼容性(SOAP)的要求，具有完整规范的服务接口语义描述(WSDL)和服务注册与发现管理的标准化定义(UDDI)。

SOA和微服务的优缺点比较

往往没有比较就没有伤害，所以通过SOA架构和微服务架构的比较，可以更深入的了解SOA架构的优缺点，同时也可以把握微服务的优缺点。

从单体到微服务的过渡架构

我们往往从上图的角度来寻求微服务的发展轨迹，也就是从单体到微服务的过渡。但是很少有人会从SOA的变异角度去思考微服务。

所以我们需要定义一个问题，微服务和SOA有关系吗？其实红豆博客里隐藏着两种关系:

（1）微服务简化了SOA架构思想，是SOA一个离经叛道的继任者，（2）微服务进行了SOA基因改造，成了一个新的变种，

微服务是SOA的离经叛道的继承者，其实是一种褒奖！

首先，我们来看看微服务和SOA有什么相似和不同。

(1)微服务专注于小的个体问题，形成服务，通过松耦合的通信机制协同工作，解决更大的问题；相反，SOA从一开始就关注重大的协调问题，首先是服务协议、规则和表达的统一，然后是足够大的独立服务的设计，并通过流程建模，解决整体问题。

(2)微服务倾向于拆分，即将单个应用尽可能拆分到一个合适的粒度，组建个人或小团队，独立为个人服务；但是SOA不一样，服务要足够粗粒度，服务接口只是作为异构系统调用的统一手段。甚至我们可以独立存在一个大型系统作为SOA的构建服务。比如前面提到的应急指挥系统的SOA架构中，通信调度系统是作为一个独立的SOA服务存在的。

(3)微服务的实现模式是自下而上的:不同的小团队分配不同的微服务进行开发、构建、部署和发布。系统的整体控制是发布和测试过程中所有团队共同参与的结果。这时候开发变成了运维，运维变成了顾问。这是Devops的思路，所以微服务更适合小团队的可持续发布。相反，SOA是一种自顶向下的实现模式，需要分层的流程管理。应该有人负责流程管理，ESB企业数据总线，每个组件服务也是不同组织的项目或者开发团队负责。因此，SOA架构在实现过程中有明确的责任关系，特别适合跨企业、跨部门的大型企业的项目的复杂应用系统建设。这与微服务的实现流程相差甚远。

(4)和SOA一样，微服务在分布式环境中形成许多不同的独立服务。与SOA相比，微服务是细粒度的，SOA是粗粒度的，它们在异构技术的兼容性上有一致的风格。微服务通过通信机制实现不同微服务的协作，主要是Restful，但是微服务用什么技术实现并不重要。同样的内容还明确了SOA的服务接口定义和Webservices的实现，是为了统一异构平台之间的协作。

最后，我们来看看SOA和微服务的对比总结。

从上面的对比可以看出，我们不可能统一所有的问题。微服自有适合的场景。如果在复杂的社会关系体系下建立复杂的应用系统，微服务的架构思路就是无源之水。相反，SOA架构具备了在这个复杂系统下的生存条件。但比如投入到很多互联网应用中，需要快速响应需求，敏捷迭代开发，灵活建立部署和发布机制，那么SOA架构肯定不适合，这个环境正好适合微服务架构。

因此，我们可以得出结论，微服务在形式上类似于SOA。在分布式环境中，进行更多的独立服务和独立部署。我们可以理解为微服务是SOA的继承者。而骨子里的微服务，则彻底粉碎了SOA繁重的前期规划、设计和分层实现，形成了一种新的思想变体，灵活敏捷小巧，更适合紧密的团队协作。这是对SOA基因的彻底改造，形成了更加简化的分布式架构形式，尤其是满足更多基于互联网的应用的需求。

我是《读字节》专栏作家，Xi科技创业者，大数据技术和分布式架构的解读、创作和咨询；

如果你觉得我写的不错，请善意的赞一下，转发一下，希望你能留下中肯的意见。

服务 微服 架构 接口 调用