高频新增服务场景下istio-ingress与nginx-ingress该如何选型？

针对你描述的每秒10次新增服务路由、且要求不影响现有连接的场景，Istio方案远优于原生Nginx Ingress方案，具体分析如下：

原生Nginx Ingress方案的问题 #

• 原生Nginx Ingress控制器每次新增/修改Ingress资源，都会触发全量的nginx -s reload操作：虽然Nginx的reload是优雅流程，会等待旧worker进程的现有连接结束后再销毁进程，但你每秒10次的高频更新会导致旧worker进程大量累积，占用过高内存，极端场景下会出现新请求超时、长连接中断的问题，完全无法满足不影响现有连接的要求。
• 如果你倾向于使用Nginx技术栈，可以替换为基于OpenResty实现的Ingress控制器（如APISIX Ingress、Kong Ingress），这类控制器的路由规则更新完全在内存中完成，不需要触发reload，也能满足你的需求。

Istio方案的优势 #

Istio新增VirtualService路由规则的逻辑和Nginx Ingress完全不同：

• 控制面Pilot会通过xDS协议将更新后的路由配置动态推送给Istio Gateway的Envoy数据面实例，整个更新过程是内存级热更新，不需要重启或重载任何数据面进程，不会中断任何现有连接，完全符合你的业务要求。
• 每秒10次的配置更新对Pilot的压力极小，且Istio支持增量配置推送，只会将对应新服务的路由规则推送给需要感知的Gateway实例，不会产生冗余的全量配置推送开销，长期运行稳定性很高。

补充优化建议 #

• 路由规则仅绑定到Istio Gateway即可，不需要配置全网格sidecar感知该类路由，可进一步降低配置推送的范围和开销。
• 生产环境可以开启Pilot的配置分发缓存，进一步降低高频更新场景下的控制面负载。

内容的提问来源于stack exchange，提问作者Huan