关于大数据:通俗地理解面向服务的架构SOA以及微服务之间的关系

14次阅读

共计 4526 个字符，预计需要花费 12 分钟才能阅读完成。

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

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

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

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

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

这个怎么了解呢？因为 SOA 的服务一旦公布进去，那么就会有很多其余的异构平台服务进行调用，这时候的服务接口批改就不像一个人或者一个小团队之间合作那么容易了，可能波及到一个大型企业多部门的信息合作，或者对构件曾经造成依赖的生态链条。因而这就牵扯出了 SOA 另外一个特色，那就是服务接口的粒度个别要设置得比拟粗。若提供过多的服务接口，服务又定义得很细粒度，那么频繁批改是在劫难逃的。这一点上就注定了 SOA 架构适宜在 较分量 的环境下存在。

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

（三）SOA 是由涣散的构件服务组成

为什么是涣散的呢？由上述咱们能够理解到 SOA 的服务接口是粗粒度的，而且组成服务的构件都是独立部署并具备独立的上下文环境，这种状态就是为了升高与其余构件之间的强依赖性。让每个构件尽可能一次性为客户提供足够的其畛域范畴的服务。

例如：告诉服务，客户端只有传递过去告诉内容即可，到底是告诉短信、微信、站内信等等，这是告诉服务与配置库、用户关系库的外部逻辑关系，也能够通过音讯从其余服务中获取。因而 SOA 服务更偏向于后期就配置好告诉渠道、告诉用户组的逻辑关系，这种模式就是 客户端轻，治理端重。

上述这种涣散的、粗粒度的构建服务例子，就十分合乎 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 有没有关系？其实，这其中就暗藏着两种关系：

（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 基因的彻底革新，造成了更简化的一种分布式架构状态，尤其满足更为互联网化利用的需要。