Service Mesh的价值到底在什么地方

背景介绍:

今年有幸加入了Service Mesh小组的研发当中，经过几个月的摸索，算是对Service Mesh有了一个初步的认识。旁边也是不停的有朋友问我，Service Mesh价值是什么？为什么我要用这个东西？

也正是基于这些原因，我特意整理了下这篇文章，发表一下自己的浅见并分享出来，希望对大家有帮助。

问题：Service Mesh的核心在哪里？它到底做了什么事情？

我想大家在看到这个问题的时候，肯定会毫不犹豫的说是“流量劫持”或者“流量代理”。

对，Service Mesh的核心关注点在流量，它做的事情就是对流量的接收和管理。

价值所在:

第一，通过sidecar的方式部署，做到与业务解耦合。

有人可能会对这个事情不屑一顾，觉得代理而已，有什么特别的，市面上有很多。的确如此，可是Service Mesh代理的方式却与别人不同，它搭上了K8S这辆高速列车，它使用sidecar做代理，依附于微服务。如此以来，它就变得与众不同了，因为sidecar可以单独部署，也就是说流量这部分功能逻辑可以与业务代码解耦，可以替代代码封装好的soa -sdk，业务终于可以不用在soa-sdk发布版本的时候，被迫升级了，并且这个价值会随着微服务数量的增多，越来越明显。

第二，实现可配置的路由功能。

有了流量劫持之后，Mesh就可以做路由转发功能，这些功能包括根据host，接口api，header里指定的tag这几个几个粒度去做路由转发。而这些路由配置是可以通过配置的方式，去动态的下发到Mesh上面来的。

如此以来，业务就对这些流量的走向就有了控制权，可以通过改改配置就能达到自己想转发给哪一些上游服务的目的，比如:灰度发布，是不是方便了很多。

第三，实现可配置的流量管控能力。

在流量被劫持之后，mesh其实就有了对整个流量的管控能力。除了第二点的路由转发功能，Mesh还可以对流量作异常处理，包括:限流、熔断、流量镜像等。

而他们产生的价值也很高，业务可能只需要配置更改就可以支持自己希望的流量限速和熔断功能。甚至在线上发觉流量不对劲的时候，改改配置镜像一波流量出来，就可以分析和定位问题，是不是很方便。

第四，注入错误的流量，提供异常测试和混沌工程。

有了流量管控之后，我们除了劫持正常流量之外，还可以注入异常流量，例如模拟http的err code等。当然这些也是通过动态配置做到的，既方便又灵活，可以说是测试阶段的一大助力。

第五，对零信任网络提供支撑。

流量除了本身的价值之后，还涉及到了另外一个问题，网络安全。网络安全又是跟流量是强绑定的，而证书的又可以理解为另一种方式的配置。这么去看问题的话，Mesh实现的功能，就可以很容易的去支持流量安全的内容，业务只需要配置相关的证书，然后下发到Mesh就可以达到网络安全的目的，只要业务接入了Mesh，安全就可以统一的去收口处理。

第六，流量的可观察性带来的价值。

既然流量被劫持到了Mesh上面，出口和入口都在的话，Mesh就可以对这些流量进行监控，打点，采集，统计。而这些数据，对用户来说就很有价值，他们可以定制自己希望观测的指标，然后配置到Mesh，有Mesh来做metric的采集和上报，即灵活又方便。

在问题排查阶段，往往线上出了问题之后，不知道到底哪一个服务有问题，而全链路追踪恰恰就能很好的解决这个问题。尽管市面上有很多全链路追踪工具，并且很多都可以通过SDK的方式让业务无感知，但是Mesh的引入之后，可以轻松的去给这些数据进行埋点，甚至可以让这些埋点的内容做些定制化处理，业务和SDK只需要做一些简单的流量层面的Header透传就可以实现。

总结： 以上的六点，只是笔者自己的一些浅陋看法，如有不同看法和观点，欢迎留言给我，谢谢。