微服务框架与服务网格

背景

互联网系统的演进，正在经历这样一个路线：单体-SOA-分布式-微服务

在docker-k8s掀起的云原生浪潮下，使得微服务更加的蓬勃发展。那么要管理一个由众多微服务架构起来的系统，将是一个复杂而严肃的话题。

也是首先催生了如spring cloud、dubbo、grpc等众多微服务框架，以及在云原生背景下诞生的service mesh服务网格。

那么对于这两种形式的服务治理，到底应该怎么去选择他们呢？
有的人会认为服务网格必将取代微服务框架；有的则认为两者必然共存。下面我们就来看看两者的区别

微服务框架

微服务框架伴随着微服务的诞生发展至今，涌现出了众多优秀的框架：spring cloud、dubbo、etcd、consul、grpc等等。这些框架都旨在提供业务服务的公共基础设施能力，比如：

• 服务发现

• 服务注册

• 服务路由

• 负载均衡

• 配置管理

• 限流、降级

• 监控

• 日志

• 等其他公共能力

从而让服务进程只需要关注业务逻辑即可。

服务网格

在微服务框架的使用过程中，人们发现如下一些难以避免的问题：

• 过于绑定特定技术栈 当面对异构系统时，需要花费大量精力来进行代码的改造，不同异构系统可能面临不同的改造。

• 代码侵入度过高 开发者往往需要花费大量的精力来考虑如何与框架或 SDK 结合，并在业务中更好的深度融合，对于大部分开发者而言都是一个高曲线