今天快速介绍目前市场面常见的三个watch机制的实现。
1.chunked transfer encoding
k8s控制面几个组件，核心枢纽是apiserver， 除etcd之外，其他组件都通过restful进行http通信。
上文提到的informer机制是controller的标准范式， 目的是实现声明式API的闭环控制，减少了对于apiserver的调用。
scheduler和kubelet、kubectl也有对于apiserver的调用，监听资源变更的方式都是watchAPI， 这是一种非标准的chunked transfer encoding，http1.1传输层编码。
分块传输编码（CTE）是一种 HTTP/1.1 机制，通过将数据分割为多个块来流式传输响应，每个块前面都带有其十六进制表示的大小，使得服务器可以在不知道总长度的情况下发送数据，适用于动态内容、实时更新和大文件传输，最后以一个长度为零的块结束。
2. grpc 流式通信
apiserver作为控制面组件的交互枢纽， 与底层存储etcd交互。
apiserver 也需要watch etcd的资源变动，这样才能接力反馈到上层组件（scheduler，kubectl）。 
etcdv3 走的是grpc协议，天生支持双向实时通信。
http2.0 高性能rpc框架， 单个tcp连接上多路复用，二进制分帧、双向流式通信，头部压缩。
apiserver是作为grpc客户端与etcd交互，etcd 的 Watch 机制是一个集 MVCC 版本控制、高效内存索引、持久化存储和流式网络通信 于一体的复杂系统。其核心价值在于提供了 基于逻辑时钟的、可靠的、有序的变更通知，这正是 Kubernetes 等分布式系统能够构建出高效、一致的状态协调机制的基础。
3. 服务端发送事件SSE
目前火热的大模型在线推理，走的是SSE协议。
服务器发送事件（SSE）是一种基于HTTP 协议的单向通信协议，它允许服务器以事件流（Event Stream）的形式实时向客户端推送数据，而无需客户端明确请求。它建立在标准的 HTTP 协议之上，通过单向的持久连接，服务器可以主动向客户端发送事件和数据。
本质上，它是以应用层消息协议来实现的，由客户端向服务端发起建立连接请求，并保持连接打开，然后服务端主动推送消息给客户端，服务器给客户端发送的 SSE 数据，必须是 UTF-8 编码，且返回的内容类型是text/event-stream。
比如当你在使用DeepSeek 时，当你询问它问题时，你会看到它会逐字地将回答显示出来，实际上这是DeepSeek 将先计算出的数据主动的"推送"给你，采用 SSE 技术边计算边返回，避免接口等待时间过长而直接关闭页面。