共计 3209 个字符，预计需要花费 9 分钟才能阅读完成。
公司介绍
Soul 是基于趣味图谱和游戏化玩法的产品设计，属于新一代年轻人的虚构社交网络。成立于 2016 年，Soul 致力于打造一个“年轻人的社交元宇宙”，最终愿景是“让天下没有孤单的人”。在 Soul，用户能够无顾虑地表白本人，认知别人，摸索世界，交换趣味和观点，取得精力共鸣和认同感，在交换中获取信息，并取得有品质的新关系。
问题与挑战
2.1 多层网关链路长
Soul 在 2020 年开始逐步试探容器服务，在 ECS 转型容器阶段，呈现了容器入口网关 (Ingress-Nginx)，微服务网关，加上对立接入层的 SLB+Tengine；造成了多重网关的架构；链路太长不仅带来老本和 RT 的问题，而且导致排查一个申请异样，须要拉十分多的人解决，定位问题代价十分大。
2.2 Ingress-Nginx 开源问题
往年 Ingress-Nginx 社区反馈稳定性和平安问题比拟多，临时进行接管新性能，对 Soul 是一个微小隐患。
2.3 Grpc 转发负载不平衡问题
内网局部服务凋谢 gRPC 入口，gRPC 是基于 HTTP/2 之上的，而 HTTP/2 被设计为一个长期存在的 TCP 连贯，所有都通过该连贯进行多路复用。这样尽管缩小了治理连贯的开销，然而在负载平衡上又引出了新的问题。
因为咱们无奈在连贯层面进行平衡，为了做 gRPC 负载平衡，咱们须要从连贯级平衡转向申请级平衡。换句话说，咱们须要关上一个到每个目的地的 HTTP/2 连贯，并均衡这些连贯之间的申请。
这就意味着咱们须要一个 7 层负载平衡，而 K8s 的 Service 外围应用的是 kube proxy，这是一个 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.kubernet… annotation 已无奈适应可编程路由的需要。
3. 不同命名空间中的服务要绑定到同一个网关中的状况在理论状况下经常出现，而入口网关无奈在多个命名空间中共享；这样就减少 Ingress-Nginx 及 Ingress-Controller 的拆分难度。
2.5 业务公布抖动
尽管 Kubernetes 本身具备优雅线上机制，及 Liveness 和 Readiness 等就绪查看，但服务启动后，霎时开始接管申请，服务还是会受到霎时流量的冲击及链接层面的压力。
服务公布可分为多批，但咱们将整个公布过程中看做整体时，看到的是服务 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 指标，不便观测和解决简单问题。
将来布局
- 采纳云原生网关将流量、平安、微服务网关三合一，大幅升高申请链路条数、升高架构复杂度。
- 升高运维和排查老本，升高整个链路 RT，晋升客户满意度。
- 开启 HTTP 3.0，晋升网络传输效率，晋升客户体验。
- 采纳服务自治（在线抓包、诊断、巡检）升高排查问题耗费。
- 采纳混沌工程提前辨认稳定性危险；
MSE 实际价值
- 随着 MSE 的落地，能够看到链路显著缩短，问题排查及运维工作大大减少 2. 代替业务网关，Http 转 Dubbo 能力的形象，大大减少了研发及运维工作量 3. 稳定性及平滑迁徙计划欠缺，能够做到真正的开箱即用原文链接本文为阿里云原创内容，未经容许不得转载。
