浅谈Service＆nbsp;Mesh对业务系统的价值

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是云原生下的微服务平台，能更好的适配云原生环境下服务和流量支持。