3.谁需要ServiceMesh
既然Service Mesh这么好，是不是可以无脑上呢？就实际情况来看，不是的。
为什么呢？
Service Mesh在服务治理上，其实并没有更多的“功能性”新特性，比较吸引人的基础特性包括：
- 天然的云原生组件
- 能够独立升级与演进
- 语言无关性
但在一个相对成熟的生产环境中，就目前来看，无论是Dubbo、spring cloud 或者是 自研的微服务框架，都已经相对成熟了，治理能力都比较完善，很少需要去升级或者扩展。
尤其是在服务注册与发现的核心功能不变情况下，一些扩展升级基本不需要所有后端服务都去升级适配。
那么基于“能够独立升级与演进” 的特性就不是那么有说服力了，至少是没有那么大的“业务价值”去驱动的。
那么到底谁才适合引入Service Mesh？
1）云原生基础的新企业（新生产线）
一切从零开始，就基于云原生技术栈的新企业，是非常适合直接引入Service Mesh的 。
云原生天然的服务注册发现、服务治理、云原生可观测，统统围绕Service Mesh展开，业务开发将能更好地专注于业务迭代，而不再需要关注这些业务无关的基础架构的迭代。
当然，一些深入了解云原生技术栈的基础架构维护者是必不可少的。
2）技术栈多样化的成熟企业
那对于一个相对成熟的企业来说，微服务框架、配置中心、全链路追踪系统等，都已经比较成熟，治理能力都比较完善，很少需要去升级或者扩展。
因此，要引入Service Mesh，大部分是基于「技术栈多样化」的需求。
所谓「技术栈多样化」，包括：
- 业务场景特性不同。比如web项目使用Java、后台高性能计算服务使用go/c++、业务请求量波动剧烈的业务使用Faas、前端微服务使用nodejs等。
- 一些特殊的招聘需求。
「技术栈多样化」带来的复杂架构，给传统微服务框架带来了巨大挑战，客户端模式（语言强绑定）的微服务框架已经无法满足这样的复杂需求了。
因此，在云原生架构下，Service Mesh的「语言无关性」的特点，给予了异构应用程序的更多可行性，让用户可以快速的编排出复杂环境、复杂依赖关系的应用程序。
4.小结
本文围绕“什么是Service Mesh”、“为什么需要Service Mesh”两个主题，对ServiceMesh进行了综述性的分享。
最后，根据生产落地中的实际情况，思考了真正适合Service Mesh落地的场景。
期望能对大家有所启发。
