软件架构设计 · SOA实现：WebService、注册表、ESB与微服务

原文说 SOA 只是一种概念和思想，需要借助具体的技术和方法来实现。从本质上看，SOA 是用本地计算模型来实现一个分布式的计算应用，也有人称这种方法为「本地化设计，分布式工作」模型。CORBA、DCOM 和 EJB 等都属于这种解决方式。目前实现 SOA 的主流方式有三种：Web Service、企业服务总线和服务注册表。先讲 Web Service。

Web Service 解决方案中一共有三种工作角色：服务提供者、服务请求者和注册中心，其中服务提供者和服务请求者是必需的，服务注册中心是一个可选的角色。服务提供者是服务的所有者，负责定义并实现服务，使用 WSDL 对服务进行详细、准确、规范地描述，并将该描述发布到服务注册中心。服务请求者是服务的使用者，从架构的角度看，是查找、绑定并调用服务、或与服务进行交互的应用程序，可以由浏览器来担当。服务注册中心是连接服务提供者和服务请求者的纽带，提供者在此发布服务描述，请求者在此查找需要的服务；在某些情况下它是可选角色，例如使用静态绑定的服务，服务提供者可以把描述直接发送给服务请求者。

Web Service 模型中的操作包括发布、查找和绑定，这些操作可以单次或反复出现。发布：服务提供者发布服务描述，以便请求者可以查找它。查找：请求者直接检索服务描述或在注册中心查询所要求的服务类型，可能在生命周期的两个不同阶段涉及——设计阶段为了程序开发而查找服务的接口描述，运行阶段为了调用而查找服务的位置描述。绑定：请求者使用服务描述中的绑定细节来定位、联系并调用服务，绑定分为动态绑定和静态绑定——动态绑定中请求者通过注册中心查找服务描述并动态交互，静态绑定中请求者已与提供者达成默契，通过本地文件或其他方式直接绑定。

采用 Web Service 作为 SOA 实现技术时，应用系统大致分六层：底层传输层，负责消息传输机制，HTTP、JMS 即 Java 消息服务和 SMTP 都可以作为传输协议，其中 HTTP 使用最广；服务通信协议层，描述并定义消息传递的技术标准，常用 SOAP 和 REST；服务描述层，以统一方式描述服务的接口与消息交换方式，标准是 WSDL；服务层，将遗留系统进行包装，通过发布的 WSDL 接口描述被定位和调用；业务流程层，支持服务发现、服务调用和点到点的服务调用，并将业务流程从服务的底层调用抽象出来；服务注册层，使提供者能够通过 WSDL 发布服务定义、支持请求者查找，标准是 UDDI。

第二种实现，服务注册表。它虽然也具有运行时的功能，但主要在 SOA 设计时使用，提供一个策略执行点 PEP，Policy Enforcement Point，在这个点上服务可以在 SOA 中注册从而被发现和使用。大多数商用服务注册产品支持三项功能：服务注册，指提供者向注册表发布服务合约，包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性，使用注册表实现 SOA 时要限制哪些新服务可以发布、由谁发布以及谁批准；服务位置，指服务使用者查询已注册的服务、寻找符合自身要求的服务，主要通过检索服务合约来实现；服务绑定，使用者利用查找到的服务合约来开发代码，与注册的服务绑定、调用和互动。

第三种实现，ESB 企业服务总线。ESB 的概念是从 SOA 发展而来的，是一种为进行连接服务提供的标准化的通信基础结构，基于开放的标准，为应用提供了一个可靠的、可度量的和高度安全的环境。背景是：在复杂的企业计算环境中，如果服务提供者和请求者之间采用直接的端到端交互，随着企业信息系统的增加和复杂度提高，系统之间的关联会逐渐变得非常复杂，形成一个网状结构，带来昂贵的系统维护费用；ESB 消除了服务请求者与服务提供者之间的直接连接，使二者进一步解耦。ESB 是由中间件技术实现并支持 SOA 的一组基础架构，是传统中间件技术与 XML、Web Service 等技术结合的产物。

ESB 具体有六大功能：支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性；通过使用 ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准；充当缓冲器的 ESB，负责在诸多服务之间转换业务逻辑和数据格式，与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时改动服务代码；

在更高的层次，ESB 还提供诸如服务代理和协议转换等功能，允许在多种形式下通过像 HTTP、SOAP 和 JMS 总线的多种传输方式，主要以网络服务的形式，为发表、注册、发现和使用企业服务或界面提供基础设施；提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地；提供安全和拥有者机制，以保证消息和服务使用的认证、授权和完整性。

在企业应用集成方面，与现存的、专有的集成解决方案相比，ESB 有四大优势：扩展的、基于标准的连接，形成一个基于标准的信息骨架，通过使用 XML、SOAP 和其他标准提供更强大的系统连接性；灵活的、服务导向的应用组合，使复杂的分布式系统能够由以前开发测试过的服务组合而成，具有高度可扩展性；提高复用率，降低成本；减少市场反应时间，提高生产率。

压轴的是微服务。通俗讲，微服务类似于古代著名的发明活字印刷术，每个服务都是一个组件，通过编排组合的方式来使用，真正做到独立、解耦、组件化、易维护、可复用、可替换、高可用。从专业角度，微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务之间采用轻量级的通信机制互相沟通，通常是基于 HTTP 协议的 RESTful API；每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等；另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

对，原文那句「应当尽量避免统一的、集中式的服务管理机制」就是这道题的命门，SOA 强调集中治理、微服务反其道行之。核心特点四条记全：小且专注于做一件事情、轻量级的通信机制、松耦合、独立部署。

微服务的优势七条：技术异构性，每个服务都可以选择适合于自身的技术，如用文档型数据库存帖子内容、用图数据存朋友圈关系，新技术可以先在一个微服务中试用再推广；弹性，每个服务可以内置可用性的解决方案与功能降级方案，比单块系统强；扩展，可以针对单个服务进行扩展而不是整体扩展；简化部署，修改一行代码不用重新部署整个应用；与组织结构相匹配，避免出现过大的代码库，获得理想的团队大小及生产力；可组合性，系统开放很多接口供外部使用，可用不同方式构建应用；对可替代性的优化，可以在需要时轻易地重写服务或删除不再使用的服务。

挑战六条：分布式系统的复杂度，服务间通信都通过网络，性能、可靠性受影响，数据一致性成本比单块系统高；运维成本，每个服务都需要独立的配置、部署、监控、日志收集，成本呈指数级增长；部署自动化，部署频度高，手动部署行不通，要构建自动化部署流水线；DevOps 与组织结构，开发者承担服务整个生命周期的责任包括部署和监控，运维越来越多地表现出顾问式的角色，要构建全功能团队；服务间依赖测试，服务数量多时如何保证按接口约定正常工作；服务间依赖管理，如何清晰有效地展示服务之间的依赖关系。最后一句定位：微服务可以说是 SOA 的一种，但二者又有差异——微服务去中心化、轻通信、独立部署，SOA 靠 ESB 集中连接，这个对比在案例分析里常考。

SOA 板块通关。下一集回到方法论：9.6 架构设计——演变交付生命周期、属性驱动设计法 ADD 的输入与三步、按架构组织开发团队、开发骨架系统，还有 9.7 架构文档化的七条规则和视图编档七部分。