什么是service mesh
服务网格是一个基础设施层，功能在于处理服务间通信，职责是负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明
可以将它比作是微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断、监控等功能。对于编写应用程序来说一般无须关心TCP/IP这一层（比如通过HTTP协议的RESTful应用），同样使用service mesh也就无须关心服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如spring cloud，现在只要交给service mesh就可以了
另一方面，service mesh更强调由这些代理连接而形成的网络，而不仅仅是一个网络代理(sidecar)。
为什么要有service mesh
因为，基于框架或者类库实现的网络代理存在诸多弊端
内容多，门槛高
例如spring cloud：
- spring-cloud-common
- spring-cloud-netflix
- spring-cloud-sleuth
- spring-cloud-gateway
- spring-cloud-bus
- spring-cloud-consul
- spring-cloud-config
- spring-cloud-security
- spring-cloud-zookeeper
- spring-cloud-aws
- spring-cloud-cloudfoundry
- …
团队成员学习并吃透这些东西，需要大量时间与精力。然而这些技术是实现微服务化的手段，真正的目标是实现业务。时间人力可能远远不足。
微服务化我们有更艰巨的挑战：微服务拆分、边界设定、设计良好的api等
服务治理功能不够完善
服务治理常见的功能如下：
Spring Cloud直接提供的功能是远远不够的。很多功能都需要你在Spring Cloud的基础上自己解决
无法跨语言
微服务一个重要的特性：就是不同的微服务可以采用最适合的编程语言来编写
然而我们的框架类库，需要提供多少语言的SDK呢？
如何升级
框架不可能一开始就完美无缺，所有功能都齐备，没有任何BUG，分发出去之后就再也不需要改动，这种理想状态不存在的。必然是1.0、2.0、3.0慢慢升级，功能逐渐增加，BUG逐渐被修复
然而使用者并不能都马上跟进升级，一旦客户端和服务器端版本不一致，就要非常小心维护兼容性
版本兼容性有多复杂？服务端数以百计起，客户端数以千计起，每个的版本都有可能不同。这是一个笛卡尔乘积。但是别忘了，还有一个前面说的编程语言的问题，你还得再乘个N！这种情况下，兼容性测试需要写多少个Case，这几乎是不可能的
service mesh演进
ps:sidecar就是框架或者类库的方式
service mesh演进是一个技术栈下移的过程。形成一个独立进程，代理服务所有流量，可单独升级，对应用程序透明
思考
这部分基于本人对service mesh初步认知，属于个人不成熟的想法，欢迎各位大牛斧正！
service mesh有什么缺点？
个人觉得，相比较框架或者类库的形式，service mesh还是有部分不好实现的功能：
熔断后的回落：
例如，service mesh熔断后的回落操作就比较局限。对于service mesh来说，服务故障的真实原因是隐蔽的，服务调用端可能只能捕获调用异常和约定来处理。而基于框架或者类库，我们有更多可选择的优雅降级方式：返回缓存值、返回缺省值甚至去调用其他不同的服务分布式追踪系统(APM)不能精细控制到本地方法级
个人想法
语言兼容与代码级精细控制，本身就是一个矛盾点。相比service mesh提供的便利，其缺点可以忽略不计
