背景
互联网系统的演进，正在经历这样一个路线：单体-SOA-分布式-微服务
在docker-k8s掀起的云原生浪潮下，使得微服务更加的蓬勃发展。那么要管理一个由众多微服务架构起来的系统，将是一个复杂而严肃的话题。
也是首先催生了如spring cloud、dubbo、grpc等众多微服务框架，以及在云原生背景下诞生的service mesh服务网格。
那么对于这两种形式的服务治理，到底应该怎么去选择他们呢？
有的人会认为服务网格必将取代微服务框架；有的则认为两者必然共存。下面我们就来看看两者的区别
微服务框架
微服务框架伴随着微服务的诞生发展至今，涌现出了众多优秀的框架：spring cloud、dubbo、etcd、consul、grpc等等。这些框架都旨在提供业务服务的公共基础设施能力，比如：
服务发现
服务注册
服务路由
负载均衡
配置管理
限流、降级
监控
日志
等其他公共能力
从而让服务进程只需要关注业务逻辑即可。
服务网格
在微服务框架的使用过程中，人们发现如下一些难以避免的问题：
过于绑定特定技术栈 当面对异构系统时，需要花费大量精力来进行代码的改造，不同异构系统可能面临不同的改造。
代码侵入度过高 开发者往往需要花费大量的精力来考虑如何与框架或 SDK 结合，并在业务中更好的深度融合，对于大部分开发者而言都是一个高曲线的学习过程。
多语言支持受限 微服务提倡不同组件可以使用最适合它的语言开发，但是传统微服务框架，如 Spring Cloud 则是 Java 的天下，多语言的支持难度很大。这也就导致在面对异构系统对接时的无奈，或选择退而求其次的方案了。
老旧系统维护难 面对老旧系统，很难做到统一维护、治理、监控等，在过度时期往往需要多个团队分而管之，维护难度加大。
基于此，于是诞生了service mesh的概念：
服务网格（Service Mesh），作为服务间通信的基础设施层。是轻量级高性能网络代理，提供安全的、快速的、可靠地服务间通讯，与实际应用部署一起，但对应用透明。应用作为服务的发起方，只需要用最简单的方式将请求发送给本地的服务网格代理，然后网格代理会进行后续的操作，如服务发现，负载均衡，最后将请求转发给目标服务。
观点
Service Mesh 将流量代理能力下沉，整体调用链路较传统 RPC 框架方式复杂。极端情况下一旦 Service Mesh 数据面 Sidecar 无法正常工作，会直接影响业务流量。这种场景一旦扩散到全局，会升级为系统级风险。原生组件提供了高可用保障，但 缺乏极端情况整体故障兜底能力。
服务框架与 Service Mesh 本身都是为解决业务微服务架构演进问题而生的，并不存在谁更好或者更先进的问题。相反，在微服务领域的未来，服务框架和 Service Mesh 会处在长期共存、互补的状态。
Spring Cloud、Dubbo 以及 gRPC 都是成熟的服务框架，定位和发展方式虽有不同，但依然可以作为业务服务框架的长期选型，即使在 Service Mesh 架构下也同样需要易用的框架、通用的协议将服务流量引入 Sidecar，只不过更多 服务级 的流量治理能力从服务框架下沉到 Sidecar，而服务框架的 代码级 的治理能力依旧可以保留，形成 服务框架细粒度治理 +Service Mesh 流量治理能力的互补。这种共存状态下的微服务架构需要有足够兼容、稳定的方案进行支撑。
