对servicemesh 出口egress网关的一些理解(如何做到降低了10倍的外部接口延迟)

背景

最近公司一个服务有上千台机器之前做了mesh化(部署了我们自研的sidecar),业务方使用的是php,需要调用一个第三方的https接口,由于php是短连接的模型,导致每次请求都需要经过ca认证和tls握手,耗时大概在100+ms,而整个请求耗时平均200+ms,业务方只能忍受100ms的延迟(设置了100ms的超时),导致整个业务逻辑不可用。
业务方找到我们,开始我们在sidecar上面配置了这个第三方接口的路由,帮助php维持了长连接,效果很不错,延迟降低到了平均60ms左右,0.3%左右的100+ms的超时,业务方能忍受这个比率。于是业务方非常高兴的上线了~
然而到了第二天早上6点多开始,100+ms超时导致的499比率持续上升,报警电话惊醒了我(mesh之后已经成了半个运维了)。
于是开始了各种常规排查,发现连接池中的连接被大量断开,于是询问第三方接口方,得到回复是他们把tengine的keepalive_timeout改短了,原因是我们的集群出口ip对他们接口建立了大量的连接(1000台机器*每台32个连接),他们为了保护服务修改了网关的配置参数。
这样的回复。。。让我们意识到了需要收敛集群对外的连接数,我们想到了egress出口网关,于是,咔咔咔一顿配置修改和部署,我们把sidecar直接部署成了网关模式并配置好内部服务发现,转移各个微服务的流量路径(sidecar的魅力体现出来了,业务方完全无感知),于是上线后通知第三方服务方改回原来的配置,惊喜的发现平均延迟降低到了20ms,99延迟达到了70ms,成功满足了业务方最大100ms延迟的需求(否则业务方就要去告诉产品实现不了这个需求了~)

梳理

开始php https短连接ca认证检查大概需要100ms,tls握手耗时在70ms左右,第一步的sidecar让连接次数变得很少,把平均延迟降低到了60ms,但是由于存在大量线上节点,而每个节点调用这个第三方接口qps只有0.x,导致连接池利用率很低,还是会存在比较高的连接重建(空闲连接都断开了),所以需要引入一个统一的出口网关,把大量连接池收敛到了集中的网关,使得网关连接利用率提高,重建连接次数急剧减少,把平均延迟降低到了20ms,当然还有一个好处是可以不给三方接口带来比较大的连接压力~
基本思想就是用内网的低延迟建立连接换取外网高延迟建立连接(n个连接池每个连接池m个平均连接的情况,比统一收敛到一个连接池使用的连接会大很多,收敛后可以选择的空连接池大了,连接利用率也就上升了)

《对servicemesh 出口egress网关的一些理解(如何做到降低了10倍的外部接口延迟)》有1个想法

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请输入正确的验证码