架构师备战(四)-软件架构设计(四) 基于服务的架构(SOA)

前面我们了解到了层次架构中表示层的架构分层，分为了MVC，MVP，MVVM等架构风格，下面我们了解一下SOA架构与微服务架构。

什么是服务？

服务是一种为了满足某项业务需求的操作，规则等的逻辑组合，它包含了一系列有序活动的交互，为实现用户目标提供支持。

SOA的起源

前面学习软件工程时，我们知道软件开发方法有结构化方法，面向对象方法，还有面向服务和原型的方法。面向服务是基于面向对象，并且是面向对象的加强的一种思想的产出物。

面向服务的思想是在构件之后的，而从对象到构件的的颗粒度是变大了的，复用的可能是一个完整的功能，比如登录。而为了取复用这些东西，我们对构件执行了标准化，而标准化在其中是很重要的。

而构件还存在一些问题，比如跨平台，用Java写的构件使用C++没办法去使用。所以我们需要对构件进一步规范化，标准化。规范化之后能够更易于复用。而服务是可以做到标准化的，做得标准化后，相互的调用变得互联互通就会变得更加的容易。

我们可以把遗留系统封装为一个个服务，但是封装成服务之后，服务之间的点对点调用又变得复杂了，交互起来存在多对多很繁杂的问题。此时出现了一个很重要的技术，也就是一个服务之间的中介者框架,企业服务总线（ESB）. 它负责作为中介者将服务与服务之间设置为星型网状结构，从而服务间的互联互通都通过ESB进行。

SOA架构的特点

• 服务构件粗粒度，传统构件细粒度居多
• 服务构件的接口是标准化的，主要是WSDL接口，传统构件常常以具体的API形式出现
• 服务构件的实现与语言无关，传统构件绑定了某种特定的语言
• 服务构件可以通过构件容器提供Qos的服务，传统构件完全由程序代码直接控制

我们了解了SOA架构的起源和特点之后,来看一下我们SOA有哪些框架实现呢,比如典型的Web Service.

SOA的实现 Web Service

Web Service有几个重要的角色：

• 服务注册中心：提供服务注册与发现的功能(SOA的服务注册，一般是手动进行注册，比如手动输入服务提供者的地址，然后添加一条数据)
• 服务请求者：发起请求的一方
• 服务提供者：提供服务的一方

我们如何在成千上万个服务中找到我们指定的服务，这个其实和百度搜索有点类似，我们通过搜索关键字来搜索对应的数据。因为百度收录了这些网站的摘要信息。所以我们的服务提供者也需要由类似的东西，也就”服务描述“。

有了服务描述之后，我们讲服务的描述信息和IP地址和端口等存储在注册中心里，而服务提供者根据服务描述向注册中心查找对应的服务，拿到IP和端口号，从而发起请求的调用。

服务提供者和服务请求者之间的绑定

服务请求者拿到服务提供者的信息之后，会做一个绑定，绑定只有就可以进行服务的调用了。而绑定的方式分为静态绑定与动态绑定。

• 静态绑定：就是我已经知道了服务提供者的网址，直接通过httpclient之类的工具直接发起http请求（绑死了）
• 动态绑定：就是从注册中心获取服务提供者地址列表，然后通过软负载均衡算法（客户端负载均衡），选择一个服务，然后发起RPC请求（没有绑死，从注册中心获取）。

SOA的实现 ESB

企业服务总线就是一个典型的中介者框架，它充当服务与服务之间的通信的一个中介者，负责将一个服务的请求转换传递后，与另外一个服务进行通信。

企业服务总线的特点

• 提供位置透明性的消息路由和寻址服务
• 就是企业服务总线能在你不提供位置信息的前提下，将您的消息传递到指定位置，从而传递到对应的服务。
• 提供服务注册与命名的管理功能
• 提供服务注册和命名的功能，是为了查找到对应的服务提供者。
• 支持多种消息传递泛型
• 就是多种类型的消息都兼容
• 支持多种可以广泛使用的传输协议
• 支持多种数据格式及其相互转换
• 提供日志和监控功能

因为ESB是中心节点，所以做协议，消息，日志和监控等处理，都放在ESB。但是ESB无疑也是一个巨大的单点，即使有主备，但性能还是比较差的。

服务总线本质上就是传统的中间件技术与XML，Web服务等技术等技术结合的产物，这些中间件包括MQ，各种网络或数据的协议转换，适配器，流程引擎等。

服务总线为应用系统之间的互联互通提供了一个基于网络的，中心化的连接中枢，它可以通过一整套标准化的协议适配器（如JMX协议，SOAP协议等）来支持应用之间在信息，事件，服务级别上动态互联互通，被接入的应用甚至还可以通过流程化的编排，把这些基础服务聚合成更大粒度的复杂服务，并通过UDD i这类协议暴露出去 ，供第三方查阅和调用。

SOA的关键技术

• 服务注册与发现
• UDDI，DISCO
• 服务描述（也就是服务的注册信息）
• WSDL，XML Schema
• 消息格式层
• SOAP，REST
• 编码格式层
• XML（DOM，SAX）
• 传输协议层
• HTTP，TCP/IP，SMTP等
• 服务编排
• BPEL4WS

重点关键技术解析

• UDDI（通过米哦啊书，发现和集成服务）：是一种目录服务，企业是、可以使用它对Web Service进行注册和搜索
• WSDL就是Web Service接口对应的WSDL文件，该文件通过XML格式说明如何调用，可以看作Web Service的接口文档（使用说明书）
• SOAP（Simple Object Access Protocol）简单对象协议，简单来说就是用于访问网络服务的协议，它是基于XML的简单协议，可使应用程序在Http之上进行信息交换。它是一种网络通讯协议，用于网络上、不同平台、不同语言的应用程序间的通讯。其实九四Http协议+XML数据格式。
• REST（XML格式的REST），也是就是遵循了REST风格，约定了新增请求使用POST，修改使用PUT，删除使用DELETE请求，并且三个请求使用同一个路由，只是请求方式不一样。
• HTTP+XML基于Web通信技术
• 简单性，缺少严格的配置文件
• 只支持几种请求方式（GET,POST,PUT,DELETE等）
• 强调信息本身，称为资源
• 网络上所有的事物都被抽象为资源
• 每个资源对应一个唯一的资源标识
• 通过通用的连接器接口对资源进行操作
• 对资源的各种操作不会改变资源的标识
• 所有的操作都是无状态的
• BPEL4WS(基于Web服务的业务过程执行语言)：实现Web服务的流程化编排。

各类技术使用关系

结合这个图和上面的解释，SOA中使用的关键技术和技术的使用场景能够大致了解了。但是上图中的有SCA/SDO/WS-Policy是什么呢？

其实是各大软件厂商共同制定了一些中立的SOA标准来保证其落地。这一努力的最终要成功就体现在这3个重量级规范上，也就是SCA/SDO和WS-Policy.

SCA和SDO构成了编程模型的基础，分别定义了服务组件的开发规范和数据的封装规范，而WS-Policy建立了SOA组件之间安全交互的规范。

上图中还有一个适配器（Adapter），它比较彻底的解决了不同协议相互转换的问题，因为我们上面提到了它支持多种不同协议，多种不同数据格式等，就是适配器在从中做转换操作。

SOA存在的问题

因为哪个时期的SOA标准和治理标准都是一帮老牌的大厂，像IBM，Oracle等。所以企业级的SOA设计到的技术栈有点过于重了，相关的规范也过于复杂，导致落地很困难。毕竟如果太容易的话，软件厂商就很难收取对应的服务费了。

而且那个时候的服务治理也很粗糙，更多的是通过ITIL这类企业内部的IT流程来实现服务的注册和梳理。因此人工行为占了很大的比例。比如UDDI服务注册就是采用人工方式将服务的接口信息（服务名，复命IP，端口等）配置到服务注册中心。

它的问题就是这些操作都是人工的，当服务数量巨大时，这个运维的代价就太大了。后期服务注册编程了自动注册就解决了这个问题。

最后，SOA中，像ESB这类组件，本身就是一个巨大的单点，虽然可以采用主备提供可用性，但是在容量扩展上依旧存在瓶颈，当服务数量已经调用者不断增长时，这个中介者终于承受不住，沉重倒在了血泊中。