SOA是一种软件的应用架构方法，它基于面向对象，但又不是面向对象，整体上是面向服务的架构。SOA由精确的服务定义、松散的构件服务组成，以及业务流程调用等多个方面形成的一整套架构方法。 这话是不是听起来，让人觉得有点晕，我们就细细品读一下。

SOA的架构思想

（一）SOA架构是面向服务的，只不过是基于面向对象

SOA继承了很多面向对象的特点，比如说面向对象的封装，经常代表很多类封装成一个模块，为其他对象调用者提供接口调用，良好的面向对象设计就是暴露接口，隐藏实现，类比到SOA的设计，SOA也需要精准明确地定义好服务接口，具体服务内部的逻辑实现都是隐藏在背后的，只不过有两个很大的区别：

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

（二）SOA的服务定义是精确的

这个怎么理解呢？因为SOA的服务一旦发布出来，那么就会有很多其他的异构平台服务进行调用，这时候的服务接口修改就不像一个人或者一个小团队之间协作那么容易了，可能涉及到一个大型企业多部门的信息协作，或者对构件已经形成依赖的生态链条。因此这就牵扯出了SOA另外一个特征，那就是服务接口的粒度一般要设置得比较粗。若提供过多的服务接口，服务又定义得很细粒度，那么频繁修改是在所难免的。这一点上就注定了SOA架构适合在较重量的环境下存在。

那什么是较重量的环境呢？（1）体系健全、制度稳定的重管理型企业，（2）业务逻辑复杂，服务的独立性，开放性需求又大，服务的稳定性也是刚需。例如：医院信息化系统架构。

（三）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整体调度与管理的一枚棋子而存在。这其实就有点SOA的精髓了。

WebService的实现方式

往往很多人不太了解SOA的情况下，就会认为Webservice就是SOA，所以这就是为什么先把上面的SOA思想以及架构实现讲讲，大家就能对SOA有个整体全面的理解。Webservice只是实现SOA构件服务的一种手段，若将其中的换成基于RestFul风格的实现，也是没有问题的。

WebService又依赖于几种具体的技术规范和协议了，具体描述我就直接引用吧：

SOAP（Simple ObjectAccess Protocol，简单对象访问协议） 定义了服务请求者和服务提供者之间的消息传输规范，SOAP 用 XML 来格式化消息，用 HTTP 来承载消息。通过 SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call， RPC）。

WSDL（Web ServiceDescription Language，Web 服务描述语言） 是对服务进行描述的语言，它有一套基于 XML 的语法定义。WSDL 描述的重点是服务，它包含服务实现定义和服务接口定义。

UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成） 提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI 规范描述了服务的概念，同时也定义了一种编程接口。通过 UDDI 提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。

如何通俗地去理解这三大件呢？

还是上个图，看起来舒服一些。如上图所示：SOA中的服务1需要调用服务2的接口，那么我们就描述一下Webservices方式。

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

然后在运行时服务1要从UDDI服务上，也就是注册发现中心，找到服务2在哪里，由于服务2早已经在UDDI服务中注册，那么服务1就可以获得服务2的路由地址。再对需要传递的数据进行SOAP格式编码。

SOAP是HTTP层之上的一个传输协议，服务1对传递参数进行满足SOAP协议的xml编码和参数发送，形成对服务2的WebService接口调用，服务2接收到SOAP协议数据，进行xml解码，然后再进行内部实现层的逻辑处理，并最终将结果仍然以SOAP方式编码返回给服务1，由服务1再解码数据。这就完成了WebService的一次请求和响应。当然了服务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基因的彻底改造，形成了更简化的一种分布式架构形态，尤其满足更为互联网化应用的需求。

前往读字节创作中心——了解”读字节“更多创作内容

本文是公众号“读字节”原创文章，转载请务必显示文章来源