框架Left，网格Right，微服务之出路

今天已经正式进入2021年。。。[言外之意：本应该早点写出来]

云原生时代的微服务，在过去的2020年：有坚守，亦有破局。服务框架依然在持续进化和奔向云原生，Service Mesh 在持续进步的同时依旧疑点重重。总体而言，微服务架构的演进并非一蹴而就，过于保守或激进都不是解决之道。

在过去的岁月中，以 Spring Cloud、Dubbo 为2大体系代表的服务框架依然在持续进化，持续发热，并加速融向云原生领域；然而，作为微服务体系及云原生中的“网红”：Service Mesh ，依然在未知中砥砺前行。由此，在面对云原生和微服务技术的蓬勃发展：一边是成熟演进的服务框架，一边是代表未来方向的 Service Mesh，企业的架构演进方向该何去何从？

1、Dubbo

作为阿里系的一枚重磅产品（无论你是否认为），2017 年 9 月，阿里巴巴宣布重启 dubbo 的开源维护，重启开源后，解决了积累很久的 pull request 和 Issue ，以及之前一些公司不得不开始自己维护 dubbo 的私有分支也逐步合入了主干。同时，与社区进一步的互动，也会激发 dubbo 团队对产品的灵感。

目前 Dubbo 团队就是阿里巴巴内部负责服务框架的团队，我们在大流量、大规模集群、服务治理领域有着丰富的实践，这些经验已经在有序地回馈给社区。重启开源后发布的 2.7.x 版本带了了很多新的特性，比如 JDK8 支持，完整的异步支持，以及元数据的精简和抽象。在今年，我们启动了另外一个新的历程碑 —— Dubbo3.0，这也会带领 Dubbo 走向下一个阶段，即云原生微服务。

Apache Dubbo 里程碑意义的版本中，做出以下重要调整：

（1）服务模型调整：从基于“接口即服务”模型调整为与 Spring Cloud、Kubernetes 相同的服务模型

（2）协议支持调整：增加了 HTTP/2（gRPC）作为通信协议的能力

（3）云原生生态支持：融入K8S云原生生态

2、Spring Cloud

作为Spring家族的产品，Spring Cloud 之于微服务体系，就像 Spring 之于 Java 开源框架，其地位举足轻重，无论是基于1.x还是2.x。在跨生态领域，Spring Cloud Alibaba 作为 Spring Cloud 与阿里系 OSS 生态融合的项目，在 2020 年也持续发展。Spring Cloud Alibaba 整合了 Sentinel、Nacos、Dubbo 等阿里微服务开源组件，旨在帮助开发者快速引入阿里系开源组件。它致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

依托Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统.因此，基于阿里的强大的技术影响力，其已成为微服务解决方案的重要选择之一。它集成了阿里云的商业化组件，可以说天然支持云原生特性。

3、Service Mesh

经过2020 年的洗礼， Istio依然仍在艰辛的路途中探索。

2020 年，Service Mesh 阵营依旧在不断地分化：

以Google 与 IBM 公司 在商标问题上的分歧，Istio 商标被 Google 捐献给 Open Usage Commons 组织，而非 CNCF。

微软发布了自己的开源 Service Mesh 项目 —— Open Service Mesh，遵循 Istio 以外阵营制定的 SMI（Service Mesh Interface）规范。

微服务 API 网关资深玩家 Kong 推出了自己的 Service Mesh 项目 —— Kuma，有趣的是 Kuma 选择了 Envoy 作为数据面，而非 Kong 网关核心内核 Nginx+OpenResty。

Service Mesh 远古玩家 Nginx 也祭出自己新一代产品 —— NGINX Service Mesh（NSM），主打简化 Service Mesh，并顺势推出商业产品 Aspen Mesh。

总之，云原生理念为微服务架构体系的演进带来了新的契机。无论基于服务框架的演进，还是Service Mesh的落地，对企业自身业务的架构更新以及各大云厂商的未来发展规划都有不小的挑战。在企业级微服务平台能力趋同的趋势下，苦练微服务能力“内功”，积极应对业务低侵入接入、大规模生产支撑带来的挑战，才是微服务架构演进的正确方向。