Service Mesh 平台实现 SideCar 与业务系统解耦，能降低 SDK 升级成本，开发代码不受语言和框架限制，但是想说服这些技术栈统一、技术成熟度不高的业务系统项目负责人进行 Mesh 化改造还是挺难的，一是他们就听不懂这些高大上的技术术语和原理，二是现有的技术也基本满足他们的技术需求，Mesh 化改造还需要一些额外如容器化、联调测试、压力测试和网络策略迁移等工作量。我试着从如下几个方面进行讲解，由于能力有限，有不对的地方还请大家指出。

大流量场景

在大流量场景下，当流量徒增、集群负责过高时，可以借助容器云自动扩缩容能力来缓解流量压力，Service Mesh 可以同步监听到新增扩容节点，更快速将流量打到新节点中，全过程自动化无需手工配置，这要比 F5 手工配置和基于 Eureka 的注册发现机制更加快速高效；当单节点流量压力无法缓解时，可以通过连接数和令牌桶两种限流策略，能有效降低流量压力，防止服务被压垮；也可以通过轮询、随机和最小请求量等多种负载均衡策略，及多中心负载均衡能力，实现更加均匀的流量分发，降低单节点压力。

稳定性要求较高场景

在稳定性要求较高场景下，当服务节点不可用时，根据健康探针，识别故障实例并进行自动隔离，相较于基于 Eureka 被动心跳机制实现的隔离，更加快速和准确；平台所提供的跨中心容灾能力，支持业务系统同城双活，进一步提升系统稳定性；借助容器云能力，支持服务异常线下重启，不仅支持物理机或虚机故障重启，还支持服务进程异常重启，相较于微服务基于 Eureka 心跳机制，Service Mesh 更加快速和准确，有效减少流量打到宕机节点；当下游服务出现不可用情况下，平台的熔断机制可以防止上游整个调用链服务的雪崩，保护整个交易链路服务的稳定。

灰度发布场景

在灰度发布场景下，平台提供的流量无损部署上线下线，支持业务系统上下线服务可用；金丝雀发布提供了在不停服情况下，自动平滑的部署新版本能力，实现无需手工干预即可完成服务的版本升级更新，确保业务系统稳定高效平滑迭代升级；平台还提供了按照一定的目标策略进行流量灰度，如 Android 用户看到 V2 版本，其他用户看到 V1 老版本，实现 A/B 测试，统计 V1 和 V2 的转化率、点击量、留存率等指标，以判断不同方案的优劣并进行决策；通过手动配置流量负载比例，将较大比例量如 80%的流量，打到少数几个新版本节点上，实现线上实际场景的压力测试，确保线上新版本稳定运行；

安全

在安全方面，支持 HTTPS 请求和服务级黑白名单访问限制，可以对重要服务进行保护；也通过在 API 网关配置 IP 黑白名单，限制 IP 访问，比如只开 F5 到网关的 IP 白名单，可以有效防止未知 IP 访问网关。

平台边缘流量治理能力，通过进出入网关，可以为系统提供统一入口出口流量管理，除常规流量负载及灰度、限流等重归功能外，还提供收敛 IP 和网络策略，从而支撑网格内业务服务 IP 不固定，网络策略无需重复申请。

混沌测试场景

在混沌测试场景下，0 代码实现错误注入 500 等状态码、延迟一定时间返回等故障注入，提升服务健壮性。

提供的无侵入式的监控，除 JVM、内存、CPU、调用量等常规监控能力外，平台还提供节点及 API 级别调用量和响应时间，服务拓扑和链路监控，可以更加清晰的进行问题定位；通过手机监控小程序，可以实时接收告警及查看线上运行情况。

多语言支持场景

在多语言支持场景下，开发代码不受语言和框架限制，通过容器化和 Mesh 化改造，可实现上述能力。

技术架构对比

下图是几个代表技术架构的对比：

说明：

• 表中大部分是按照原生技术进行对比，不涉及到公有云产品和公司内部的二次开发平台，所以对比有一定的局限性；

• 单体服务可以通过 JMX exporter 或 Zabbix 监控 JVM；

• 表中灰度发布是在容器 IP 不固定场景下，Spring Cloud 原生无法做到不同 Deployment 版本下的流量治理。

总结

传统单体服务几乎没有上述服务和流量治理能力，云原生容器环境下的原生 Spring Cloud 技术（二次开发适配容器能力除外）明显在大流量、稳定性及灰度等场景有明显不足。Service Mesh 是云原生下的微服务平台，能更好的适配云原生环境下服务和流量支持。