博主vx: haitangyijiusu 。很高兴认识你！偶尔带huo，都是精挑细选信得过的产品，欢迎来支持，期待和您相遇！  

k8s List-Watch

    k8s系统组件之间使用HTTP协议通信，使用HTTP协议实现这么复杂的系统功能，一定是有他的过人之处。
    List-Watch,顾名思义，就是由List和Watch两部分组成，List就是普通的HTTP短链接，可以获取各种资源的列表数据。
    
    而Watch则是通过调用资源的Watch API监听资源变更时间，基于HTTP长链接实现。
    
    Informer封装了list-watch的API，用户需要指定资源，编写时间处理函数，AddFunc，UpdateFunc、DeleteFunc等等。如下图所示，informer首先通过List API拿到资源，然后调用WatchAPI监听资源的变更时间，并将结果放到一个FIFO的队列，队列的另一头有很多个协程从中POP出时间，并调用相对应的注册函数处理时间。Informer维护了一个只读的Store缓存，也称作是Indexer，可以提高查询的效率降低APISERVER的负载。

    一个优秀的消息系统，至少有以下四个特质：

•     消息可靠性
•     消息实时性
•     消息顺序性
•     高性能

    
    List可以查询到某个资源的当前状态和期望状态，避免消息因为丢失而造成状态不一致场景。Watch API和apiserver保持一个长连接，接收资源的状态变更时间。并做对应的处理。如果只有watch，如果某个时间点断开连接，到再次连接，中间又可能漏掉一些事件没有处理。所以可以通过list进行“查漏补缺”。另一个方面来讲，我们可以认为list获取全量数据，而watch获取的是增量数据。如果只有list，那么每次都要全量获取数据，对apiserver必将造成很大的压力。
    
    watch也保证了消息的实时性。
    
    关于顺序性，在高并发场景下，客户端在短时间内可能会受到同一个资源的很多个请求事件。k8s通过事件的“resourceVersion”标签来描述事件的时间节点，而这个字段是递增的数字。所以可以通过这个字段来保证事件最终的状态和最新的时间所期望的状态是否一致。

    K8s Watch机制实现的核心是Chunked Transfer Encoding（分块传输编码）。

    维基百科的解释是：

    分块传输编码（Chunked transfer encoding）是超文本传输协议（HTTP）中的一种数据传输机制，允许HTTP由网页服务器发送给客户端应用（ 通常是网页浏览器）的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供。
通常，HTTP应答消息中发送的数据是整个发送的，Content-Length消息头字段表示数据的长度。数据的长度很重要，因为客户端需要知道哪里是应答消息的结束，以及后续应答消息的开始。然而，使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。通常数据块的大小是一致的，但也不总是这种情况。