Imported from junjingjesse/jjj-skills (skills/JJJ-architecture-service-oriented-architecture/SKILL.md). Install upstream with npx skills add junjingjesse/jjj-skills --skill JJJ-architecture-service-oriented-architecture. Copyright stays with the author.

面向服务架构技能 (Service-Oriented Architecture)

快速开始

当用户触发此技能时，直接说：

请描述你的系统集成或服务化问题，我来帮你分析SOA架构、Web服务标准或RESTful设计。

然后等待用户输入。

SOA概述

什么是面向服务架构 (SOA)

SOA通过将功能拆解为独立服务，实现软件的模块化、可复用性和灵活组合，从而提升开发效率和系统可扩展性。

现实类比：

• 洗衣：自己洗 vs 洗衣店服务
• 做饭：自己做 vs 餐馆/外卖服务
• 出行：自己开车 vs 打车服务

核心角色：

服务原则 (Service Principles)

高效可复用的服务需遵循以下原则：

1. 模块化与低耦合 (Modular & Loosely Coupled)

• 服务内部实现与外部请求分离
• 只暴露必要接口
• 请求通过符合接口定义的通信方式发送

2. 可组合性 (Composable)

• 服务应能组合形成应用或其他服务
• 前提是服务必须模块化
• 类比面向对象编程中的对象组合

3. 平台与语言独立性 (Platform- & Language-Independent)

• 一个服务可由Java编写，请求方可能使用Ruby
• 通过通信标准与协议实现独立性
• 核心在于强制执行良定义的通信标准

4. 自描述性 (Self-Describing)

• 服务应说明如何与其交互
• 包括服务输入/输出定义
• 使用正式标准：WSDL描述服务

5. 自宣传性 (Self-Advertising)

• 潜在客户端必须了解可用服务
• 内部组织可通过自定义目录管理服务
• 分布式Web服务使用UDDI标准

记忆口诀：模块化+可组合→灵活复用；跨平台/语言独立→可互操作；自描述+自宣传→易发现与使用

Web系统演进

Internet与Web的区别

• ARPANET (1969)：Internet前身，用于发送少量数据的计算机网络
• Tim Berners-Lee (1990)：提出World Wide Web，灵感来源于超文本

核心区别：Internet ≠ Web，Web建立在Internet之上

Web系统进化链

静态网页 → 动态网页 → Web应用 → Web服务

分层Web架构

典型层次划分

[表现层/Presentation Tier] - Web浏览器/服务器
         ↓
[应用层/Application Tier] - 处理功能逻辑
         ↓
[数据层/Data Tier] - 数据库/文件系统

静态网页层次

浏览器 → Web服务器 → 数据层(仅读HTML)

动态网页层次

浏览器 → Web服务器 → 应用层(生成HTML) → 数据层
         ↓
    可调用外部Web服务

数据交换格式

HTML vs XML vs JSON

JSON数据结构示例：

// 对象
{"name": "John Doe", "age": 15}

// 数组
[
  {"name": "John", "age": 15},
  {"name": "Jane", "age": 16}
]

HTTP协议

HTTP请求结构

请求行 + 请求头 + 空行 + 消息体(可选)

请求行：请求方法 + URI + 协议版本

必需请求头：

• Host：主机名/IP
• Accept：可接受的响应内容类型

消息体存在时必需：

• Content-Length：字节数
• Content-Type：类型

HTTP响应结构

状态行 + 响应头 + 空行 + 消息体(可选)

状态行：协议版本 + 状态码（如200 OK）

HTTP请求方法

URL编码

• 特殊字符：用%加两位十六进制表示
• 空格：%20或+
• 查询字符串：=指定值，&连接多个参数

HTTP无状态特性

• HTTP不跟踪客户端请求历史
• Cookie：服务器发送Cookie给客户端存储，每次请求更新

JavaScript与DOM

JavaScript作用

• 修改网页元素、属性、样式和内容
• 实现动态用户交互
• 部分处理在客户端完成，减少服务器请求

DOM操作

// 获取所有图片元素
document.getElementsByTagName("img")

// 给每个图片添加点击监听器
for (img in images) {
    img.addEventListener("click", function() {
        // 切换缩放状态 25% ↔ 100%
    })
}

中间件与RPC

中间件 (Middleware)

定义：在环境不同的应用之间提供标准化接口的架构组件

作用：

• 管理客户端与服务器的通信
• 类似于中介者设计模式，但规模更大
• 封装业务逻辑、客户端请求分发、身份认证

远程过程调用 (RPC)

概念：客户端调用服务器上的过程，就像调用本地函数一样

历史：1980年代，Birrell与Nielson开发，提供透明的远程调用机制

执行流程：

1. 客户端调用过程，参数传给客户端存根(Client Stub)
2. 客户端存根封装参数(Marshalling)到标准化消息格式
3. 通过绑定信息发送消息到服务器
4. 服务器存根接收消息，解封装(Unmarshalling)
5. 服务器存根调用服务器端过程并传递参数
6. 服务器将结果封装返回给客户端存根
7. 客户端存根解封装结果并返回给客户端

绑定方式

同步 vs 异步

• 同步：客户端等待响应，执行暂停
• 异步：客户端无需等待，可继续处理其他任务，提高并行性

Object Broker与CORBA

Object Broker架构

CORBA (Common Object Request Broker Architecture)：

• 制定者：OMG（Object Management Group）
• 核心目标：
  1. 语言无关：支持多种面向对象语言
  2. OS无关：客户端和服务器操作系统可不同
  3. 分布式对象：跨网络或跨进程的对象分布

CORBA核心组件

IDL、Stub与Skeleton

静态绑定 vs 动态绑定

动态绑定组件：

• Interface Repository：存储broker对象的IDL定义
• Dynamic Invocation Interface (DII)：客户端动态浏览与构造方法
• Naming Service：根据名称检索对象
• Trading Service：根据对象属性检索对象

第一代Web服务 (SOAP/WSDL/UDDI)

Web服务基础

Web服务：基于Web技术暴露和访问的服务，支持跨平台和跨语言的机器对机器通信

SOAP (Simple Object Access Protocol)

定义：基于XML的通信标准，用于服务请求者和服务提供者之间的消息传递

SOAP消息结构：

<soap:Envelope>
  <soap:Header>...</soap:Header>  <!-- 可选 -->
  <soap:Body>...</soap:Body>     <!-- 必须 -->
</soap:Envelope>

两种风格：

四种消息模式：

WSDL (Web Services Description Language)

定义：描述Web服务接口的XML标准，类似方法签名

WSDL四大组件：

WSDL自动生成绑定代码：服务请求者可读取WSDL自动生成代码调用服务

UDDI (Universal Description, Discovery, Integration)

定义：Web服务的发布与发现标准

三页信息分类：

四大数据结构：

服务发布与发现流程：

提供者发布 → UDDI注册表 → 请求者搜索 → 获取WSDL → 生成绑定 → SOAP调用 → 返回响应

服务组合 (Service Composition)

组合服务定义

当一个服务由其他服务构成时，即称为组合服务

服务组合层级

底层服务 → 中层组合服务 → 高层组合服务 → 对外接口

Composition vs Coordination

BPEL (Business Process Execution Language)

定义：将兼容的服务组合成业务流程的标准

功能：

• IF/THEN/ELSE逻辑
• 条件分支与流程控制
• 将低层功能封装为高层服务

汽车制造商案例：

Part Order Service组合：
1. 查询仓库库存(Warehouse Service)
2. IF 库存>0 → 下单并返回确认
3. ELSE → 调用外部供应商服务查询价格 → 返回确认

REST架构

REST五大约束

REST请求与响应示例

请求 (XML)：

<request method="PUT" resource="/shoppingcart/1234">
  <item>coffee</item>
</request>

响应 (JSON)：

{
  "shoppingCartId": 1234,
  "items": ["coffee", "tea", "cake", "sandwich", "water"],
  "total": 70.51,
  "cacheControl": "max-age=30"
}

RESTful API设计

设计原则

常用HTTP状态码

分页与过滤

• 过滤：/courses?department=computing
• 分页：?offset=0&limit=20

微服务架构 (Microservices)

微服务定义

微服务是一种将应用功能拆分为独立、可组合的小服务的架构风格

微服务特点

微服务 vs 单体 vs SOA

微服务优势

1. 灵活技术选型：各服务可用不同语言、框架
2. 易扩展与高可维护性：单个服务可通过复制实例扩展
3. 独立升级与修复：逐个服务更新，不影响其他服务
4. 小团队并行开发：每个团队负责小功能模块
5. 促进代码复用：功能模块化，可随需组合

微服务挑战

1. 分布式系统复杂性：需要中央管理协调
2. 测试复杂：服务间交互复杂，难以复现bug
3. 故障处理：某服务失败时，依赖服务需具备容错能力
4. 通信开销：HTTP、XML等通信存在性能开销

微服务应用示例

餐厅指南应用：

[UI Service]
    ├── HTTP → [Restaurant Catalog Service]
    ├── HTTP → [Reservation Service]
    └── HTTP → [Review Service]

图书馆应用：

[Search Service] ←HTTP→ [Recommendation Service] ←HTTP→ [Rating Service]
     独立数据库              独立数据库              独立数据库

模式对比总结

SOAP vs REST

微服务 vs SOA

常见问题

Q: 什么时候用SOAP vs REST？

• 企业级集成、需要正式契约 → SOAP
• 轻量级API、移动应用 → REST

Q: 微服务适合什么场景？

• 大规模应用需要快速迭代
• 不同功能需要独立扩展
• 团队规模较大需要并行开发

Q: 如何选择服务分解粒度？

• 单一业务能力
• 独立数据管理
• 明确接口边界
• 可独立部署

记忆口诀汇总