跳到正文Seminar Week 5 Summary · Jimmy Huang's Blog也就是说，这周是把“运行层”往“应用设计层”推进的一周：
不只是会把东西部署到云上；
还要理解一个云应用为什么会被设计成多个服务；
以及这些服务如何通过统一接口和统一数据格式协作。
1. 为什么需要 Web 服务
Web 服务是什么
为什么重要
不同系统、不同编程语言、不同平台之间，本来很难直接互相理解。
Web 服务提供了一种更标准、更结构化的互操作方式（Interoperability）。
它支持常见的增删改查（Create, Read, Update, Delete, CRUD）类操作。
它使得：一个组织里的程序
可以自动和另一个组织里的服务器程序通信
不需要人手动参与
和前面几周的关系
Web 服务解决的是：应用怎么对外提供能力
服务与服务之间怎么交流
一个大系统怎么由多个小服务组合起来
可以这样理解
2. 为什么应用经常不做成一个大单体，而要拆成多个服务
3. 外部数据表示（External Data Representation）与编组（Marshalling）
所以，系统之间通信时，就需要一个大家都认得的“外部表示方式”。
关键概念
外部数据表示（External Data Representation）
可以这样理解
为什么重要
4. XML（Extensible Markup Language）
XML 是什么
XML 的关键特点
XML 的缺点
文本冗长，消息通常比较大。
传输成本更高。
解析成本也更高。
存储占用更大。
元素（Elements）与属性（Attributes）
元素（Element）
属性（Attribute）
XML 命名空间（Namespace）与模式（Schema）
命名空间（Namespace）
我现在声明一个前缀 pers，它对应的命名空间是 http://www.cdk4.net/person
pers 是简称
后面的 URL 是这个“名字体系”的唯一标识
<person id="123">
<name>Smith</name>
<place>London</place>
<year>1934</year>
</person>
const person = {
id: 123,
name: "Smith",
place: "London",
year: 1934
}
XML Schema
XML Schema 用来规定：哪些元素可以出现
哪些属性可以出现
它们的数据类型应该是什么
5. JSON（JavaScript Object Notation）
JSON 是什么
JSON 是一种轻量级数据交换格式。
它用于存储和交换数据。
它是 XML 更简洁、更加常用的替代方案之一。
JSON 的关键特点
JSON 的基本结构
JSON 主要是：对象（object）
数组（array）
键值对（key-value）
常见值类型包括：string
number
object
array
true / false
null
示例
6. JSON vs XML
XML 更强调结构描述与规范性
JSON 更强调简洁、高效和 API 友好
7. 服务之间如何通信
通信模式（Communication Patterns）
同步通信（Synchronous Communication）
发送和接收通常都是阻塞的（blocking）。
发送方发出消息后，要等待接收方那边对应接收动作。
接收方如果没有消息到达，也会等待。
异步通信（Asynchronous Communication）
发送通常是非阻塞的（non-blocking）。
消息拷到本地缓冲区后，发送方就可以继续做别的事。
实际传输可以并行进行。
这两者的区别
消息传输（Message Transmission）
为什么端口重要
同一台服务器上可以跑很多服务。
只知道机器地址还不够，还必须知道要找哪一个服务。
8. 服务如何被引用：URI、URL、URN 与 Endpoint
URI
统一资源标识符，是最广义的概念，用来唯一标识一个资源。
URL
统一资源定位符，是 URI 的子集，不仅标识资源，还提供资源的位置和访问方式。
http://www.example.com/book
https://api.github.com/events
file:///home/user/file.txt
URN
统一资源名称，是 URI 的子集，只提供资源名称或编号，不提供资源位置。
Endpoint
Web 服务真正暴露给客户端访问的地址，通常是一个 URL。
https://api.github.com/events
https://school.example.com/api/login
https://api.weather.com/current?city=Melbourne
本周需要记住的点
9. Web 服务的组合（Combination of Web Services）
这部分在讲什么
为什么重要
可以这样理解
单个服务像一个“能力模块”。
多个服务拼在一起，就能形成一个完整业务流程。
10. Travel Agent 案例：服务组合是怎么落地的
场景流程
旅行代理服务（Travel Agent Service）的流程大致如下：
可用的话，收取订金（deposit）。
返回预订号（reservation number）作为确认。
在最终付款前，用户还可以修改或取消预订。
图示真正表达的逻辑
这个例子说明了什么
这和 SOA 的关系
这就是一个非常典型的：多服务协作
通过组合形成更大业务能力
面向服务架构思路
11. 服务组合后的要求与挑战
并发路径、分支路径和循环有些步骤可以并行做；
有些步骤要根据条件走不同分支；
有些流程可能需要重复执行。
12. SOAP-based Web Services
SOAP 是什么
SOAP 的典型特点
一个典型 SOAP 系统怎么工作
客户端根据 WSDL 组织 SOAP 请求消息。
服务端处理后，返回 SOAP 响应消息。
SOAP 消息格式（Message Format）
SOAP 消息通常被包在一个 Envelope（信封） 里，内部主要分成两部分：
SOAP 请求消息怎么读
意思就是：
- 调用 exchange
- 给它传两个参数：
- Hello
- World
SOAP 响应消息怎么读
这说明 SOAP 不只是“返回结果”，还比较强调结构化错误描述。
SOAP over HTTP
HTTP Header 可以告诉服务器：目标地址（endpoint）
要执行的 action
HTTP Body 才真正放 SOAP 消息。
也就是说：HTTP 是运输层外壳
SOAP 是里面那份正式业务消息
WSDL 是什么
这个服务有哪些操作？
输入输出是什么？
用什么协议通信？
地址在哪里？
WSDL 的主要作用
作为客户端和服务器之间的约定基础。
可描述：操作（operations）
消息（messages）
类型（types）
绑定方式（bindings）
服务地址（services）
WSDL 结构可以这样抓
抽象层（Abstract）
说明“这个服务做什么”：
具体层（Concrete）
说明“这个服务怎么访问、在哪里访问”：
更直白地说
Abstract：功能定义
Concrete：访问方式和地址
UDDI 是什么
这说明在 SOAP 生态里，服务发现（service discovery）本身也是重要的一环。
SOAP 这一整块的整体印象
所以它很适合：
- 规则强
- 接口清晰
- 企业集成要求高
13. REST（Representational State Transfer）
REST 是什么
REST 的核心想法
RESTful Web Services 是什么
REST 的核心原则
1. 资源是核心抽象
系统不是先想“我有哪些函数”；
而是先想“我有哪些资源”。
2. 每个资源都应该可被 URI 定位
3. 使用统一且受约束的方法集
主要依赖标准 HTTP 方法。
不再为每个业务动作都发明一套完全不同的调用形式。
4. 交换的是资源的表示（Representation）
5. 无状态（Stateless）
“无状态”最容易误解的地方
无状态不等于“系统里完全没有状态”。
它真正强调的是：服务器不替客户端长期保存会话上下文
每次请求都尽量自包含
例如：
- 身份认证信息
- Cookies
- 请求上下文
REST 的优缺点
优点
缺点
每次请求可能都要带更多上下文信息，产生数据开销
服务器每次都要根据请求内容重新构造处理上下文
14. REST 的统一接口：HTTP 方法怎么理解
先记两个术语
四个最重要的方法
GET：查很多次，资源不变，所以 safe 且 idempotent
DELETE：删一次和删很多次，最终都是“没了”，所以 idempotent，但它会修改资源，所以不 safe
POST：常用于创建/提交，不保证重复执行结果一样，所以通常不是 idempotent，也不 safe
其他较少使用的方法
为什么 REST 这种做法有优势
可以这样理解
URI：你要操作哪一个资源
HTTP 方法：你想对这个资源做什么
响应内容：服务器把这个资源当前表示返回给你
15. SOAP 与 REST：这一周最该抓住的区别
复习时不要混淆
16. 面向服务架构（Service-Oriented Architecture, SOA）
SOA 是什么
SOA 的关键思想
为什么 Web 服务和 SOA 关系很近
SOA 的价值
给企业或组织提供更灵活的软件架构。
让不同系统之间更容易互通。
允许把已有服务重新组合，形成新的业务能力。
Mashup 是什么
Mashup 指的是：第三方开发者
把两个或更多已有服务组合起来
形成一个新服务
17. 微服务（Microservices）
微服务是什么
微服务是一种应用架构方式。
它把应用中的功能进一步拆成更细的小服务。
本周课件给出的核心特征
每个应用功能都可以成为自己的服务。
这些服务通常运行在容器中。
微服务的优点
松耦合
可复用
更专业化
更敏捷
更可扩展
更有韧性（resilient）
为什么说它是 Cloud Native 的做法
因为它很适合和这些东西配合：容器
Kubernetes
API 通信
独立扩缩容
不同组件使用不同技术栈
微服务最实际的价值
可以这样理解
和前几周的关系
设计应用结构
把功能拆成服务
服务通过 Web API / Web Service 通信
每个服务容器化
放到 Kubernetes 中编排和扩缩容
所以这周并不是孤立知识点，而是前面内容的“应用设计补全”。
Summary :
Envelope
├── Header（可选）
└── Body（业务消息）
<person>
<name>Smith</name>
</person>
<person id="123456789">
<name>Smith</name>
<place>London</place>
<year>1934</year>
</person>
<person pers:id="123456789" xmlns:pers="http://www.cdk4.net/person">
<pers:name>Smith</pers:name>
<pers:place>London</pers:place>
<pers:year>1934</pers:year>
</person>
<pers:person xmlns:pers="http://www.cdk4.net/person" pers:id="123456789">
<pers:name>Smith</pers:name>
<pers:place>London</pers:place>
<pers:year>1934</pers:year>
</pers:person>
<xsd:schema xmlns:xsd="URL of XML schema definitions">
<xsd:element name="person" type="personType"/>
<xsd:complexType name="personType">
<xsd:sequence>
<xsd:element name="name" type="xs:string"/>
<xsd:element name="place" type="xs:string"/>
<xsd:element name="year" type="xs:positiveInteger"/>
</xsd:sequence>
<xsd:attribute name="id" type="xs:positiveInteger"/>
</xsd:complexType>
</xsd:schema>
type Person = {
id: number
name: string
place: string
year: number
}
{
"employees": [
{ "firstName": "John", "lastName": "Doe" },
{ "firstName": "Peter", "lastName": "Jones" }
]
}
最外层对象
└── employees
└── 数组
├── 第1个员工对象
│ ├── firstName: John
│ └── lastName: Doe
└── 第2个员工对象
├── firstName: Peter
└── lastName: Jones
<env:Envelope>
<env:Body>
<m:exchange>
<m:arg1>Hello</m:arg1>
<m:arg2>World</m:arg2>
</m:exchange>
</env:Body>
</env:Envelope>