Soul 云原生网关最佳实践

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

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 节点资源浪费较为严重

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

   
   

2. HTTP 路由仅支持 host 和 path 匹配，对于高级路由功能没有通用配置，只能通过 annotation 来实现，比如使用 Nginx Ingress Controller 实现 URL 重定向，需要配置 nginx.ingress.kubernetes.io/rewrite-target annotation 已无法适应可编程路由的需求。
3. 不同命名空间中的服务要绑定到同一个网关中的情况在实际情况下经常出现，而入口网关无法在多个命名空间中共享；这样就增加 Ingress-Nginx 及 Ingress-Controller的拆分难度。

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

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

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

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

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

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

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

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

1. 采用云原生网关将流量、安全、微服务网关三合一，大幅降低请求链路条数、降低架构复杂度

2. 降低运维和排查成本，降低整个链路 RT，提升客户满意度。
3. 开启 HTTP 3.0，提升网络传输效率，提升客户体验
4. 采用服务自治（在线抓包、诊断、巡检）降低排查问题消耗
5. 采用混沌工程提前识别稳定性风险；