导图社区 面向服务架构
- 47
- 0
- 0
- 举报
面向服务架构
这是一篇关于面向服务架构的思维导图，主要内容包括：SOA 参考架构，SOA 主要协议和规范，SOA 设计模式：服务注册表、企业服务总线、微服务等。
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材，使用前请自行确认授权范围。
- 架构师
- 软件
- 程序员
- 程序世界
- 相似推荐
- 大纲
面向服务架构
概念
定义
面向服务的体系结构（Service-Oriented Architecture，SOA）
应用角度
SOA 是一种应用框架，着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务
软件角度
SOA 是一个组件模型，将应用程序的不同功能单元（成为服务）通过这些服务之间定义良好的接口和契约联系起来
业务流程
业务流程是指为了实现某种业务目的行为，所进行的流程或一系列动作
BPEL
（Business Process Execution Language For Web Services）面向 Web 服务的业务流程执行语言
用户可以使用该语言，组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构
用于整合现有的 Web Services，将现有的 Web Services 按照要求的业务流程整理成为一个新的 Web Services
例;
一个简化的订单处理流程，包括接收订单、检查库存和处理支付三个主要步骤
<process name="OrderProcessing" targetNamespace="http://example.com/bpel/order" xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:ord="http://example.com/orderservice" xmlns:inv="http://example.com/inventory" xmlns:pay="http://example.com/payment"> <!-- 合作伙伴链接 --> <partnerLinks> <partnerLink name="customer" partnerLinkType="ord:orderLT" myRole="orderService"/> <partnerLink name="inventoryService" partnerLinkType="inv:inventoryLT" partnerRole="inventoryService"/> <partnerLink name="paymentService" partnerLinkType="pay:paymentLT" partnerRole="paymentService"/> </partnerLinks> <!-- 变量定义 --> <variables> <!-- 输入订单消息 --> <variable name="orderRequest" messageType="ord:orderRequestMessage"/> <!-- 库存检查请求/响应 --> <variable name="inventoryCheckRequest" messageType="inv:checkInventoryRequest"/> <variable name="inventoryCheckResponse" messageType="inv:checkInventoryResponse"/> <!-- 支付处理请求/响应 --> <variable name="paymentRequest" messageType="pay:processPaymentRequest"/> <variable name="paymentResponse" messageType="pay:processPaymentResponse"/> <!-- 订单响应 --> <variable name="orderResponse" messageType="ord:orderResponseMessage"/> </variables> <!-- 主流程 --> <sequence> <!-- 接收初始订单请求 --> <receive partnerLink="customer" portType="ord:orderPT" operation="placeOrder" variable="orderRequest" createInstance="yes"/> <!-- 准备库存检查请求 --> <assign> <copy> <from variable="orderRequest" part="orderInfo"/> <to variable="inventoryCheckRequest" part="itemInfo"/> </copy> </assign> <!-- 调用库存服务 --> <invoke partnerLink="inventoryService" portType="inv:inventoryPT" operation="checkInventory" inputVariable="inventoryCheckRequest" outputVariable="inventoryCheckResponse"/> <!-- 检查库存响应 --> <switch> <case condition="bpws:getVariableData('inventoryCheckResponse', 'availability') > 0"> <!-- 有库存，处理支付 --> <assign> <copy> <from variable="orderRequest" part="paymentInfo"/> <to variable="paymentRequest" part="paymentDetails"/> </copy> <copy> <from expression="number(100)"/> <!-- 示例金额 --> <to variable="paymentRequest" part="amount"/> </copy> </assign> <!-- 调用支付服务 --> <invoke partnerLink="paymentService" portType="pay:paymentPT" operation="processPayment" inputVariable="paymentRequest" outputVariable="paymentResponse"/> <!-- 准备成功响应 --> <assign> <copy> <from expression="'Order processed successfully'"/> <to variable="orderResponse" part="status"/> </copy> <copy> <from expression="number(123456)"/> <!-- 示例订单号 --> <to variable="orderResponse" part="orderNumber"/> </copy> </assign> </case> <otherwise> <!-- 无库存，准备失败响应 --> <assign> <copy> <from expression="'Item out of stock'"/> <to variable="orderResponse" part="status"/> </copy> <copy> <from expression="number(0)"/> <to variable="orderResponse" part="orderNumber"/> </copy> </assign> </otherwise> </switch> <!-- 发送响应给客户 --> <reply partnerLink="customer" portType="ord:orderPT" operation="placeOrder" variable="orderResponse"/> </sequence> </process>
发展阶段
起源
为了将公司的业务打包成独立的、具有很强伸缩性的基于因特网的服务，人们提出了 Web 服务的概念
萌芽
以 XML 技术为标志
XML 用途
可以将任何文档转为 XML，再通过网络传输。借助 XML 转换语言（XSLT，eXtensible Stylesheet Language Transformation），接收方可以解析和抽取 XML 数据
规定了服务之间和内部数据交换的格式和结构
XSD Schemas
保障了消息数据的完整性和有效性
XSLT
使得不同的数据表达能通过 Schema 映射而互相通信
标准化
Web 服务标准化，实现异构系统之间的简单交互
主要规范
SOAP
简单对象访问协议（Simple Object Access Protocal）
WSDL
Web 服务描述语言（Web Services Description Language）
UDDI
通用服务发现和集成协议（Universal Discovery Description and Integration）
成熟
主要规范
SCA
（Service Component Architecture，服务组件架构）
是一种基于 SOA（面向服务架构） 的编程模型，用于构建松耦合、可重用的服务组件，并支持多种编程语言（Java、BPEL、C++等）和技术协议（Web Services、JMS等）
核心特点
组件化开发
将业务逻辑封装为独立的组件（Component），通过 服务（Service） 和 引用（Reference） 暴露功能或依赖外部服务
松耦合
通过 绑定（Binding） 机制（如SOAP、REST、JMS）实现协议无关性
组合应用
通过 组合（Composite） 将多个组件组装为完整应用，定义在 composite.xml 文件中
例： <composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" name="OrderProcessing"> <component name="OrderService"> <implementation.java class="com.example.OrderServiceImpl"/> <service name="OrderService" promote="OrderService"> <binding.ws uri="http://example.com/orderservice"/> </service> </component> </composite>
SCA 组件通常使用 SDO 作为标准数据格式，实现组件间的数据交换
SDO
（Service Data Objects，服务数据对象）
一种数据访问框架，提供统一的 API 来操作异构数据源（如数据库、XML、JSON），常用于 SCA 组件间的数据传递
核心特点
统一数据模型
屏蔽底层数据源差异，以 DataObject 形式表示数据
变更跟踪
自动记录数据修改（增删改），支持增量更新
动态/静态类型
支持动态访问（如 dataObject.get("property")）或静态代码生成
例： // 创建DataObject DataObject order = dataFactory.create("http://example.com", "Order"); order.set("orderId", 1001); order.set("customer", "张三"); // 访问数据 String customer = order.get("customer"); // 输出"张三"
WS-Policy
（Web Services Policy）
是一种 XML 标准，用于描述 Web 服务的 非功能性需求（如安全、事务、可靠性），通常与 WSDL 结合使用
核心元素
策略断言（Policy Assertion）
具体需求声明（如 必须使用HTTPS）
策略附件（Policy Attachment）
将策略关联到服务端点（Endpoint）或操作（Operation）
例：
<wsp:Policy xmlns:wsp="http://www.w3.org/ns/ws-policy"> <sp:TransportBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <wsp:Policy> <sp:TransportToken> <sp:HttpsToken RequireClientCertificate="false"/> </sp:TransportToken> <sp:AlgorithmSuite> <sp:Basic256/> </sp:AlgorithmSuite> </wsp:Policy> </sp:TransportBinding> </wsp:Policy>
SOA 的微服务化发展
SOA 向更细粒度、更通用化程度发展
SOA 与微服务的区别
微服务更精细，微服务更多地以独立进程的方式存在，互相之间无影响
微服务提供的接口方式更通用化，例如 HTTP RESTful 方式
微服务更倾向于分布式去中心化部署
微服务架构是 SOA 的进一步优化，去除了 ESB 企业服务总线，是一个去中心的分布式架构
SOA 与微服务架构图
SOA 参考架构
典型例子
IBM 的 Websphere 业务集成参考架构（以服务为中心的企业集成架构）
概念
以服务为中心的企业集成，采用“关注点分离（Separation of Concern）”的方法
规划企业集成中的各种架构元素
规划每种结构元素提供的服务
服务如何组合在一起完成某种类型的集成
狭义的服务（WSDL 描述）
广义的服务（某种能力）
企业集成架构的服务分类
业务逻辑服务
概念
（Business Logic Service）
包括用于实现业务逻辑的服务和执行业务逻辑的能力
业务应用服务（Business Application Service）
业务伙伴服务（Partner Service）
应用和信息资产（Application and Information asset）
整合已有应用（应用和信息访问服务）
可接入服务
事件发现服务
整合新开发的应用（业务应用服务）
组件服务
核心服务
接口服务
整合客户和业务伙伴（B2C/B2B）（伙伴服务）
社区服务
文档服务
协议服务
控制服务
概念
（Control Service）
包括实现人（People）、流程（Process）和信息（Information）集成的服务，以及执行这些集成逻辑的能力
数据整合（信息服务）
联邦服务
提供将各种类型的数据聚合的能力
复制服务
提供远程数据的本地访问能力
通过自动的实时复制和数据转换，在本地维护一个数据源的副本
转换服务
搜索服务
流程整合（流程服务）
编排服务
通过预定义的流程逻辑，控制流程中业务活动的执行，并帮助业务流程从错误中恢复
事务服务
保证流程执行中的事务特性（ACID）
短流程常采用传统的“两阶段提交”技术
两阶段提交协议（Two-Phase Commit，2PC）是分布式系统中保证事务原子性的经典协议，主要用于协调多个参与节点（如数据库）共同完成或放弃一个事务。 核心角色 协调者（Coordinator）：事务的发起者和决策者 参与者（Participant/Cohort）：事务的实际执行者（通常是资源管理器） 两个阶段 准备阶段（Prepare Phase） 提交/回滚阶段（Commit/Rollback Phase） 协议流程 第一阶段：准备阶段 协调者向所有参与者发送PREPARE请求 每个参与者执行事务操作（但不提交），记录undo/redo日志 参与者回复投票结果： YES：准备成功，可以提交 NO：准备失败，需要回滚 第二阶段：提交/回滚阶段 根据第一阶段的投票结果： 全部参与者返回YES： 协调者发送COMMIT指令 参与者完成事务提交 参与者回复ACK 协调者收到所有ACK后完成事务 任一参与者返回NO或超时： 协调者发送ROLLBACK指令 参与者执行回滚操作 参与者回复ACK 协调者收到所有ACK后终止事务
长流程常采用“补偿”的方法
补偿事务(Compensating Transaction) 核心补偿模式 1. Saga模式 原理：将长事务拆分为多个本地事务，每个事务提供对应的补偿操作 实现方式： 编排式(Choreography)：通过事件驱动，各服务自主决定后续操作 编制式(Orchestration)：由中央协调器控制流程 2. TCC模式(Try-Confirm-Cancel) 三阶段操作： Try：预留资源（如冻结库存） Confirm：确认执行业务（实际扣减） Cancel：取消预留（释放资源） 特点： 需要业务逻辑显式支持三阶段 比Saga一致性更强 3. 事件溯源+补偿 原理： 使用事件流记录所有状态变更 通过"反向事件"实现补偿
人工服务
用户访问整合（交互服务）
交付服务
体验服务
资源服务
连接服务
概念
（Connectivity Service）
通过企业服务总线，提供分布在各种架构元素中服务间的连接性
企业服务总线
（Enterprise Service Bus，ESB）是过去消息中间件的发展
基本特征、能力
描述服务的元数据和服务注册管理
在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式，如同步模式、异步模式等
发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者
高级能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等
业务创新和优化服务
概念
（Business Innovation and Optimization Service）
用于监控业务系统运行时服务的业务性能，根据业务性能和变化，采取措施适应变化的市场
公共事件框架服务
采集服务
监控服务
开发服务
概念
（Development Service）
从需求分析，到建模、设计、开发、测试和维护等全面的工具支持
建模服务
设计服务
实现服务
测试服务
IT 服务管理
概念
（IT Service Management）
支持业务系统运行的各种基础设施管理能力或服务
安全和目录服务
系统管理和虚拟化服务
SOA 主要协议和规范
相关标准
大多以“WS-”作为前缀，统称“WS-*”
基本协议
图示
UDDI
统一描述、发现和集成协议
是一个广泛的、开放的行业计划，它使得商业实体能够彼此发现
定义它们怎样在 Internet 上互相作用，并在一个全球的注册体系架构中共享信息
WSDL
（Web Services Description Language，Web 服务描述语言）
是一个用来描述 Web 服务和说明如何与 Web 服务通信的 XML 语言
描述 Web 服务的三个基本属性
服务做什么
服务所提供的操作（方法）
如何访问服务
和服务交互的数据格式及协议
服务位于何处
协议相关的地址，如 URL
SOAP
在分散或分布式的环境中交换信息的简单协议，基于 XML
组成
SOAP 封装（Envelop）
SOAP 编码规则（Encoding Rules）
SOAP RPC 表示（RPC Representation）
SOAP 绑定（Binding）
REST
Representational State Transfer（（资源）表述性状态转移）
RESTful
REST 式的
是对遵循 REST 设计思想同时满足设计约束的一类架构设计或应用程序的统称
资源
Resource
REST 以资源为中心构建
资源可以是一个订单，也可以是一副图片
互联网中一切暴露给客户端的事物都可看作一种资源
一个资源可设计多个 URI，但一个 URI 只能对应一种资源
表述
Representational
描述资源在 Web 中某一个时间的状态
客户端和服务端借助 RESTful API 传递数据，实际就是在进行资源表述的交互
状态转移
State Transfer
应用状态
对某个时间内用户请求会话相关信息的快照，保存在客户端，由客户端自身维护，可以和缓存配合降低服务端并发请求压力
资源状态
对某个时间资源请求表述的快照，保存在服务端
状态转移借助 HTTP 方法实现
如 GET、POST、DELETE
超链接
通过在页面中嵌入链接和其他资源建立联系
SOA 设计模式
设计原则
无状态
单一实例
明确定义的接口
自包含和模块化
粗粒度
服务之间的松耦合性
重用能力
互操作性、兼容和策略声明
服务注册表模式
服务注册表
(Service Registry)
主要在 SOA 设计时使用
提供一个主控制点，或称为策略执行点（Policy Enforcement Point，PEP））
主要支持的 SOA 治理功能
服务注册
应用开发者，也叫服务提供者，向注册表公布他们的功能
服务位置
服务应用开发者，帮助他们查询注册服务，寻找符合自身要求的服务
服务绑定
服务的消费者利用检索到的服务合同来开发代码，开发的代码将与注册的服务绑定、调用注册的服务以及与它们实现互动
企业服务总线模式
思想
提供一种标准的软件底层架构，各种程序组件能够以服务单元的方式插入到该平台上运行，并且组件之间能够以标准的消息通信方式来进行交互
交互过程
例
服务请求者触发一次交互过程
产生一个服务请求消息
将该消息按照 ESB 的要求标准化，然后标准化的消息被发送给服务总线
ESB 根据请求消息中的服务名或接口名进行目的组件查找
将消息转发至目的组件
并最终将处理结果逆向返回给服务请求者
不是点对点的直接交互模式，是事件驱动的消息交互模式，解耦了组件间的依赖关系
连接在总线上的组件，只需要向服务总线发出请求消息，即可获得所需服务
ESB 以中间件方式，提供服务容错、负载均衡、QoS 保障和可管理功能
微服务模式
架构设计模式方案
聚合器微服务
调用多个微服务实现系统应用程序所需功能
形式
将检索到的数据信息进行处理并直接展示
对获取到的数据信息增加业务逻辑处理后，再进一步发布成一个新的微服务作为一个更高层次的组合微服务
代理微服务
是聚合器模式的一个变种
客户端根据实际业务需求差别，选择调用不同功能的微服务
分支微服务
是聚合器模式的一个扩展
客户端或服务允许同时调用两个不同的微服务链
链式微服务
客户端或服务在收到请求后，会返回一个经过合并处理的响应
例：
服务 A 收到请求后调用服务 B，服务 B 调用服务 C，依次往下游发送请求。对结果合并处理后，作为请求响应返回上游服务调用者
数据共享微服务
在单体架构应用到微服务架构的过渡阶段允许使用
异步消息传递
将消息写入一个消息队列中，实现业务逻辑以异步方式运行，从而加快系统响应速度
常用消息队列
ActiveMQ、RabbitMQ、RocketMQ、Kafka 等
SOA 实施
选择 SOA 解决方案
尽量选择能进行全局规划的方案
用户评估
已有系统
能用多少
多少需要改造
需要上哪些新系统
将来的系统如何满足需求
投入的资本有多少
选择时充分考虑企业自身的需求
从平台、实施等技术方面进行考察
业务流程分析
建立服务模型
自顶向下分解法
自上而下的领域分解方式
从业务着手进行分析
选择端到端的业务流程进行逐层分解至业务活动
并对其间涉及的业务活动和业务对象进行变化分析
业务目标分析法
自底向上分析法
利用已有资产来实现服务
“遗留资产分析”
将已有可复用模块包装为服务
建立业务流程
建立业务对象
建立服务接口
服务接口通常应包含多个操作
操作应语义上相关
服务之间的交换可以为
有状态
当服务提供者保留关于在之前的操作调用期间，服务使用者和服务提供者之间交换的数据信息时，服务之间进行的是有状态（或对话型）交换
例：
先调用 setCustomerNumber 设置客户编号，再调用 getCustomerInfo 获取之前客户编号对应的客户信息
无状态
建立业务流程