istio circle-breaking文章摘录 原文链接 https://tech.olx.com/demystifying-istio-circuit-breaking-27a69cac2ce4 揭秘istio 熔断 我们已经在自己的eks集群上采用了istio服务网格，我们采用了许多令人激动的特性， 之前我们的熔断依靠的是java的Resilience4j，但istio给予我们的是不需要修改代在网络层面就能实现的熔断功能。 尽管istio表面上看上去很简单，但我们在网络上找到的文章用处并不大且不助于理解熔断在不同场景下的功能。 所以我们着手进行一些测试去加固我们的理解在我们开始真正的使用它之前。 根据文档描述，我们需要创建一个目的地规则去配置熔断到给定的目标service上，熔断的功能参数被定义在connectionPool里面 （outlierDetection同样是熔断的一部分，但这篇文章我们仅仅关注connectionPool），这些相关的参数是： tcp.maxConnections：到一个目的地址的最大http1/tcp连接数量。默认是2³²-1. http.http2MaxRequests: 后端最大请求数，默认是2³²-1。 在官方文档中，很清楚这些参数在简单场景中是如何工作的，一个客户端以及一个目标实例，但是，在实际情况中，更多的场景是， >一个客户端对应多个目标服务实例。 >多个客户端对一个目标服务实例 >客户端与目标实例都有多个的场景。 文档中有点缺乏对于以上情况的描述，问了对熔断有更深的理解，我们决定在本地环境测试下这些参数。 我们创建两个python脚本，一个作为客户端，一个作为服务端。 客户端调用服务端10次，10并发调用，然后在下10次调用前做sleep操作。接着创建两个pod演示。 首先对service创建DestinationRule，设置最大连接数为5。 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: pyserver-service spec: host: pyserver-service trafficPolicy: connectionPool: tcp: maxConnections: 5 场景一中：一对一， STATUS: 200, START: 11:52:20, END: 11:52:25, TIME: 5.055624961853027 STATUS: 200, START: 11:52:20, END: 11:52:25, TIME: 5.058431386947632 STATUS: 200, START: 11:52:20, END: 11:52:25, TIME: 5.061942100524902 STATUS: 200, START: 11:52:20, END: 11:52:25, TIME: 5.06324577331543 STATUS: 200, START: 11:52:20, END: 11:52:25, TIME: 5.062822580337524 STATUS: 200, START: 11:52:20, END: 11:52:30, TIME: 10.03047299385070 STATUS: 200, START: 11:52:20, END: 11:52:30, TIME: 10.03211736679077 STATUS: 200, START: 11:52:20, END: 11:52:30, TIME: 10.03300023078918 STATUS: 200, START: 11:52:20, END: 11:52:30, TIME: 10.04033088684082 STATUS: 200, START: 11:52:20, END: 11:52:35, TIME: 15.04372119903564 根据显示的数据看出来，只有5次的调用在5秒，其他的都在10秒，这就暗示了tcp.maxConnections使得多余的请求被加入到了 队列中，等待着链接去释放，默认情况下，可以被添加到队列的请求数量是非常高的。 为了实际是实现熔断的行为，我们需要设定http.http1MaxPendingRequests来限制可以被加入到队列的请求数量，默认是 2³²-1. 有趣的死，如何我们把它设置为0的话，它将会变为默认值，所以我们最低需要把它设置为1， 设置为1后就可以观察到，丢掉了4个请求，5个请求发送到了目标服务，1个被添加到了队列中，这是符合预期的行为。 http2MaxRequests 接着是另一个参数http2MaxRequests 对于http2来说，http2MaxRequests是非常重要的，因为http2可以在单个tcp连接里发送多个并发请求。因此需要限制最大请求数而不是 tcp连接。 场景二： 一对多的情况，这种情况测试的是 1.并发连接的限制是在pod层面的，每个pod的最大连接是在5个。 2.或者这是在service层面的，跟所有的pod数量没有关系。 第一种情况的的最大并发是15，第二种则是跟之前一样。 测试结果是连接限制是在service层面上的。 第三种场景是我们有多个客户端对应一个服务端。 因为每个istio的proxy都是独立的并且相互并不通信，所以基于这一点预测仍然是5个请求处理，然后一个加入队列，其余的被丢弃。 实际的结果是他仅仅允许了总共5个请求成功。 这是如何发生的呢，这些proxy事先通信过吗？检查下logs我们发现被丢弃的请求有两种日志， 首先被察觉到的就是RESPONSE_FLAGS — UO and URX， UO：上游过载（熔断） URX：请求被拒绝因为上有重试限制，或者达到最大连接。 一种是连接在本地被丢弃，另一种是在服务端被丢弃，