Istio on Yeqown

在 Kubernetes 中实现 gRPC 流量的镜像和对比

Thu, 08 May 2025 09:35:14 +0800

本文主要解决在服务重构过程中如何保证新旧服务行为一致性的问题。

场景描述#

现有一个 python 开发的 gRPC 微服务提供了一些 数据查询 接口供上层应用使用，随着业务流量的增加运维这个服务的成本也逐渐增加，为了降低运维成本和提高性能 (木有擅长 python 高性能的开发)，因此选择了使用 go 语言对这个服务进行重写。在开发完成之后，需要对新服务的 gRPC 接口进行验证。

这种场景对测试开发人员来说，实在是太熟悉了吧？典型的 重放验证，马上能想到的验证手段就是：

如果有存量的单元测试，那么直接重新跑一遍单元测试就能快速的完成验证。
没有单元测试的情况，那么可以将新服务部署起来，通过流量复制的方式将旧服务的流量复制到新服务上，然后对比两个服务的返回结果是否一致。

flowchart LR
    %% 定义布局方向和间距
    subgraph s1["方案一: 单元测试验证"]
        direction TB
        UT[单元测试] -->|执行| NS1[新服务]
    end
    
    subgraph s2["方案二: 流量复制验证"]
        direction TB
        C[客户端] -->|请求| OS[旧服务]
        OS -->|响应| C
        OS -->|复制流量| NS2[新服务]
        NS2 -->|对比响应| OS
    end

    %% 设置布局方向和对齐方式
    s1 ~~~ s2

但是很遗憾 😭，并没有成熟的单元测试；测试人员也都是人肉测试，对于内部服务的接口验证帮助不大，因此这里采用第二种方式进行验证。

服务均采用 Kubernetes 部署。

方案介绍#

HTTP 流量的复制重放工具就很多很成熟了，而且往往在网关/代理一侧就能实现流量复制甚至对比。

工具	分类	文档链接
Nginx mirror	网关/代理	https://nginx.org/en/docs/http/ngx_http_mirror_module.html
APISIX	网关/代理	https://apisix.apache.org/docs/apisix/plugins/proxy-mirror/
Istio: Virtual Service mirror	Service Mesh	https://istio.io/latest/docs/tasks/traffic-management/mirroring/
GoReplay	流量镜像	https://github.com/buger/goreplay
tcpcopy	流量镜像	https://github.com/session-replay-tools/tcpcopy

tcpcopy 相比于其他工具方案，虽然不能直接使用，但是其作用于 TCP 传输层，功能会更丰富。相比之下，gRPC 流量复制工具就没有那么成熟了。

近期的一些经验总结

Tue, 17 Dec 2024 16:50:41 +0800

这里不会过多的介绍软件的相关概念和架构，主要是针对实际问题的解决方案和思考。

问题汇总#

CDC 相关
更新于: 2025-02-06
- CDC Elasticsearch sink 怎么自定义索引名称？
- 自定义 transform 实现自定义索引名称
更新于：2025-10-11
- CDC kafka-connect mongodb 侧反复进行 “快照” 导致数据同步异常
更新于：2026-06-01
- CDC Elasticsearch sink 假性的消费堆积问题
DMS 数据同步相关
- 数据迁移完成后，怎么对比源数据和目标数据是否一致？
- 如果不一致怎么处理？
Istio 相关
- Istio 中多个 gateway 使用相同 host，analyze 是提示错误
- Istio 中一个服务提供了多个端口的服务，怎么配置 Virtual Service ？
APISIX 相关
- 使用 APISIX 作为网关，怎么进行有条件的响应重写？
- APISIX 插件的执行顺序是怎么样的？
ShardingSphere Proxy

Istio Idle Timeout问题复现和解决

Mon, 25 Mar 2024 09:37:25 +0800

更新#

更新 2024-04-01#

通过调整 tcp_proxy 的 idle_timeout 参数后，部分中间件（redis, mongo）的异常问题不再出现，但是 mysql(sharding-spere) 和 memcached 仍然存在 “invalid connection” 错误，所以还需要找到能够解决 mysql(sharding-spere) 和 memcached 的方法。

上述描述的现象非常主观，不一定正确也不能作为最终结论，但是 idle_timeout 配置确实没有解决所有的问题。

这里，需要知道 istio 在 inject 时会通过 iptables 对应用的流量进行劫持，对于 outbound 的流量 iptables 规则拦截转发到 OUTPUT 链。OUTPUT 的链转发流量到 ISTIO_OUTPUT，这个链会决定服务访问外部服务的流量发往何处。

这样产生的效果是，除了应用自己建立的连接之外 envoy 也会创建一个代理连接。

$ netstat -notp | grep 3307
tcp         0             172.23.105.25:41030        x.x.x.x:3307         ESTABLISHED -      off(0.00/0/0)
tcp         0             172.23.105.25:41022        x.x.x.x:3307         ESTABLISHED 1/./app      keepalive(0.88/0/0)

我遇到的问题可以确定问题就出在 envoy 建立的连接上，因为应用自己建立的连接是正常的，同时还可以看到应用自己的连接开启了 keepalive, 而 envoy 建立的连接没有开启。这样可能会出现这个连接会因为超时而被关闭的情况，或者其他原因导致连接被释放。那如果可以避免将中间件的流量通过 envoy 代理，这样就可以避免这个问题。

在官方的文档中也提到，https://istio.io/latest/zh/docs/tasks/traffic-management/egress/egress-control/ 对于外部服务，可以通过配置 excludeOutboundPorts 或者 excludeOutboundIPRanges 来使得某些服务的流量不经过 istio sidecar。其背后的原理是通过 iptables 的规则中排除这些端口或者 IP 地址。

在istio服务网格中扩展自定义功能

Fri, 17 Nov 2023 22:48:59 +0800

前提#

本文假设你已经对 Kubernetes、istio 和 Envoy 有一定的了解，如果你还不了解，可以先阅读下面的文章：

当然不仅限于知道这些，还需要对其有一定的实践经验，这样才能更好的理解本文的内容。当然本文也不会涉及太深，只是作为 istio 的一个入门扩展教程。

为什么要扩展功能？#背景#

用通俗的话去理解 istio 的作用就是，对我们部署在 kubernetes 上的应用进行流量控制（代理），给我们提供了：流量控制、流量监控、流量安全等功能。但是在实际的使用中，我们还是会遇到一些特殊的场景，需要我们自己基于自己的业务场景去扩展一些功能，比如：ip 白名单、ip 黑名单、统一认证等。这些功能往往和具体公司的业务场景有关，因此 istio 无法直接提供这些功能，需要我们自己去扩展。

传统的扩展方式#

在传统架构中，常常通过 API 网关这一组件来实现这一些扩展能力，常用的 API 网关有：kong、apisix、openresty，而扩展的原理就是插件，或者像 nginx/openresty 在请求链中的不同阶段提供了不同的 hook，我们可以基于这些 hook 来实现扩展功能。

就我个人的经历来说，网关要么自己定制开发，要么基于openresty来实现，又或者使用一些开源的网关，如：kong、apisix，在此基础上进行二次开发。不过这些方式都是在传统API网关中去实现的，随着 Service Mesh 的发展，API网关的某些功能也被 Sidecar 代理所取代，比如：流量控制、流量监控、流量安全等。目前 Mesh 发展的趋势也是进一步在 Sidecar 代理中实现更多的功能，而不是在 API 网关中实现。

Envoy 的扩展能力#

https://www.envoyproxy.io/docs/envoy/latest/extending/extending

https://www.youtube.com/watch?v=XdWmm_mtVXI

envoy 提供了丰富的扩展能力，Access Logger, Access Log Filter, Clusters, Listen Filter, Network Filter, HTTP Filter 等等。这一块内容非常多，如果想要了解更多，请参考官方文档。

istio 的扩展能力#

https://istio.io/latest/docs/reference/config/networking/envoy-filter/

istio 作为一个 Service Mesh 框架，其底层的代理是 Envoy，因此 istio 也继承了 Envoy 的扩展能力。istio 提供了 EnvoyFilter 这样一种自定义 istio Pilot 生成的 Envoy 配置的机制。可以修改某些字段的值、添加特定过滤器。对于特定命名空间中的给定工作负载，可以存在任意数量的 EnvoyFilter。这些 EnvoyFilter 的应用顺序如下：配置根命名空间中的所有 EnvoyFilter，然后是工作负载命名空间中的所有匹配的 EnvoyFilter。