华兴证券是 CloudWeGo 企业用户，使用 Kitex 框架完成混合云部署下的跨机房调用。企业用户如何搭建针对 Kitex 的可观测性系统？如何在 K8s 集群下使用 Kitex ? 华兴证券后端研发工程师，DevOps 负责人张天从以下 4 个方面介绍了 Kitex 在多机房 K8s 集群下的实践经验。
1. Kitex 的可观性系统搭建
华兴证券 CloudWeGo-Kitex 使用情况
首先介绍下研发团队的 Kitex 使用情况。2021 年 6 月 1 日，华兴证券互联网证券 APP 研发团队成立。Kitex 在 7 月 12 日发布了首个版本，10 天后研发团队就引入了 Kitex。选择 Kitex 的原因是：团队早期成员比较了解 Kitex，于是为了快速支撑业务迭代和验证，团队选择了最熟悉的框架，这样使用上比较习惯，对性能和功能方面也比较有把握。后来这也支撑了我们 APP 的快速上线。大约 4 个月之后 APP 的第一个版本正式上线。
![]()
下图是我们的微服务调用关系图，一共有三十多个微服务，调用链路数超过 70。我们的服务分别部署在两个机房。核心业务比如交易、行情等部署在私有机房。非核心的业务，比如资讯、股票信息等部署在阿里的金融云，这样能够更好地利用金融云已有的基础设施比如 MySQL、Kafka 等，作为初创团队，能够降低整体的运维压力。考虑到性能以及安全方面的因素，两个机房之间专门拉了专线。服务之间存在一些跨机房的依赖。跨机房调用会产生很多问题，后文会详细说明。
![]()
Tracing 选型
服务数多了之后，我们需要一套链路追踪系统来描绘调用链路每个环节的耗时情况。考虑到 Kitex 原生支持 Opentracing，为减少集成成本，我们调研了符合 Opentracing 规范的产品。
排除掉收费的、客户端不支持 Go 之后，就剩阿里云的链路追踪产品和 Uber 公司出品的 Jaeger，考虑到私有机房也要部署，最终选择了 Jaeger。
Kitex 接入 Tracing
选定方案之后，开始对 Kitex 的这个功能进行测试，结果发现当时去年 9 月初的 Kitex 版本并不支持跨服务的 Tracing，原因是调用的时候，没有把 Trace 信息发送给下游，如图所示，这样上下游是两个孤立的 Trace（OpenTracing 规范里称为 Span），于是就无法通过一个 TraceID 去串起整条链路。当时任务比较急，于是我们没有等 Kitex 官方的实现，决定自研。
![]()
为了自研，我们结合 Kitex 的源码，梳理出客户端和服务端的流程。可以看出 Kitex 的上下游都内置了 Tracer 的 Hook。这里我们要解决的问题是，如何把 Span 信息进行跨服务传输？
![]()
经调研，实现透传有三种方案。
第一种是在消息层搞一个 Thrift 协议的拓展，把 Trace 信息塞进去。原因是 Thrift 本身没有 Header 结构，只能进行协议的拓展。好在 Kitex 支持自定义的协议拓展，因此具备可行性，然而开发成本较高，所以没选择这种方案。
第二种是在 IDL 里增加通用参数，在字段里存 Trace 信息。缺点是业务无关的字段要在 IDL 里，对性能有一定的影响。毕竟需要通过 Kitex 的中间件，通过反射来提取。
第三种是利用了 Kitex 提供的传输层透传能力，对业务没有侵入性。最后选择了这一种方案。
![]()
透传方案定了之后，整体的流程就清晰了。首先客户端会在 metaHandler.write 里通过 CTX 获取当前 Span，提取并写入 spanContext 到 TransInfo 中。
然后服务端，在 metaHandler.Read 里读取 spanContext 并创建 ChildOf 关系的 Span，中间件结束时 span.finish()，最后为了防止产生孤立 Trace，New 服务端时不使用 Kitex 提供的 Tracing 的 Option。
这里是因为同一个服务可能分别作为 Kitex 上下游，Tracer 如果共用，需要分别加特殊逻辑，实现上有点复杂。
![]()
Tracing 基础库
为了充分利用 Tracing 的能力，除了 Kitex，我们在基础库中也增加了 Gin、Gorm、Redis、Kafka 等组件的 Tracing。
下面展示实际的一条链路。功能是通过短信验证码进行登录。先是作为 HTTP 服务的 API 入口，然后调用了一个短信的 RPC 服务，RPC 服务里面通过 Redis 来检查验证码。通过之后调用用户服务，里面可能进行一些增加用户的 MySQL 操作。最后把用户登录事件发给 Kafka，然后运营平台进行消费，驱动一些营销活动。可以看出最耗时的部分是关于新增用户的一堆 MySQL 操作。
![]()
对错误的监控
Tracing 一般只关注调用耗时，然而一条链路中可能出现各种错误：
1. Kitex
2. HTTP
![]()
如何对这类错误进行监控？主要有以下三种方案：
1. 打日志 + 日志监控，然后通过监控组件，这种方案需要解析日志，所以不方便；
2. 写个中间件上报到自定义指标收集服务，这种方案优点是足够通用，但是需要新增中间件。同时自定义指标更关注具体的业务指标；
3. 利用 Tracing 的 Tag，这种方案通用且集成成本低。
具体实现如下：
-
Kitex 的 err、以及 HTTP 的状态码，定义为系统码；
-
IDL 里的 Code 以及 HTTP 返回的 JSON 里的 Code，定义成业务码；
-
Tracing 基础库里提取相应的值，设置到 span.tag 里；
-
Jaeger 的 tag-as-field 配置里加上相应的字段（原始的 Tags，为 es 里的 Nested 对象，无法在 Grafana 里使用 Group By）。
监控告警
在增加错误监控的基础上，我们构建了一套监控告警系统体系。
这里重点看一下刚才的链路追踪相关的内容。首先每个业务容器会把指标发送到 Jaeger 服务里。Jaeger 最终把数据落盘到 es 中。然后我们在 Grafana 上配置了一堆看板以及对应的告警规则。
触发报警时，最终会发送到我们自研的 alert-webhook 里。
自研的部分首先进行告警内容的解析，提取服务名等信息，然后根据服务的业务分类，分发到不同的飞书群里，级别高的报警会打加急电话。这里也是用到了飞书的功能。
![]()
Grafana 里我们配置了各类型服务调用耗时、错误码一体化看板，描述了一个服务的方方面面的指标。包括日志监控、错误码监控、QPS 和调用耗时、容器事件监控、容器资源监控等。
![]()
下图展示了飞书告警卡片。包括 RPC 调用超时、系统码错误、业务码错误。
这里我们做了两个简单的工作，一个是带上了 TraceID，方便查询链路情况。另一个是把业务码对应的含义也展示出来，研发收到报警之后就不用再去查表了。
![]()
本章小结
-
完成了 Tracing 接入 Kitex，实现跨服务传递；
-
对 Tracing 基础库扩展了其他类型中间件（Gin、Gorm、Redis、Kafka）的支持；
-
对 Tracing 基础库增加了系统码、错误码实现对错误的监控；
-
配置了全方位的服务指标看板；
-
结合 es、Grafana、飞书以及自研告警服务，搭建了针对微服务的监控告警系统。
这样我们就完成了可观测性体系的搭建。
2. 服务压力测试中遇到的问题以及解决方案
完成了监控告警体系之后，我们希望对服务进行压测，来找出性能瓶颈。第二部分介绍一下服务压测中遇到的问题和解决方案。
Kitex v0.0.8：连接超时问题
首先我们发现，QPS=150 左右，Kitex 出现连接建立超时的错误。当时我们检查了下 CPU、网络、内存等均没有达到限制。先是怀疑连接池大小不太够，于是测了下 10 和 1000，如上图所示，结果在报错数目上没有区别。另外观察到的一个现象是，压测期间出现接近 5000 的 Time Wait 状态。
![]()
5000 的限制，是因为达到了 tcp_max_tw_buckets 的设置的值。超过这个值之后，新的处于 Time Wait 状态的连接会被销毁，这样最大值就保持在 5000 了。于是我们尝试进行排查，但没有思路，于是去翻看 Kitex 的 Issue，发现有人遇到相同的问题。
![]()
原来，v0.0.8 版本的 Kitex，在使用域名的方式来新建 Client 的时候，会导致连接池失效。因为把连接放回连接池时，用的 Key 是解析之后的 IP，而 GET 的时候，用的是解析前的域名，这样根本 Get 不到连接，于是不停创建短连接。这样的两个后果是：一方面建立连接比较耗时，另一方面请求执行完毕之后都会关闭掉连接，于是导致了大量的 Time Wait。
![]()
为了进行验证，我把测试服务改成了 IP 访问，然后比较了 IP 访问和域名访问以及不同连接池大小的情况。可以看出 IP 访问（连接池有效），但是连接池比较小的情况，出现减少的 Timeout。连接池 100，Timeout 消失。而中间的域名访问的情况下，出现大量 Timeout。
![]()
Kitex v0.1.3：连接池问题修复
看代码得知在 Kitex v0.1.3 修复了这个问题。
![]()
于是我们打算升级 Kitex 的版本，因为当时已经上了生产环境，在升级基础组件之前，需要进行验证，看一下不同连接池大小状态下的表现。还是域名模式，QPS 为 150 的情况下，随着连接池大小的增加，Timeout 的情况逐渐变少到消失。
![]()
继续进行压测，我们发现 QPS=2000 的时候又出现了报错。结合监控，发现原因是连接建立的时候超过了默认的 50ms。
![]()
我们讨论了几种解决方案：
1. 修改超时配置。然而，交易日的 9:30-9:35 有⼀堆集中交易请求，突发的流量，耗时长了体验不好，可能会影响 APP 收入，我们希望系统性能保持稳定。
2. 进行连接耗时的优化。然而 Kitex 已经使用了 Epoll 来处理创建连接的事件，作为使用方，进一步优化的难度和成本都太大。
3. MaxidleTimeout 参数改成无限大？比如先创建一个足够大的池，然后随着用户请求，池变得越来越大，最终稳定下来。但是每次服务升级之后，这个池就空了，需要慢慢恢复。
4. 进行连接预热。
![]()
其实连接预热就相当于压测结束之后立马趁热再压一次，如图，可以发现 QPS=2000 的情况下，几乎都走了连接池，没有报错。因此，如果服务启动时能够进行连接预热，就可以省下建立连接的时间，使服务的性能保持稳定。
![]()
当时 CloudWeGo 团队针对我们公司建了企业用户交流群，于是我们就向群里的 Kitex 研发提了连接预热的需求。其开发之后提供了连接预热个数的选项。我们也进行了测试。按照 QPS=2000 进行测试，
![]()
![]()
本章小结
3. Kitex 的不同连接类型在 K8s 同集群/跨集群调用下的一些问题和解决方案
第三部分我们讨论一下 Kitex 的不同连接类型在 K8s 同集群/跨集群调用下的一些问题和解决方案。
长连接的问题：跨集群调用
首先是长连接跨集群调用下的问题。服务在跨集群调用时，其源 IP: 端口为宿主机的，数量有限，而目的 IP: 端口为下游集群的 LB，一般是固定的。
那么，当长连接池数目比较大（比如数千），且上游较多（各种服务、每个都多副本，加起来可能数十个）的情况下，请求高峰时段可能导致上游宿主机的源端口不够用。同集群内跨机器调用走了 vxlan，因此没有这个问题。
解决方案有两类：
比较起来，改造成 Mux 模式成本最低。
连接多路复用的问题：滚动升级
但是多路复用模式，在 K8s 场景下，存在一个滚动升级相关的问题。我们先介绍下 Service 模式。
K8s 的 Service 模式采用了 IPVS 的 Nat 模式（DR 和隧道模式不支持端口映射），链路为：上游容器←→ClusterIP（服务的虚拟 IP）←→下游容器。
然后我们看看滚动升级流程：
1. 新容器启动。
2. 新容器 Readiness Check 通过，之后做两件事情：
3. 由于更新了 Endpoints 列表，Endpoints 列表发生更新事件，立即回调触发规则更新逻辑（syncProxyRules）：
经过步骤 3 之后，已有的连接仍然能够正常工作（因为旧容器 rs 未删），但新建的连接会走到新的容器上（因为旧容器权重 =0）。
在 Service 模式下，上游通过一个固定的 IP: 端口来访问下游，当下游滚动升级的时候，上游看到的地址并未变化，即无法感知到滚动升级。于是，下游即使有优雅退出，但上游并不知道下游开始优雅退出了。之后可能的情况是：
针对此问题，解决方案如下：
![]()
具体可采用如下方式：
1. 收到 sigTerm 的下游直接告诉上游（通过之前建立的 Conn1），同时下游继续处理发来的请求。
2. 上游收到关闭信息之后：
这种方式的优点是同集群跨集群均可使用，缺点是需要 Kitex 框架支持。在我们找 Kitex 团队讨论之后，他们也提供了排期支持本需求。
连接多路复用的滚动升级测试：Headless Service 模式
在 Kitex 团队开发期间，我们测下 Kitex 已有版本对 Headless Service 模式下的滚动升级功能。测试方案如下：
-
Kitex 版本 v0.1.3；
-
上下游均为 Mux 模式；
-
上游的加了个自定义 DNSResolver，刷新时间为 1s，加日志打印解析结果；
-
下游的退出信号处理，收到 sigTerm 之后特意 Sleep 10s（用来排除这个 Case：服务端发现连接空闲关闭了，但客户端在关闭之前恰好拿到连接，接着认为未关闭，实际上已经关闭，而客户端发起了请求，于是导致报错）；
-
QPS=100 恒定压上游，然后触发下游滚动升级。
实测报错如下图：
![]()
时序分析如下：
可见报错时旧下游还未执行退出逻辑，排除旧下游主动关闭连接。请求旧下游期间，且此时解析到新容器 IP（移除了旧容器 IP），报错是因为还没到退出逻辑的时候。因此推测，解析条目变化导致了报错。
根据推测，结合代码（Kitex 客户端部分）分析，可能出现以下并发问题：
-
【协程 1】客户端从 Mux 池里取出 Conn1，即将发起请求（所以没有机会再检查 Conn1 状态了）；
-
【协程 2】DNS 更新，移除了 IP，于是 Clean 方法中关闭了 Conn1；
-
【协程 1】客户端用 Conn1 发起请求，导致报错 Conn Closed。
![]()
于是我们向 CloudWeGo 提了 Issue，他们很快修复了这个问题。
![]()
连接多路复用的滚动升级测试：Service 模式
同样地，在 Service 模式中，测试方案如下：
-
Kitex 版本使用 Feature 分支：mux-graceful-shutdown；
-
上下游均为 Mux 模式、服务发现使用 Service 模式；
-
恒定 QPS=200 压上游，20s 触发下游滚动升级；
-
另外写个服务打印期间的 IPVS 的日志；
-
下游的退出信号处理，收到 SigTerm 之后特意 sleep 10s（保证 IPVS 规则已更新）。
测试结果如下：
报错：INFO[0050] "{\"code\":-1,\"message\":\"remote or network error: connclosed\"}"。
时序分析为：
1. 旧下游收到 sigTerm，开始 sleep 10s。
2. IPVS 规则变化：
3. 旧下游 sleep 完成，进入最长为 15s（WithExitWaitTime）的优雅退出。
4. 上游请求报错。
5. 旧下游打印了最后一条日志。
6. IPVS 规则变化：
7. IPVS 规则变化：旧下游的规则被移除。
![]()
因此我们得出结论，报错发生在优雅退出期间。最后一条日志时刻大于报错时刻，因此，排除 K8s 的问题，确认 Conn Closed 是由 Kitex 导致的。之后我们和 Kitex 研发团队沟通了分析结果，找到了 Root Cause，是因为假设了新的下游会有一个新的地址（但实际中 Service 模式都是一个地址），导致新请求取到了老请求的连接并进行关闭。对此进行了修复：
![]()
连接多路复用的问题：下游扩容
如果⽤ Service 模式（上游看到的下游就是体现为⼀个 IP），创建的 TCP 连接会在最开始固定的几个下游 POD 上，之后如果扩容增加 POD，新创建的 POD 就不会路由到了，导致扩容实际上无效。
解决方案如下：
1. 同集群调用：可用 Headless Service 模式，由于 DNS 解析能够得到所有 POD，路由没问题。
2. 跨集群调用：不在同集群内， Headless Service 模式无效，考虑如下方案：
-
方案1：修改服务发现机制。
优点：Kitex 无需改动。
缺点：增加依赖项（服务发现组件）。
-
方案2：下游先升级，之后上游 Redeploy 一下，让连接分布到下游的各种实例上。
优点：Kitex 无需改动。
缺点：上游可能很多，逐个 Redeploy 非常不优雅。
-
方案3：上游定期把 Mux 给过期掉，然后新建连接。
优点：彻底解决。
缺点：需要 Kitex 支持。
本章小结
-
首先，针对长连接模式分析了跨集群时上游源端口数问题，希望通过多路复用模式解决；
-
其次，针对多路复用模式 + K8s Headless Service 模式的优雅升级，实测报错，分析定位了原因，Kitex 研发团队及时解决了相应问题；
-
再次，针对多路复用模式 + K8s Service 模式下的优雅升级提出了方案，Kitex 团队完成了实现，迭代了一轮，测试通过；
-
最后，针对多路复用模式 + K8s Service 模式下的下游副本扩容时路由不到的问题分析了原因，提出了方案，目前方案待实现。
4. 实践中遇到的其他问题以及解决方案
第四部分我们分析下实践中遇到的其他问题以及解决方案。
RPC Timeout Context Canceled 错误
研发同学发现日志出现 Contexe Canceled 的错误，分析日志发现出现频率低，一天只有几十条，属于偶发报错。
![]()
我们推测是用户手机因为某种原因关闭了进行中的连接所导致，对此进行本地验证。三个部分：首先Gin 客户端设置了 500ms 超时限制，去请求 Gin 服务端接口；其次，Gin服务端收到请求之后，转而去调用 Kitex 服务；最后，Kitex 服务端 Sleep 1s 模拟耗时超时，保证 Gin 客户端在请求过程中关闭连接。
实测能够稳定地复现。
![]()
我们梳理了源码逻辑，客户端关闭连接之后，Gin 读取到 EOF，调用 cancelCtx，被 Kitex 客户端的 rpcTimeoutMW 捕获到，于是返回了 err。
那么问题就变成，请求未完成时，连接为何会被关闭？我们按照设备的 ID 去分析日志，发现两类情况：一类是报错对应的请求是该设备短期内的最后一条，于是考虑 APP 被手动关闭；二是报错对应的请求非短期内的最后一条，客户端研发反馈，有些接口例如搜索，上一条请求执行中（未返回），且新的请求来时，会 Close 掉上一次请求的连接。第二种情况比较确定，关于第一种情况，APP 被关闭时，IOS 和 Android 是否会关闭连接？客户端同学没有给出肯定的答复。
于是我们考虑实际测试一下，两端分别写一个测试的应用，持续发起请求，但是不释放连接，此时关闭 APP，分析 TCP 包。实测我们在两端上均看到了 4 次挥手的 Fin 包。所以这个问题得到了确认。
![]()
那么如何进行修复呢？我们采取在 GIN 的中间件上拦截掉 Done 方法的方式。
![]()
上线之后，再没有出现这种情况。
![]()
还有一个问题，我们在测试环境发现，跨集群调用的时候，经常出现连接被重置的问题。生产环境搜日志，无此现象。
![]()
我们分析了环境差异：
我们找网络同事咨询，得知 NAT 表项的过期时间是 60s。连接过期时，NAT 设备并不会通知上下游。因此，上游调用的时候，如果 NAT 设备发现表项不存在，会认为是一个失效的连接，就返回了 rst。于是我们的解决方案是 Kitex 上游的 MaxIdleTimeout 改成 30s。实测再未出现报错。
![]()
本章小结
5. 展望
未来我们计划把 Gin 更换为更高性能（QPS/时延）的 CloudWeGo-Hertz。因为我们 K 线服务的 Response Size 比较大（~202KiB），更换后 QPS 预计可达原先的 5 倍。同时，为回馈开源社区，我们打算贡献 Tracing 基础库的代码到 Kitex-contrib/Tracer-opentracing。欢迎持续关注 CloudWeGo 项目，加入社区一起交流。
![]()
6. 更多资讯
