15.1 SOA的相关概念

15.1.1 SOA的定义

15.1.2 业务流程与BPEL

15.2 SOA的发展历史--看看即可

15.2.1 SOA的发展历史

1.萌芽阶段：

XML是SOA的基石。

2.标准化阶段

15.2.2 国内SOA的发展现状与国外对比

15.2.3 SOA的微服务化发展

随着技术的发展，SOA向微服务演进。

15.3 SOA的参考架构

IBM的Websphere业务集成参考架构(如图15-2所示，以下称参考架构)是典型的以服务为中心的企业集成架构。以它为例子来学习SOA架构。

1.连接服务——企业服务总线

举例：

2.业务逻辑服务

1).整合已有应用——应用和信息访问服务

已有的应用：如遗留应用、预包装的应用各种企业数据存储，在IBM的Websphere这个参考架构中可分两类：

(1)可接入服务(On-Ramp Service):

2).整合新开发的应用——业务应用服务

新开发的应用也是集成的目标，以服务为中心的企业集成通过业务应用服务(Business Application Service)实现新应用集成。

业务应用服务(Business Application Service)作用有2方面：

Ⅰ.它提供了很多可重用的组件，可辅助开发可重用、可维护和灵活的业务逻辑组件。

Ⅱ.提供了运行时的集成对业务逻辑组件的自治管理。就是管理类的工具自动化管理等等。

在IBM的Websphere这个参考架构中，有三类应用服务：

(1)组件服务(Component Service):

(2)核心服务(Core Service):

提供运行时的服务，包括内存管理、对象实例化和对象池、性能管理和负载均衡、可用性管理等

3).整合客户和业务伙伴(B2C/B2B)——伙伴服务

企业不是独立存在的，他需要与其他企业或者组织交互，合作伙伴的系统异构性，需要支持多种传输协议和数据格式。

在IBM的Websphere这个参考架构中，有三类应用服务：

3.控制服务

1)数据整合——信息服务

2)流程整合——流程服务

企业内部的IT系统通过将业务流程自动化提效，但是流程有可能跨部门的，所以将关联的流程(不管跨不跨部门)组成自动化流程更高效，业务流程集成就是为此诞生的。

参考架构中，流程服务包括：

3)用户访问整合——交互服务

4.开发服务

企业集成，涉及范围很广，不仅要集成新开发的应用，还有集成已有的应用和数据；不仅企业内部集成还有企业外部系统集成，不仅交互集成和数据集成，还有功能和应用集成；所以企业集成复杂性较高，需要强有力的开发工具支持。

5.业务创新和优化

一方面通过各种集成提高信息流转速度，一方面为业务创新和优化提供了支持平台。

6.IT服务管理

15.4 SOA 主要协议和规范

Web服务是实现SOA的主要手段，了解一下Web Service相关的标准。

15.4.1 UDDI协议

用于Web服务注册和服务查找，描述了服务的概念，定义了编程的接口，供其他企业来调用。

15.4.2 WSDL规范

WSDL文档的元素实例：

<definitions name="MyService"
    targetNamespace="http://www.examples.com/MyService"
    xmlns:tns="http://www.examples.com/MyService"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="http://schemas.xmlsoap.org/wsdl/">
 
  <types>
    <xsd:schema targetNamespace="http://www.examples.com/MyService">
      <xsd:element name="MyRequest">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="Name" type="xsd:string"/>
            <xsd:element name="Age" type="xsd:int"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="MyResponse">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="Greeting" type="xsd:string"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:schema>
  </types>
 
  <message name="MyRequestMessage">
    <part name="parameters" element="tns:MyRequest"/>
  </message>
  <message name="MyResponseMessage">
    <part name="parameters" element="tns:MyResponse"/>
  </message>
 
  <portType name="MyServicePortType">
    <operation name="MyOperation">
      <input message="tns:MyRequestMessage"/>
      <output message="tns:MyResponseMessage"/>
    </operation>
  </portType>
 
  <binding name="MyServiceSoapBinding" type="tns:MyServicePortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="MyOperation">
      <soap:operation soapAction="http://www.examples.com/MyService/MyOperation"/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>
 
  <service name="MyServiceService">
    <port name="MyServicePort" binding="tns:MyServiceSoapBinding">
      <soap:address location="http://www.examples.com/MyService"/>
    </port>
  </service>
 
</definitions>

服务接口和服务实现实例：

在Web服务描述语言（WSDL）中，服务接口和服务实现是通过<portType>和<binding>元素定义的。

以下是一个简单的WSDL示例，其中定义了一个名为HelloWorldService的服务接口和该服务的SOAP绑定实现。

<definitions name="HelloWorldService" targetNamespace="http://example.com/HelloWorldService"
    xmlns:tns="http://example.com/HelloWorldService" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
 
    <!-- 服务接口定义 -->
    <portType name="HelloWorldPortType">
        <operation name="sayHello">
            <input message="tns:sayHelloRequest"/>
            <output message="tns:sayHelloResponse"/>
        </operation>
    </portType>
 
    <!-- 消息定义 -->
    <message name="sayHelloRequest">
        <part name="name" type="xsd:string"/>
    </message>
    <message name="sayHelloResponse">
        <part name="greeting" type="xsd:string"/>
    </message>
 
    <!-- 服务实现绑定定义 -->
    <binding type="tns:HelloWorldPortType" name="HelloWorldSoapBinding">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="sayHello">
            <soap:operation soapAction=""/>
            <input>
                <soap:body use="literal"/>
            </input>
            <output>
                <soap:body use="literal"/>
            </output>
        </operation>
    </binding>
 
</definitions>

详细简介参考：WebService——WSDL详解-CSDN博客

15.4.3 SOAP协议

SOAP为建立Web服务和服务请求之间的通信提供支持。

这4个部分都作为SOAP的一部分，作为一个整体定义的，但它们在功能上是相交的、彼此独立的。

SOAP的两个主要设计目标是简单性和可扩展性，这就意味着有一些传统消息系统或分布式对象系统中的某些性质将不是SOAP规范的一部分。例如，分布式垃圾收集(Distributed Garbage Collection)、成批传送消息、对象引用和对象激活等。

深入研究：SOAP传输协议_soap协议-CSDN博客、SOAP协议-CSDN博客

15.4.4 REST规范

REST(Representational State Tran)：译是表述性状态转移，可以理解为资源表述性状态转移。

它不仅仅是一种规范，更是一种软件架构风格，不仅仅适应于互联网环境，而是一个普遍是设计理念，目的是为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。

微服务对外就是以REST API形式暴露给调用者的 。RESTful是在REST基础上增加了设计约束的一类设计的总称。

1.资源(Resource)

资源是REST架构中的核心概念，它是系统中某种具体实体或抽象概念的唯一标识。资源可以是任何事物，比如一个用户、一篇文章、一张图片等。每个资源都有自己的URI作为唯一标识符。

2.表述(Representational)

资源的表现形式称为表示，可以是一段文本、一张图片、一个JSON对象等。客户端和服务器之间通过交换表示来实现资源的传输和状态的转换。

3.状态转移(State Transfer)

4.超链接

深入研究：https://zhuanlan.zhihu.com/p/99196645、REST详解_rest协议-CSDN博客、rest 设计规范_rest 规范-CSDN博客

15.5 SOA设计的标准要求

15.5.1 文档标准化

15.5.2 通信协议标准

15.5.3 应用程序统一登记与集成

15.5.4 服务质量(QoS)

15.6 SOA的作用

SOA普及之前，解决企业内部信息系统的问题通常是采用EAI(企业应用整合)的方式。但是

15.7 SOA的设计原则

15.8 SOA的设计模式

SOA的实现方式：

15.8.1 服务注册表模式

15.8.2 企业服务总线模式

企业基于SOA实施EAI、B2B、BP吗的过程中，点对点的集成方式存在着复杂度高，可管理性差，复用度差和系统脆弱等问题。业服务总线(Enterprise Service Bus, ESB)技术在这种背景下产生，其思想是提供一种标准的软件底层架构，各种程序组件能够以服务单元的方式“插入”到该平台上运行，并且组件之间能够以标准的消息通信方式来进行交互。

交互过程：

一个典型的在ESB环境中组件之间的交互过程是：首先由服务请求者触发一次交互过程，产生一个服务请求消息，并将该消息按照ESB的要求标准化，然后标准化的消息被发送给服务总线。ESB根据请求消息中的服务名或者接口名进行目的组件查找，将消息转发至目的组件，并最终将处理结果逆向返回给服务请求者。

意义：

• ESB最大限度上解耦了组件之间的依赖关系，降低了软件系统互连的复杂性。连接在总线上的组件无需了解其他组件和应用系统的位置及交互协议，只需要向服务总线发出请求，消息即可获得所需服务。服务总线事实上实现了组件和应用系统的位置透明和协议透明。技术人员可以通过开发符合ESB标准的组件(适配器)将外部应用连接至服务总线，实现与其他系统的互操作。同时，ESB以中间件的方式，提供服务容错、负载均衡、QoS保障和可管理功能。

15.8.3 案例研究--看看即可

15.8.4 微服务模式

1.微服务架构概述

1).复杂应用解耦

微服务架构将单一模块应用分解为多个微服务，同时保持总体功能不变。应用按照业务逻辑被分解为多个可管理的分支或服务，避免了复杂度的不断积累。每个服务专注于单一功能，通过良好的接口清晰表述服务边界。由于功能单一、复杂度低，小规模开发团队完全能够掌握，易于保持较高的开发效率，且易于维护。

2).独立

微服务在系统软件生命周期中是独立开发、测试及部署的。微服务具备独立的运行进程，每个微服务可进行独立开发与部署，因此在大型企业互联网系统中，当某个微服务发生变更时无需编译、部署整个系统应用。从测试角度来看，每个微服务具备独立的测试机制，测试过程中不需要建立大范围的回归测试，不用担心测试破坏系统其他功能。因此，微服务组成的系统应用具备一系列可并行的发布流程，使得开发、测试、部署更加高效，同时降低了因系统变更给生产环境造成的风险。

3).技术选型架构

微服务架构下系统应用的技术选型是去中心化的，每个开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术，从而更方便地根据实际业务情况获得系统应用最佳解决方案，并且每个微服务功能单一、结构简单，在架构转型或技术栈升级时面临较低风险，因此系统应用不会被长期限制在某个体系架构或技术栈上。

4).容错

5).松耦合，易扩展

2.微服务架构模式方案

1).聚合器微服务

2).链式微服务

3).数据共享微服务

4).异步消息传递微服务

3.微服务架构面临的问题与挑战

1)聚合器微服务

①聚合模式

②代理模式

微服务代理设计模式（Proxy Pattern），主要用于在客户端、和微服务之间，增加一个代理层，以处理一些通用的功能。它是聚合器模式的一个变种。

代理模式的核心思想：是通过一个代理服务在客户端、和实际服务之间进行中介，这个代理服务可以处理各种横切关注点。

在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。

常见的横切点：

• 安全验证、和授权；

• 请求路由、和负载均衡；

• 日志记录、和监控等

API网关是一个典型的代理模式，作为所有客户端请求的统一入口点，处理：

• 路由：将请求路由到相应的后端服务。

• 认证和授权：验证用户身份和权限。

• 缓存：缓存频繁访问的数据，减少后端服务压力。

• 日志和监控：记录请求日志和监控服务状态。

需要注意的是，代理层本身也需要高可用、和高性能的设计，以避免成为系统的瓶颈、和单点故障。

微服务代理设计模式通过引入代理服务来隐藏底层微服务的复杂性，并提供额外的功能和保护。以下是关于微服务代理设计模式的一些关键点：

1. 隐藏复杂性：代理微服务可以隐藏底层微服务的复杂性，对外提供简单的接口，使使用者无需了解底层微服务的实现细节。
2. 提供额外功能：代理微服务可以在底层微服务的基础上提供额外的功能，如缓存、认证、鉴权、日志等，以增强服务的功能和性能。
3. 控制访问：代理微服务可以对外部请求进行控制和管理，例如限流、熔断、降级等，以确保底层微服务的稳定性和可靠性。
4. 解耦微服务：代理微服务可以将底层微服务解耦，使得各个微服务之间的依赖关系更加清晰，易于维护和升级

代理模式的实现方式可以包括静态代理和动态代理
静态代理是在代码编写时显式地编写的代理类，而动态代理则是在运行时动态生成代理类。
无论哪种方式，代理对象都在客户端和目标对象之间充当了中介的角色，客户端不再直接访问目标对象，而是通过代理对象间接访问目标对象。

代理模式的应用场景
在微服务架构中，代理设计模式的应用场景广泛。
例如，在跨多个微服务进行通信时，可以使用代理微服务来统一管理请求路由、认证和授权等。
此外，代理微服务还可以作为服务网关，集中处理诸如身份验证、安全性和负载均衡等横切关注点，从而简化微服务的开发。

参考：

微服务架构-代理设计模式-CSDN博客

https://zhuanlan.zhihu.com/p/694561162

③分支模式

这种模式是聚合器模式的扩展，允许同时调用两个微服务链

分支微服务设计模式是一种用于构建大型系统的微服务架构模式，其核心思想是 将复杂的业务逻辑拆解为多个小的、相互独立的子系统，每个子系统由一个或多个微服务负责处理。

以下是分支微服务设计模式的主要特点：

1. 解耦性高：每个分支逻辑都由单独的微服务负责处理，使得系统各个组件之间解耦，降低了系统的耦合度。这种设计模式使得每个微服务可以独立开发、测试和部署，从而提高了系统的可伸缩性和可维护性。
2. 灵活性：由于每个微服务都是独立的，它们可以使用不同的技术栈进行开发，这使得系统更加灵活，能够适应不同的业务需求和技术环境。
3. 快速迭代：由于每个微服务都可以独立升级和扩展，因此系统可以更快地响应业务变化和市场需求，实现快速迭代。
4. 可靠性：每个微服务都有自己独立的数据存储和处理逻辑，因此当某个微服务出现故障时，其他微服务仍然可以正常运行，保证了系统的整体可靠性。

在分支微服务设计模式中，每个微服务都负责处理特定的业务逻辑，这些业务逻辑通常根据不同的条件或参数的取值来执行不同的业务流程。这种设计模式是聚合器模式的扩展，允许同时调用两个或多个微服务链，从而支持更复杂的业务场景。

为了实现分支微服务设计模式，需要遵循一些最佳实践

如明确定义服务接口、选择合适的通信方式、选型合适的技术栈、实现数据一致性、实现自动化部署以及建立全面的监控和故障处理系统等。此外，还需要关注微服务之间的交互和协作，确保它们能够高效、可靠地协同工作。

总之，分支微服务设计模式是一种灵活、可靠且易于扩展的微服务架构模式，适用于构建大型、复杂的业务系统。通过将其应用于实际项目中，可以提高系统的可伸缩性、可维护性和可靠性，同时支持快速迭代和灵活扩展。

参考：

微服务架构-分支微服务设计模式-CSDN博客

https://zhuanlan.zhihu.com/p/694561162

异步消息允许服务发送消息后立即返回，而不需要等待消息被处理完毕，这种异步方式可以大大提高系统的处理速度、和吞吐量。

微服务架构，通常涉及多个服务之间的相互调用，如果通信只是在少数几个微服务之间进行，那么同步通信就很好。

在某些情况下，用户不需要立即得到服务的响应，而是可以在后台异步处理。

例如：当用户提交一个表单时，不需要立即等待数据的处理结果，可以在后台处理并通过消息通知用户结果，从而提高用户体验。
这意味着：发送方可以继续处理其他请求，而不会被阻塞等待响应。
而且，服务之间的通信变得更加松散，也不再需要强依赖于对方。

微服务异步消息传递设计模式是一种在微服务架构中常用的通信方式，它允许服务之间以异步的方式传递消息和数据，从而实现解耦、提高系统的可扩展性和容错性。下面将详细解释微服务异步消息传递设计模式的概念、特点和实现方式。

概念
在微服务架构中，服务之间通常通过API接口（如RESTful API）进行同步通信。然而，在某些场景下，同步通信可能不是最佳选择，因为它会导致服务之间的紧密耦合和潜在的阻塞问题。异步消息传递设计模式通过引入消息队列或事件总线等中间件，实现服务之间的异步通信。

特点

1. 解耦：异步消息传递使得服务之间可以独立运行，无需等待对方响应。这有助于降低服务之间的耦合度，提高系统的可扩展性。
2. 提高性能：由于服务之间不需要实时等待响应，因此可以并行处理多个请求，从而提高系统的吞吐量和响应速度。
3. 容错性：当某个服务出现故障时，消息队列或事件总线可以缓存待处理的消息，待服务恢复后再继续处理。这有助于增强系统的容错性和可用性。
4. 灵活性：异步消息传递支持多种消息格式和通信协议，可以根据业务需求选择合适的通信方式。

实现方式
1.消息队列：消息队列是一种常用的异步通信中间件，它允许服务将消息发送到队列中，并由其他服务从队列中消费这些消息。常见的消息队列系统有RabbitMQ、Kafka等。

• 生产者：发送消息到队列的服务，也称为消息发布者。
• 消费者：从队列中接收并处理消息的服务，也称为消息订阅者。
• 队列：存储消息的缓冲区，可以根据业务需求设置不同的存储策略（如持久化、优先级等）。

2.事件总线：事件总线是一种集中式的事件发布和订阅系统，它允许服务发布事件并通知所有对该事件感兴趣的服务。事件总线通常使用发布/订阅模式进行通信。

• 发布者：发布事件的服务，将事件发送到事件总线。
• 订阅者：订阅特定事件的服务，当事件发生时从事件总线接收通知。
• 事件总线：负责事件的发布、订阅和分发。

使用场景

1. 后台任务处理：如批量数据处理、发送邮件等耗时操作，可以通过异步消息传递将这些任务交给后台服务处理，避免阻塞主服务。
2. 跨服务通信：当服务之间的通信需要解耦或提高性能时，可以使用异步消息传递进行通信。
3. 事件驱动架构：在事件驱动架构中，服务之间通过发布和订阅事件进行通信。异步消息传递是实现事件驱动架构的重要手段之一。

总结
微服务异步消息传递设计模式通过引入消息队列或事件总线等中间件，实现服务之间的异步通信。它具有解耦、提高性能和容错性等特点，适用于多种场景下的微服务通信需求。

参考：

https://zhuanlan.zhihu.com/p/694561162

微服务架构-异步消息传递设计模式-CSDN博客

15.9构建SOA架构时应该注意的问题

15.9.1原有系统架构中的集成需求

15.9.2服务粒度的控制以及无状态服务的设计

1.服务粒度的控制

简单来说就是粒度大小适中，根据实际项目来平衡控制粒度大小。

15.10 SOA实施的过程 ---简单看看

15.10.1选择SOA解决方案

1.尽量选择能进行全局规划的方案

2.选择时充分考虑企业自身的需求

3.从平台、实施等技术方面进行考察

15.10.2业务流程分析

1.建立服务模型

1).自顶向下分析法

2.建立业务流程

1)建立业务对象

2)建立服务接口

在实现SOA解决方案的上下文中，服务接口的结构非常重要。

3)建立业务流程

站在巨人的肩膀上：WebService——WSDL详解-CSDN博客

https://blog.csdn.net/thinkpet/category_12398447.html

https://zhuanlan.zhihu.com/p/694561162