跳到正文ChatGPT 说 · Jimmy Huang's BlogChatGPT 说
本页目录· 50 条
1. 本周 Seminar 总览
这周 Seminar 的核心，不是在教你“怎么部署 Kubernetes”了，而是在前几周已经学过的 虚拟化 → 容器 → 容器编排 基础上，再往前补上“应用应该怎么设计、服务之间怎么通信”这一层。老师其实是在帮你把整条技术链补完整：你不仅要会把东西跑起来，还要知道为什么现代云应用常常被拆成很多服务，以及这些服务之间靠什么交流。
这周课件主要讲了几个大块：Web Service 的定义、数据表示格式（XML / JSON）、服务组合案例、SOAP、REST、SOA，以及 microservices 的基本思想。其中老师明显把 REST、JSON、服务拆分思路、以及它们和作业/后续开发的关系 讲得更重；而 SOAP 和 WSDL 的很多页是 home reading/self-reading，属于要知道，但不是讲课时最重点展开的部分。
更直白地说，这周是在回答这几个问题：
“为什么一个大应用常常要拆成多个服务？”
“多个服务怎么互相说话？”
“为什么云环境里常用 JSON、REST？”
“这些东西和你前面学的容器、Kubernetes、Assignment 怎么接起来？”
2. 核心知识点总结
2.1 Web Service 是什么
课件给出的定义是：Web Service 为客户端和远程服务器之间提供一个通用接口，通常通过 HTTP 上的 request / reply 来交互，消息内容用 XML 或 JSON 表示，并支持跨系统、跨组织的互操作。它的目标不是单纯“能联网”，而是让不同系统之间可以比较规范地交换数据、完成 CRUD 等操作。
怎么理解：
你可以把 Web Service 理解成“程序对外开放的沟通窗口”。不是给人点网页用的，而是给别的程序、别的服务来调用的。
比如一个订酒店服务、一个订机票服务、一个支付服务，它们不需要人工中转，而是可以通过 Web Service 自动通信。
为什么重要：
因为云计算和分布式系统里，系统通常不是一个整体程序，而是很多组件分别运行。要让它们协同工作，就必须有统一的通信方式。老师也明确说了，Web services enable SOA。
和本课程的关系：
前几周你学的是“怎么把应用放到容器里、放到 Kubernetes 里”，这周学的是“应用内部应该拆成什么样、这些部分怎么交流”。这是从“部署层”走到“架构层”。
2.2 为什么要把应用拆成多个服务，而不是做成一个大单体
这是 transcript 里老师讲得很明确、很生活化的一段。老师让大家讨论：为什么不把所有功能都塞进一个 monolithic application，而要拆成多个 services。学生和老师一起总结出的点包括：
多个服务像多个独立零件，小零件坏了可以单独换，小零件也可以拿去别的地方继续用。老师还专门用了“像原子一样的小服务，之后可以组合成新的东西”这个比喻。
这是后面理解 SOA、microservices、REST API、容器化部署 的前提。如果你不先接受“应用应该拆开”，后面的内容会觉得很抽象。
2.3 数据表示与 Marshalling / Unmarshalling
这部分是这周一个非常基础、但很关键的概念。课件讲的是：不同系统内部的数据表示方式可能不同，所以在传输之前，要把数据转换成一个大家都同意的外部格式；发送端做 marshalling，接收端做 unmarshalling。
老师在 transcript 里用“人和人用共同语言交流”的例子讲得很好：
他的大脑先用母语组织意思，再“翻译”成英语说出来，这就像 marshalling；接收者再把英语转换回自己能理解的内部表示，这就是 unmarshalling。
因为 Web Service 不是同一台机器内部函数调用，而是不同机器、不同语言、不同系统之间通信。没有这一步，互操作做不起来。
很多人会把它当成“只是序列化”。其实在这门课里你更应该把它理解成：
为了跨系统沟通，把内部表示变成共享表示，再从共享表示变回内部表示。
2.4 XML：是什么、优点、缺点
课件里把 XML 定义为一种 markup language，由 W3C 定义，用标签来描述数据的逻辑结构；它可扩展、自描述、平台无关、人可读。
XML 是文本型的，消息会比较大，所以会增加传输、存储和处理开销。 这也是为什么它在分布式/云场景里并不总是最优。
XML 很像“很正式、写得很完整的结构化说明书”。
2.5 JSON：是什么、为什么现在更常见
课件定义 JSON 为 lightweight data-interchange format，是存储和交换数据的语法，比 XML 更轻量、也更容易使用。它是文本格式、语言无关。
在分布式系统和云计算场景里，大家常常更偏向 JSON，不是因为 XML “错了”，而是因为 JSON 更紧凑，消息更小，带宽占用更低，处理成本也更低。
如果 XML 像“正式表格 + 说明文字”，那 JSON 更像“结构清晰的对象字典”。
你后面看到的大多数 Web API、REST API，都默认围着 JSON 转。这个点本周一定要吃透。
2.6 URI / URL / Endpoint：服务怎么被找到
老师在 transcript 里专门补充解释了命名问题：
在分布式系统中，不同机器、不同系统必须有一个统一方法来“定位资源”，所以需要 URI。而 URL 是 URI 的一种，强调“位置”，通常包含协议、域名和路径。
URI：统一资源标识
URL：能告诉你资源“在哪儿”
Endpoint：服务暴露给外界访问的具体地址
服务不是只要存在就行，还要能被发现、能被调用。这和你后面理解 REST 的“资源 + URI”是直接相连的。
2.7 Travel Agent 场景：服务组合的经典例子
课件用 travel agent 场景来说明多个服务如何协同：
客户端不是自己分别去问航班、酒店、租车，而是先问一个 travel agent service。这个服务再去聚合多个底层服务的信息，返回价格和可用性；用户还能 refine query、下预订、拿 reservation number，后续还能修改或取消。
这其实就是 service composition / mashup / orchestration 思维。
2.8 SOAP：你要知道它是什么，但本周不是最核心实战重点
SOAP-based web services 这部分主要是 self-reading / home reading。
2.9 WSDL：服务合同/说明书
WSDL 在课件里被定义为 Web Services Description Language，是一种 service description。它描述服务提供什么操作、输入输出是什么、用什么协议、服务地址在哪。
有哪些操作
传什么参数
回什么结果
在哪里访问
用什么协议访问
2.10 REST：现代 Web API 的主流思想
它起源于 Roy Fielding 2000 年的博士论文，是一种受约束的风格，客户端通过 URL + HTTP methods（GET, PUT, DELETE, POST） 来操作资源；RESTful Web Services 使用一组统一、预定义、无状态的操作访问资源表示。REST 是设计准则，不是系统的物理结构。
不是到处定义一堆随意方法名
而是围绕资源，用固定 HTTP 动作去操作
这也是为什么 REST API 看起来都比较规整。
2.11 REST 的统一接口：GET / PUT / DELETE / POST
GET：只读，idempotent，safe
PUT：插入或更新，idempotent，不 safe
DELETE：删除资源，idempotent，不 safe
POST：既不 idempotent，也不 safe
另外，REST 的好处包括：不必设计太多花哨方法签名、HTTP 广泛支持、可缓存、可扩展。
GET：查很多次，资源不变，所以 safe 且 idempotent
DELETE：删一次和删很多次，最终都是“没了”，所以 idempotent，但它会修改资源，所以不 safe
POST：常用于创建/提交，不保证重复执行结果一样，所以通常不是 idempotent，也不 safe
2.12 SOA：面向服务的整体思路
一种设计原则集合，分布式系统由一组 loosely coupled services 构成；这些服务可以被发现、通信、被编排，来提供更强的功能；Web services 是实现 SOA 的主要方式之一。SOA 还鼓励 mashup，把多个已有服务组合成新服务。
SOA 不是一个具体框架，而是“系统应该用服务来组织”的思想。
这是从“单个 API / 单个 service”上升到“整个系统如何设计”的层面。
2.13 Microservices：SOA 在云原生中的更细粒度实践
这和 transcript 前面讨论“为什么拆服务”是直接呼应的。老师其实是在先讲动机，再给你正式术语。
3. 老师强调的重点
重点1：这周内容是把“部署”前面的“架构设计层”补上
老师多次强调，前几周你已经学了 VM、container、orchestration；现在要学的是 software architecture、service-oriented architecture、microservices、RESTful APIs，这样你的“技术栈才完整”，也才能真正支撑 assignment。这个不是随便一讲，而是整节课的主线。
重点2：为什么要拆服务，而不是做单体
老师让学生现场讨论这个问题，而且来回追问，说明这是明显重点。最后不断落到几个关键词：易维护、易修补、故障隔离、部分失败不拖垮全局、服务复用、后面会过渡到 microservices。这类内容很适合考“解释型”题。
重点3：JSON 和 XML 的区别，尤其为什么云里常更偏向 JSON
JSON 更轻、更紧凑、更适合消息传输；XML 不是不能用，而是通常更大、更耗带宽、更耗处理。这个判断非常像 quiz / exam / short answer 题。
重点4：Marshalling / Unmarshalling
老师用“脑子里先想母语，再翻译成英语说出去”的例子来解释，这是整场里少数被讲得特别具体、特别久的抽象概念。通常老师会这么讲，说明他知道学生容易卡在这里。
重点5：REST 的 HTTP 方法语义
GET / PUT / DELETE / POST 的含义，以及 safe / idempotent 的区别，是 REST 里最常考、也最容易混淆的一块。课件直接单独列页展示，很像要你会判断、会区分。
重点6：Service 提供稳定入口，背后怎么扩容用户不需要知道
老师用 FIT5225 单元邮箱举例，解释为什么 service 要给用户一个稳定入口，而后面由系统自己处理扩容、负载分发。这个例子把 Kubernetes service 和更一般的“服务接口”思想连起来了，属于很强的口头重点。
重点7：这周内容和 assignment 是直接相连的
老师明确说过，理解应用怎么拆服务、怎么容器化、怎么部署到 Kubernetes、怎么在上面跑 service，这样“stack is full and ready”，这和 assignment 是直接关联的。
4. transcript 里补充的重要信息
4.1 老师给了一个很实用的“开发—部署—调试顺序”
这不是课件里写得这么清楚的，但 transcript 里讲得很完整：
老师还反复说：不要跳步骤，不然出了问题你根本不知道是哪一层坏了。 这对你做作业很实用。
4.2 老师把“service”讲成了“稳定公共入口”
课件里只说 service 提供接口，但 transcript 里老师举了单元邮箱的例子：
用户只需要记住一个邮箱，不需要知道后面是谁在处理、有没有扩容、是不是换人了。这个比喻非常有助于理解“为什么 service 要稳定，为什么后端变化对用户透明”。
4.3 “extra reading”和“home reading”不一样
4.4 一个服务不一定只面对终端用户
老师口头补充说过，client 不一定永远是“人”或前端，也可能是另一个 server。这个补充很重要，因为它能帮你真正理解“服务和服务之间通信”。
4.5 服务拆分的价值不只是“省资源”
老师还纠正了学生一个常见误区：拆服务不一定天然就更省 RAM；更重要的是它让你能把不同服务部署到不同节点、隔离故障、单独维护、单独扩展。这个补充比课件更贴近真实系统。
5. 这周最可能要掌握的考点 / 作业相关点
我判断最可能和 quiz / assignment / exam 有关的，是下面这些：
5.1 Web Service 的定义与作用
它通过 HTTP 上的 request/reply，让不同系统用 XML / JSON 通信，实现互操作。
5.2 XML vs JSON 的比较
为什么 JSON 在云/API 场景更常见；XML 的优势是什么；XML 的问题是什么。
5.3 Marshalling / Unmarshalling
只要你能用“把内部数据转换成约定外部格式，再在接收端还原”说清楚，就够了。
5.4 REST 的资源思想 + HTTP 方法
5.5 SOAP / WSDL 的高层概念
SOAP 是 XML-based 的 Web Service 协议；WSDL 是服务描述语言。
5.6 SOA 与 Microservices 的区别与联系
5.7 和作业直接相关的“完整链路”
应用设计成服务 → 容器化 → Kubernetes 部署 → service 暴露 → 性能 / 效率优化。
而且老师还明确说，按 applied session 基础做出来是 passing；想拿更高分，效率和性能要更好。
5.8 Quiz 相关的隐含重点
week 6 quiz 是 45 分钟、online、closed book，会有 multiple choice，也会有一个 solution-architecture 风格的问题。
所以你不能只背术语，还要能用这些概念解释一个设计场景。
6. 我应该怎么学这周内容
推荐学习顺序
你先记住：前几周学“怎么跑”，这周学“怎么设计、怎么通信”。
service、resource、representation、HTTP method。
如果这四个词没搞懂，REST 和 Web Service 会很飘。
第三步，学 Web Service + marshalling + XML/JSON。
先理解“服务之间必须有共同语言”，再比较 JSON 和 XML。
GET / PUT / DELETE / POST
先抓高层概念，不要一开始就扎进 XML envelope 细节里。
第六步，最后收束到 SOA / microservices，并把它和前面的容器、Kubernetes、assignment 连起来。
我必须先搞懂的基础概念
哪些内容属于“理解型”
为什么要拆服务而不是做单体
Web Service 为什么能促进 interoperability
Marshalling / Unmarshalling 在跨系统通信里为什么需要
为什么 JSON 更常见于现代 API
REST 为什么强调 stateless
SOA 和 microservices 的思想差别
哪些内容属于“记忆型”
哪些内容属于“应用型”
哪些内容只需要了解
哪些内容需要重点掌握
哪些地方最容易混淆
1. Kubernetes service vs Web Service
一个偏基础设施暴露入口，一个偏服务通信/API 概念。它们有关联，但不是同一个词义。
前一部分课里老师已经反复强调：Kubernetes 调度和扩缩看的是 pod，不是 container。
SOAP 更偏 XML + contract + WSDL；REST 更偏资源 + HTTP 动作。
DELETE 是 idempotent，但不 safe。这个最容易错。
SOA 更宽泛，microservices 更细粒度、更云原生。
6. extra reading vs home reading
学完后我应该能回答哪些问题，才算真的掌握
什么是 Web Service，它解决了什么问题？
为什么不同系统之间要用 XML 或 JSON 这种共同格式？
什么是 marshalling / unmarshalling？
JSON 和 XML 各有什么优缺点，为什么云里常偏向 JSON？
REST 的核心思想是什么？
GET / PUT / DELETE / POST 分别适合做什么？
safe 和 idempotent 有什么区别？
SOAP 和 REST 的高层区别是什么？
SOA 和 microservices 是什么关系？
如果让我设计一个简单应用，我怎么把它拆成服务并部署到 Kubernetes 上？
如果这 10 个问题你都能顺畅回答，这周基本就算掌握了。
7. 给我一份简短复习清单
8. 如果我是初学者，你再用更简单的话解释一遍
“我已经有一个程序了，怎么把它装进容器，怎么放到 Kubernetes 上跑起来。”
它们要通过 Web Service / API 来通信。
老师的意思是，在云和分布式系统里，大家现在更常用 JSON，因为它更轻、更省事。
一种叫 SOAP，比较正式，偏 XML，规则很多；
用 URL 表示资源，用 GET / POST / PUT / DELETE 这些 HTTP 动作操作资源。
你不只是要会把应用部署到云上，你还要会把应用设计成适合云的样子。