3. 配置文件可维护性差

实际线上用到 Consul 作为配置中心，采用篇幅很长的 JSON 格式配置文件，不利于运维。另外在 Consul 修改配置没有回退功能，是一个高风险操作。

好在目前日志网关的功能并不复杂，所以我们决定重构它。

新项目启动

众所周知， Go 语言拥有独特的高并发模型、较低的上手难度和丰富的第三方生态。而且我们小组成员都有 Go 项目的开发经验，所以我们选择使用基于 Go 语言的技术栈来重新构建 Chopper 项目，所以新项目命名为 chopper-go 。

需求梳理及概要设计

重新构建一个线上项目的基本原则是，功能上要完全兼容，最好能够实现线上服务的无缝升级替换。

原版核心模块的设计

Chopper 的核心功能是将接收到的 HTTP 请求分流到特定 Kafka 集群及其 Topic 中。

一、HTTP 接口部分

只开放了唯一一个对外的 API ，功能很简单：

请求方式：POST 请求路径：/log/repo/{repo_name} 请求体: 多行日志，满足 JSONL格式（即每行一条 JSON ，多行按换行符 \n 分隔）。相应状态码：- 200：投递成功。- 5xx：投递失败需要重试。参数解释: - repo_name: 对应 repo 配置名称。

请求方式：POST 请求路径：/log/repo/{repo_name} 请求体: 多行日志，满足 JSONL格式（即每行一条 JSON ，多行按换行符 \n 分隔）。相应状态码：- 200：投递成功。- 5xx：投递失败需要重试。参数解释: - repo_name: 对应 repo 配置名称。

每一类业务抽象为一个 repo 配置。Repo 配置由三部分构成：constraint、processor、kafka。

constraint 是一个对象，可以配置对日志字段的一些约束条件，不满足条件的日志会被丢弃。

processor 是一个列表，可以组合多个处理模块，程序将按顺序依次对请求中的每条日志进行处理。实现了如下几种 processor 类型：

  • decoder , 配置原始数据按哪种格式反序列化到 Lua table ，但只实现了 JSON decoder。

  • splitter，配置分隔日志字段的字符。

  • assigner，配置一组字段名映射关系，需要与 spliter 配合。

  • executer， 配置额外的 lua 脚本名称，通过动态加载其他 lua 脚本实现更灵活的处理逻辑。

decoder , 配置原始数据按哪种格式反序列化到 Lua table ，但只实现了 JSON decoder。

splitter，配置分隔日志字段的字符。

assigner，配置一组字段名映射关系，需要与 spliter 配合。

executer， 配置额外的 lua 脚本名称，通过动态加载其他 lua 脚本实现更灵活的处理逻辑。

kafka 是一个对象，可以配置当前业务相关联的 Kafka 集群名，默认投递的 Topic ，以及生产者客户端的工作模式（同步或者异步）。

新版本的改动

HTTP 接口沿用原先的设计，在业务配置部分做了一些改动：

  • processor 改名为 executers ，实现几个通用功能的日志处理模块，方便组合使用。

  • kafka 配置中关联的不再是集群名，而是 Kafka 生产者客户端的配置标签。

  • 原先保存 kafka 集群连接配置信息的配置块，改为保存 kafka 生产者客户端的配置块，统一在一个配置块区域初始化所有用到的 kafka 生产者客户端。

processor 改名为 executers ，实现几个通用功能的日志处理模块，方便组合使用。

kafka 配置中关联的不再是集群名，而是 Kafka 生产者客户端的配置标签。

原先保存 kafka 集群连接配置信息的配置块，改为保存 kafka 生产者客户端的配置块，统一在一个配置块区域初始化所有用到的 kafka 生产者客户端。

一点妥协（做减法）

为了缩短新项目的开发周期，对原始项目的一些不太重要的特性我们做了一些取舍。

取消动态脚本功能

Go 是静态语言没有 Lua 动态语言那么灵活，要加载执行动态脚本有一定的实现难度，且日志处理性能没有保障。

线上只有极少数业务在 processor 中配置了 executor，且这些 executor 的 Lua 脚本实现相近，完全可以抽取出通用的代码。

不支持外部配置中心

为了让发布和回退有记录可回溯，从 Consul 等配置中心热加载服务配置的功能我们也去掉了。利用好容器平台的金丝雀发布功能，就能将服务更新的影响降到最低。

不支持复杂的路由重写

OpenResty 项目内置 Nginx 可以利用 Nginx 强大的配置实现丰富的路由 rewrite 功能，就具体使用场景而言，我们只需要简单的路由映射即可。况且更复杂的需求也可以由上一级网关完成。

选择合适的开源库

Web 框架的选择

使用 Go 开发 Web 应用很快捷。我们参考了如下文章：

  • 《超全的 Go Http 路由框架性能比较》（https://colobu.com/2016/03/23/Go-HTTP-request-router-and-web-framework-benchmark/）

  • 《iris真的是最快的路由框架吗？》（https://colobu.com/2016/04/01/Is-iris-the-fastest-golang-router-library/）

  • https://github.com/kataras/server-benchmarks

《超全的 Go Http 路由框架性能比较》（https://colobu.com/2016/03/23/Go-HTTP-request-router-and-web-framework-benchmark/）

《iris真的是最快的路由框架吗？》（https://colobu.com/2016/04/01/Is-iris-the-fastest-golang-router-library/）

https://github.com/kataras/server-benchmarks

下列几款 Star 较多的 Go Web 框架都能满足我们需求：

  • kataras/iris

  • gin-gonic/gin

  • go-chi/chi

  • labstack/echo

kataras/iris

gin-gonic/gin

go-chi/chi

labstack/echo

他们性能都很好，最终我们选择了 Gin。原因是用得多比较熟，而且文档看着舒服。

Kafka 生产者客户端的选择

社区中热度最高的几款 Go Kafka 客户端库：

  • segmentio/kafka-go

  • Shopify/sarama

  • confluentinc/confluent-kafka-go

segmentio/kafka-go

Shopify/sarama

confluentinc/confluent-kafka-go

实际上三款客户端库我们在历史项目中都使用过，其中 kafka-go 的 API 是三者中最简洁易用的，我们的多个消费端程序都是基于它实现的。

但是在 chopper-go 中仅需要用到生产者客户端，我们没有选择 kafka-go 。那是因为我们做了一些基准测试（https://github.com/sko00o/benchmark-kafka-go-clients ），发现 kafka-go 的生产者客户端存在性能风险：启用 async 模式时尽管消息发送特别快，但是内存占用也增长特别快。

通过阅读源码我也找到了原因并向官方提了 issue（https://github.com/segmentio/kafka-go/issues/819），但是作者觉得这设计没毛病，所以就不了了之了。

最终我们选择 sarama，一方面是性能很稳定，另一方面是它开放的 API 较多，但是用起来确实有点费劲。

测试框架的选择

程序的可靠性，一定需要测试来保证。除了编写小模块中编写单元从测试，我们对整个日志网关服务还要做集成测试。集成测试涉及到一些外部服务依赖，此项目中主要的外部依赖是 Kafka 和 Zookeeper 。

利用 Docker 可以很方便的拉起测试环境，我们注意到了两款可以用来在 Go test 中编写集成测试的库：

  • ory/dockertest

  • testcontainers/testcontainers-go

ory/dockertest

testcontainers/testcontainers-go

使用下来，我们最终选择了 testcontainers-go，简单介绍下原因：

在编写集成测试时，我们需要有个等待机制来确保依赖服务的容器是否准备就绪，并以此控制测试流程，以及测试结束后需要把测试开启的临时容器都清理干净。

testcontainers-go的设计要优于 dockertest。testcontainers-go提供一个 wait 子包，可以配置多种等待策略来确保依赖服务就绪，以及测试结束时它会调用一个特殊的名为 Ryuk 的容器来确保测试容器都被关闭。相对而言，dockertest要简陋不少。

需要注意的是，在 CI 环境运行集成测试都需要确保 ci-runner 支持 DinD ，否则运行 go test 会失败。

项目开发

项目开发过程中基本按照需求来实现没有太多难点。这里分享踩到的几个坑。

循环中变量的引用问题

在测试中发现，Kafka 生产者没有按期望把消息投递到指定的 Kafka 集群。

经过排查到如下代码：

funcNew(cfg Config)(*Manager, error){ varnewProducers = make(NewProducerFuncs) forname, kCfg := rangecfg.Mapping { newProducers[name] = func(kafka.Producer, error){ returnkafka.New(kCfg) } }// 略}

其作用是将配置每个 Kafka 生产者配置先保存为一个函数闭包，待后续初始化 repo 的时候再初始化生产者客户端。

经验丰富的同学可以发现，for 循环的 kCfg 变量其实是指向迭代对象的地址，整个循环下来所有的函数闭包中用到的 kCfg 都指向 cfg.Mapping 的最后一个迭代值。

解决办法很简单，先做一遍变量拷贝即可：

这是个挺容易碰到的问题，参考 https://colobu.com/2022/10/04/redefining-for-loop-variable-semantics/

Go 也有可能在未来将循环变量的语义从 per-loop 改成 per-iteration。

Sarama 客户端的一点坑

对于重要的日志数据，我们希望在 HTTP 请求返回时明确反馈是否成功写入 Kafka 。那么最好将 Kafka 生产者客户端配置为同步模式。

而同步模式的生产者要提高吞吐量，批量发送是必不可少的。

批量发送的配置位于 sarama.Config.Producer.Flush

cfg := sarama.NewConfig// 单次请求中消息数量的绝对上限cfg.Producer.Flush.MaxMessages = batchMaxMsgs// 能够触发请求发出的消息数量阈值cfg.Producer.Flush.Messages = batchMsgs// 能够触发请求发出的消息字节大小阈值cfg.Producer.Flush.Bytes = batchBytes// 批量请求的触发间隔时间cfg.Producer.Flush.Frequency = batchTimeout

实践中发现，如果配置了 Flush.Bytes 而没有配置Flush.Frequency 就存在问题。如果消息大小始终未达阈值就不会触发批量请求，故 HTTP 请求就会阻塞直到客户端请求超时。

所以在配置参数的读取上，我们把这两个配置项做了关联，只有配置了 Flush.Frequency 才能让 Flush.Bytes 的配置生效。

项目上线

容器平台上的灰度技巧

原本图方便我们的路由转发规则配置的是全部路由直接转给同一组 Chopper 实例。

前面介绍了，每一个业务对应一个 repo，也就对应一个独立的请求路径。如果要灰度新的服务，需要对不同业务单独灰度，所以我们需要将不同业务的流量去分开。

好在容器平台的 k8s-ingress 使用的是 APISIX 作为接入网关，其路由匹配的优先级是：绝对匹配 > 前缀匹配。

只需要针对特定业务增加一条绝对匹配规则，就可以分离出特定业务的流量。

举个例子：

原本的转发规则是：/* -> workers-0

我们新建一条转发规则：/log/repo/cdn-access -> workers-1

workers-0 和 workers-1 两组服务的配置完全相同。

然后我们对 workers-1 这组服务灰度发布新版程序。

逐步扩大

每灰度一条路由，我们可以从监控 Dashboard 上观察 HTTP 请求是否有异常，观察 Kafka 对应的 topic 的写入速率是否有异常抖动。

一旦观测到异常，立即停止灰度，然后检查程序运行日志，修正问题后重新开始灰度。

如果无异常，则逐步扩大灰度比例，直到完成服务更新。

总结起来就是灰度、观测、回退、修改循环推进，确保升级对每个业务都无感知。

完成发布

对比服务端资源占用情况

旧版 chopper (4C8G x 20) 灰度比例 10% -> 50%

chopper-go (4C4G x 20)

10% -> 50%

50% -> 100%

结论：新版日志网关的内存和 CPU 的资源使用都有显著降低。

服务端程序的资源占用情况

旧版 chopper 的 Kafka 客户端不支持消息压缩，chopper-go 发布中就配置了 Kafka 生产者消息的功能。

压缩算法选择 lz4 ，观察两组消费服务的资源实用率的变化：

消费服务0

  • 内存使用率 27% -> 40%

  • 网络流入 253Mbps -> 180Mbps

内存使用率 27% -> 40%

网络流入 253Mbps -> 180Mbps

消费服务1

  • 内存使用率 28% -> 39%

  • 网络流入 380Mbps -> 267Mbps

内存使用率 28% -> 39%

网络流入 380Mbps -> 267Mbps

结论：开启消息压缩功能后，消费实例的内存使用率普遍有增长，但内网传输带宽占用降低约 30% 。

更新计划

重构后的流式日志网关，尚有许多可优化空间，例如：

  • 采用更节省带宽的日志传输格式；

  • 进一步细化 Kafka topic 的分流粒度；

  • 日志消息处理阶段多级处理执行器之间增加缓存提高字段访问速度等等。

采用更节省带宽的日志传输格式；

进一步细化 Kafka topic 的分流粒度；

日志消息处理阶段多级处理执行器之间增加缓存提高字段访问速度等等。

在丰富开源生态的加持下，该项目的优化迭代也将有条不紊地进行。

END

微软Edge正在偷窥你

这里有最新开源资讯、软件更新、技术干货等内容