背景
互联网系统的演进，正在经历这样一个路线：单体-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 流量治理能力的互补。这种共存状态下的微服务架构需要有足够兼容、稳定的方案进行支撑。
