​ 端到端原则（End To End）最初来自计算机技术和通信系统的设计原则，在用来划分通信底层的功能的时候，强调端侧高可用如果依赖通信底层实现代价很大，且无法完全高可用，需要依赖端侧实现。这种原则后来也用于知道分布式系统和适微服务系统，当服务调用依赖一系列微服务系统或者中间件时候，端侧应用应该实现高可用而不依赖于底层或者中间件。

高可用4大原则我自认为分别是 端到端，有状态vs无状态，可观测，万一，其他微服务框架，容器化我认为是次要的。

为了说明端到端原则，会举出3个例子来说明

例子	说明
分布式文件复制	End To End 论文中的例子，证明复制文件只是需要端到端保证，不依赖底层软件或者硬件的高可用
Kafka保证消息处理	Kafka自身不能保证发送端的消息一定被接收端正确处理
物联网系统	物联网系统同样类似Kafka那样的中间件，它应该只完成基础的物联网功能，比如消息认证，消息格式转化和传输。

以分布式文件复制，会有一系列概率较低的偶发错误，如乱序，重复传递，传输内容不正确，传输内容被篡改等。 把A系统文件传输到B系统，需要将文件分块读取和传输，可能会经历A和B系统磁盘错误，A和B系统通信的网络错误，或者是网络中取出数据，复制到操作系统中的错误，为了保证传输的高可用，有俩种方式

• 一种方式是要求底层系统每一部分，如磁盘，网络，操作系统保证高可用，确保分块传输的数据正确，这里的正确可能是内容正确，顺序正确，数据安全。
• 另外一种较为简单的方式接收端实现高可用，在传输完毕后接收端检测复制的文件是否正确

检测文件是否正确，发送端可以生成文件内容的HASH值并发送到接收端 ，接收端需要过对比文件的HASH值和传送的HASH值是否一致

以Kafka为例子，它是一个高性能的消息系统。如果想要保证消息生产者发送的消息一定能被消息订阅者收到，Kafka自己不能保证。这需要消息接收端显示的发送一个“收到”消息给发送端。下图展示了通过请求Topic和应答Topic来实现消息系统下的高可用。

当我们在实现分布式或者微服务系统的时候，高可用系统首先考虑是端到端设计原则，即底层或者中间层或者中间服务节点完成基本功能，端侧实现高可用。

以物联网应用为例子，当设备上报属性时候，我们希望影子系统存储的是最后一次上报的属性。我们会要求设备端上报的属性带有时间戳或者一个的版本号。 影子系统在存储设备属性时候，会检测这个版本号，如果此版本号低于目前影子系统的存储的版本号，则不存储。

我参与的过一个物联网系统优化，设备属性起初并没有上报版本号，但又要求影子系统存储的是最新属性，这是物联网这种中间系统不可能做到的，采取的临时方案是在物联网的网关模拟出一个版本号，但这肯定还是有问题，直到最后规定设备属性必须上报版本号才解决。

这个像中间件的物联网系统，曾经为了保证设备消息可靠传输，团队做出了巨大努力，并没有成功得到设备端和业务端的认可。就是忽略了端到端原则

为了实现端侧高可用，本书会介绍一系列适用端侧的的技术来保证分布系统高可用

技术	描述
ID生成	用于发起端生成一个唯一序列号，接收端用于验证消息唯一性和顺序性
重试策略	发起端如果没有收到响应，需要重试。发送端如果无法确认接收端是否收到，也可以发起重试。
接口幂等	接收端对于多个同样的请求，对接收端的影响应该是一致的
无状态服务	接收端无状态服务能保证较为容易得实现高可用，如果是有有状态服务，高可用难度增加一个数量级
有状态服务	如果接收端必须是有状态服务，需要通过分区，粘性连接，分区再平衡，数据复制，一致性共识等技术实现高可用
心跳	检测对端系统是否存活的技术，对端系统也通常通过判断是否收到心跳判断客户端是否存活
超时控制	设定合理的超时策略，保证发送端和接收端的高可用。
流量控制	流量控制保证了自身系统的可用。 发送端端流量控制和接收端流量控制有所区别
API设计原则	综合如上技术形成的分布式API设计原则