Soul 云原生网关最佳实践

公司介绍

Soul 是基于兴趣图谱和游戏化玩法的产品设计，属于新一代年轻人的虚拟社交网络。成立于2016年，Soul 致力于打造一个“年轻人的社交元宇宙”，最终愿景是“让天下没有孤独的人”。在 Soul，用户可以无顾虑地表达自己，认知他人，探索世界，交流兴趣和观点，获得精神共鸣和认同感，在交流中获取信息，并获得有质量的新关系。

问题与挑战

2.1 多层网关链路长

Soul 在 2020 年开始逐渐试探容器服务，在 ECS 转型容器阶段，出现了容器入口网关(Ingress-Nginx)，微服务网关，加上统一接入层的 SLB+Tengine；造成了多重网关的架构；链路太长不仅带来成本和 RT 的问题，而且导致排查一个请求异常，需要拉非常多的人解决，定位问题代价非常大。

2.2 Ingress-Nginx 开源问题

今年 Ingress-Nginx 社区反馈稳定性和安全问题比较多，暂时停止接收新功能，对 Soul 是一个巨大隐患。

2.3 Grpc 转发负载不均衡问题

  1. 内网部分服务开放 gRPC 入口，gRPC 是基于 HTTP/2 之上的，而 HTTP/2 被设计为一个长期存在的 TCP 连接，所有都通过该连接进行多路复用。这样虽然减少了管理连接的开销，但是在负载均衡上又引出了新的问题。
  2. 由于我们无法在连接层面进行均衡，为了做 gRPC 负载均衡，我们需要从连接级均衡转向请求级均衡。换句话说，我们需要打开一个到每个目的地的 HTTP/2 连接，并平衡这些连接之间的请求。
  3. 这就意味着我们需要一个 7 层负载均衡，而 K8s 的 Service 核心使用的是 kube proxy，这是一个 4 层负载均衡，所以不能满足我们的要求。
  4. 目前使用独立 evnoy + headless 方案解决 gPRC 转发不均衡问题，slb 暴露 envoy 的端口供其他服务调用；但维护成本较高，evnoy 节点资源浪费较为严重

2.4 Ingress 稳定性及局限性

1.由于业务的不确定性，随着业务请求的波动，nginx ingress controller 会出现连接数突增，导致 ingress controller 健康检查不通过；nginx ingress controller上游的检测需要时间及 fail 次数积累，导致这一阶段用户请求大量失败或重试。(如下图)

2.HTTP 路由仅支持 host 和 path 匹配，对于高级路由功能没有通用配置，只能通过 annotation 来实现，比如使用 Nginx Ingress Controller 实现 URL 重定向，需要配置 http://nginx.ingress.kubernetes.io/rewrite-target annotation 已无法适应可编程路由的需求。

3.不同命名空间中的服务要绑定到同一个网关中的情况在实际情况下经常出现，而入口网关无法在多个命名空间中共享；这样就增加 Ingress-Nginx 及 Ingress-Controller的拆分难度。

2.5 业务发布抖动

  1. 虽然 Kubernetes 自身具备优雅线上机制，及 Liveness 和 Readiness 等就绪检查，但服务启动后，瞬间开始接收请求，服务还是会受到瞬间流量的冲击及链接层面的压力。
  2. 服务发布可分为多批，但我们将整个发布过程中看做整体时，看到的是服务RT忽然升高，造成局部业务阶段性响应变慢，给用户最直观的感受是卡顿（单次请求较慢或请求失败后的重试），在用户侧可能感知到服务降级或服务不可用，从而影响用户体验。

技术选型

由于开源 Ingress-Nginx 遇到比较多的问题，由于线上流量巨大难以定位和解决概率超时问题，因此我们考虑投入更多研发人员解决这个问题，还是选择 Envoy 网关解决，还是选择阿里云 ASM、MSE 云原生网关两个产品，因此我们针对这三个新技术方向做了全面评估。

综上所述, Envoy 已是现阶段数据面较好的选择(可以解决现有nginx ingress controller的性能和稳定性问题)，由于性能要求比较高，因此我们优先做了性能压测。

3.1 压测数据

我们通过对线上服务三种不同方案的压测数据对比（SLB+Envo+headless svc、ALB、MSE），主要测试性能和 gRPC 负载均衡能力两方面；压测数据显示，MSE 云原生网关在 RT 和成功率上均有优势，并且能满足 Soul gRPC 的转发需要；那 MSE 是否能满足 Soul 所有业务需求呢？是否能解决最大集群超时问题呢？因此我们对 MSE 进行了更全面的评估。

3.2 全面技术评估

  • 对 MSE 云原生网关进行功能、稳定性、性能、安全等全方位评估，看看是否满足 Soul 未来要求。

  • Soul 的业务场景比较复杂，评估 MSE 云原生网关将流量网关、微服务网关、安全网关三合一，集成 10+ 云产品，开箱即用，满足业务需求。

  • Soul 对稳定性要求非常高，任何抖动都会导致大量用户影响，考虑 MSE 云原生网关经历阿里双十一大规模生产验证，久经打磨，奠定了我们生产使用的信心。

  • 由于 Soul 流量非常大，网关机器规模大，因此成本是一个关键的考量点，压测显示 MSE 云原生网关采用软硬一体解决方案，比自建性能高 1 倍左右。

  • Soul 后端有大量 Dubbo 服务，目前通过自研业务网关做 HTTP 到 Dubbo 协议转换，考虑 MSE 云原生网关支持 HTTP 到 Dubbo 协议转换，支持直接挂 Dubbo 服务，有利于未来架构收敛。

3.3 迁移方案

  • 由于 MSE 兼容 Ingress 标准，因此创建完云原生网关实例，监听已有的 Ingress 资源，就可以直接迁移后端到路由转发规则；
  • MSE 与 Ingress-Nginx 可以共存，因此只需要从上游把流量从 Ingress-Nginx 逐渐切到 MSE 云原生网关即可，按照不同的域名进行灰度，降低变更风险。
  • 在 Soul 的场景中，流量切换 MSE 后，Ingress-Nginx 没有完全的下线，保持了 2 个节点，并增加 HPA 配置，以备不时之需；
  • gRPC 转发 MSE 替换原有的独立 Envoy，业务服务修改 svc 中服务暴露协议及端口即可，逐个服务迁移；

3.4 技术方案

3.4.1 短期方案

Soul 的网关链路比较长，解决最紧迫超时问题、服务发布预热问题，因此第一期先替换Ingress-Nginx，并将容器入口网关/微服务网关合并；

3.4.2 终态方案

将网关链路降为最短；下线微服务网关，将http转发rpc能力托管MSE；下线Tengine，将 ECS 转发能力托管在 MSE；最终实现 SLB->MSE->POD/ECS04

落地效果

4.1 稳定性及 RT 前后对比

MSE 切换后处理及响应请求时间平稳，从峰值 500ms 下降至峰值 50ms

4.2 服务发布产生的错误码对比

Ingress-Nginx 与 MSE 错误码对比，服务发布期间 502 降为 0，499 平均降低 10%;

4.3 预热与启动 RT 问题

落地解决了大部分超时问题，但是启动慢 Java 程序发布超时问题还没解决，因此我们开启服务预热功能，业务启动逐步打流量过来，防止大量流量打到刚启动 Java 进程超时。

开启预热效果：从图中可以看出，Pod 在刚刚启动后，并没有瞬间接收到全量，而是在 5 分钟的时间里逐渐预热服务，这一点在服务 http 入口请求数量，Pod 网络进出流量，Pod CPU 使用率均可以看到；Nginx 需要自己从底层到上层的各种监控，采用云原生网关后，提供一站式观测视图，提供丰富网关 prometheus 指标，方便观测和解决复杂问题。

未来规划

  1. 采用云原生网关将流量、安全、微服务网关三合一，大幅降低请求链路条数、降低架构复杂度
  2. 降低运维和排查成本，降低整个链路 RT，提升客户满意度。
  3. 开启 HTTP 3.0，提升网络传输效率，提升客户体验
  4. 采用服务自治（在线抓包、诊断、巡检）降低排查问题消耗
  5. 采用混沌工程提前识别稳定性风险；

MSE 实践价值

1. 随着MSE 的落地，可以看到链路明显缩短，问题排查及运维工作大大减少
2. 替代业务网关，Http转Dubbo能力的抽象，大大减少了研发及运维工作量3. 稳定性及平滑迁移方案完善，可以做到真正的开箱即用

原文链接

本文为阿里云原创内容，未经允许不得转载。