学不动了古典、SOA、传统、K8S、ServiceMesh( 三 ) _SOA

虽然K8S可以做一部分服务发现的工作，我们还是需要在客户端中去实现更多的一些弹力方面的功能，因此我认为2.0时代只是说是微服务框架结合容器、容器调度，而不能是脱离微服务框架本身完全依靠K8S实现微服务。2.0和1.0的本质区别或者说增强还是很明显，那就是我们可以全局来统筹解决我们的微服务部署和可靠性问题，在没有容器和容器调度这层抽象之前，有的公司通过实现自动化虚拟机分配拉起，加上自动化初始脚本来实现自动的微服务调度扩容，有类似的意思，但是非常花时间而且速度慢。K8S真正让OPS成为了DEV而不是执行者，让OPS站在总体架构的层面通过DEV（咱不能说开发DSL文件不算开发吧）资源和资源之间的关系来统筹整个集群。在只有十几个微服务若干台服务器的小公司可能无法发挥2.0容器云的威力，但是服务器和服务一多，纯手工的命令式配置容易出错且难以管理，K8S真的释放了几十个运维人力。
6、微服务v3.0——ServiceMesh服务网格玩法

文章插图

在之前提到过几个问题：

SOA的模式虽然简单，但是集中的Proxy在高并发下性能和扩容会是问题
传统的RPC方式，客户端很重，做了很多工作，甚至协议转换都在客户端做，而且如果涉及到跨语言，那么RPC框架需要好几套客户端和服务端
K8S虽然是一个重要的变革，但是在服务调度方面还是太弱了，它的专项在于资源调度

于是ServiceMesh服务网格的概念腾空而出，巧妙解决了这几个问题：

采用边车模式的Proxy随服务本身部署，一服务一边车与服务共生死（当然，有的公司会使用类似ServiceBus的Global Proxy作为Sidecar Proxy的后备，防止服务活着Sidecar死了的情况）可以解决性能问题
Sidecar里面做了路由、弹力等工作，客户端里可以啥都不干，如上图所示，上图是Istio的架构，Istio的理念是把ServiceMesh分成了数据面和控制面，数据面主要是负责数据传输，由智能代理负责（典型的组件是Envoy），控制面由三大组件构成，Pilot负责流量管理和配置（路由策略、授权策略）下发，Mixer负责策略和数据上报（遥测），Citadel用于密钥和证书管理
由于我们双边都走Sidecar Proxy，我们对于流量的进出都可以做很细粒度的控制，这个控制力度是之前任何一种模式都无法比拟的，这种架构的方式就像把服务放到了网格之中，服务连接外部的通讯都由网格进行，服务本身轻量且只需要关注业务逻辑，网格功能强大而灵活
对于Proxy的流量劫持可以使用IP table进行拦截，对于服务本身无感知，而且Sidecar可以自动注入Pod，和K8S进行自动整合，无需特殊配置，做到透明部署透明使用
Pilot是平台无关的，采用适配器形式可以和多个平台做整合，如果和K8S整合的话，它会和API Server进行通讯，订阅服务、端点的信息，然后把信息转变成Istio自己的格式作为路由的元数据
Mixer期望的是抽象底层的基础设施，不管是Logging还是Metrics、Tracing，在之前RPC时代的做法是客户端和服务端都会直接上报信息到InfluxDb、Tracing Server等，这让客户端变得很臃肿，Istio的理念是这部分对接后端的工作应该由统一的组件进行，不但使得Proxy可以更轻而且可以通过Plugin机制对接各种后端基础设施

说了这么多ServiceMesh的优势，我们来看一下这种模式的性能问题。想一下各种模式下客户端要请求服务端整个HTTP请求（跳）次数：

古典模式：2跳，代理转发一次
SOA模式：2跳，总线转发一次
传统模式：1跳，客户端直连服务端
K8S Service模式：1跳（路由表会有一定损耗）
ServiceMesh模式：3跳（其中2跳是localhost回环）

总的来说，3跳并不是ServiceMesh的瓶颈所在，而更多的可能性是Istio的倔强的架构理念。Istio认为策略和遥测不应该耦合在Sidecar Proxy应该放到Mixer，那么相当于在调用服务的时候还需要额外增加Mixer的同步请求（来获得策略方面的放行）。Istio也在一直优化这方面，比如为Mixer的策略在Proxy做本地缓存，为遥测数据做批量上报等等。虽然经过层层优化，但是Istio目前的TPS不足2000，还是和一般的RPC能达到的20000+有着十倍的差距，说不定将来Istio会有架构上的妥协，把Mixer变为非直接依赖，策略方面还是采用类似Pilot统一管理配置下发的方式，遥测方面还是由Sidecar直接上报数据到Mixer 。
我个人认为，ServiceMesh是一个非常正确的道路，而且ServiceMesh和K8S结合会更好，理由在于：