Service Mesh 发展已经有 6-7 年的时间，很多人对 Service Mesh 只停留在了解和知道的水平上，特别是很多技术人第一次接触到 Service Mesh，看到服务网格的解释，看到 Istio 的架构，对这门技术仍然云里雾里。劝退大多数人的不是技术，而是概念本身。

大部分的架构演进止步于微服务

架构的演进都是为了解决问题，然而现实是，大部分的公司架构演进止步于微服务。

微服务现在大行其道，但是对于大多数的公司而言，除非使用 Java 等又大量框架和库能支持快速落地，其他语言技术栈可能找一些稍微通用的框架修修改改。甚至见过 RESTful API 格式提供的服务，以手写 SDK 调用其他服务，这种还没有服务发现机制。

现实有两点：

1. 少部分公司能够落地到接近微服务最佳实践，可能没有更大的业务体量迫使架构进一步优化。

2. 更多公司似是而非的进行着架构落地，往微服务正走，支撑过业务的快速发展，而足矣。甚至业务的生命周期比软件的生命周期更短。

问题是什么？

在落地微服务之后，在业务体量或数据量疯狂扩张，服务节点数量成倍增加。甚至服务拓扑图成了一张网。

我们都知道微服务治理是最重要的功课，如果所有的微服务都统一语言和技术栈还好。假如整个业务体系再跨语言，那治理微服务诸如重试、限流、认证等等手段难不成都要跨语言、跨不同的客户端去实现一遍？假如某一次请求异常，又如何再跨语言跨技术栈等复杂的系统中快速定位问题？

我们更应该清楚的看到在跨端、跨语言、跨技术栈、又特别大体量业务和网络环境的情况下：

1. 多套框架或中间件如何能够快速迭代、修复和演进？

2. 复杂架构中如何快速定位网络问题？

3. 如果让流量统一可控？如故障注入？支持多泳道？

所有问题都可以通过增加一层来解决

我们以服务发现最简单的治理手段举例，我们已知的这几种服务发现方式：

1. 客户端做发现

现有 RPC 框架的的服务发现多数是基于这种方式实现的，大致流程是，客户端定期从注册中心获取一组服务实例，根据一定规则和发现机制选取其一，然后发起 RPC 调用。

2. 集中式 LB 做转发

所有服务发现统一走一个 LB 或路由器，缺点也很明显，容易制造新的单点，且增加了的维护成本和调用次数。

3. 服务代理形式做转发

部分服务实例以组为单位对外提供服务，这样能减小集中式的路由器或网关的压力，算是基于上述两种折中的方式，但是应该思考的问题是如何维护？

代理如何做？

Service Mesh 一言以蔽之：就是以代理的形式对服务进行治理，特别是网络层面的。那现在的问题就是如何实现代理。

ServiceMesh 演进过程

第一阶段：公共库抽取，解决业务耦合问题，但维护成本高，语言相关，通用型较差

第二阶段：代理模式，功能较为简陋，手工操作，如 Nginx

第三阶段：边车模式，帮助微服务处理大部分网络请求，

第四阶段：ServiceMesh，边车模式网格化，更为通用的网络处理模型

第五阶段：ServiceMesh2，ServiceMesh 升级版，增加控制平面