Nacos 服务网格生态演进

Nacos 为了融入服务网格生态，完成了⼀次从微服务1.0 架构到服务网格架构的演进架构。传统微服务架构下的Nacos
我们先看下传统微服务架构下的Nacos，其流量从Tengine 进入，经过微服务网关，然后再进入微服务体系。
之所以分为两层网关，是因为第⼀层Tegine 是负责流量的接入，核心具备的能力是抗大流量、安全防护和支持https 证书，追求的是通用性、稳定性和高性能。第二层是微服务网关，这层网关侧重的是认证鉴权、服务治理、协议转换、动态路由等微服务相关的能力，比如开源的spring cloud gateway，zuul 等都属于微服务网关。
流量进入微服务体系后，会通过微服务框架实现服务间的调用，比如hsf/dubbo、spring cloud等等，那么Nacos 在这里起到的核心作用是服务发现能力，比如cousumer 会先从Nacos 获取rovider 的服务列表地址，然后再发起调用，还有微服务网关也会通过Nacos 获取上游的服务列表。这些能力主要通过SDK 的方式提供，同时也会在SDK 上增加⼀些负载均衡、容灾保护的策略。

传统微服务架构下的Nacos 存在以下几个问题：
1. Tengine 不支持动态配置，包括开源的Nginx 原生也是不支持的，阿里内部是定期reload配置的方式实现配置变更，这导致配置不能及时变更，影响研发效率；
2. Fat SDK 模式下，服务治理、服务发现等逻辑与SDK 强耦合，如果需要变更逻辑，就得修改SDK，推动业务方升级；
3. 多语言下需要维护不同语言的SDK，成本高，服务治理策略难以统⼀；
服务网格时代的Nacos
随着云原生技术的发展和微服务2.0 架构的提出，很多公司正在尝试通过服务网格技术去解决微服务1.0 架构中的问题。在微服务架构2.0 架构中，流量是通过ingress 网关接入的，进入微服务体系，与1.0 架构不同的是引入了数据面Envoy 和控制面Istio，Envoy 以Sidecar 模式与应用部署在同⼀个Pod 中，会劫持应用的进出流量，然后可以通过控制面Istio 下发的XDS 配置实现流量控制、安全、可观测能力，这⼀架构的优势是将服务治理能力与业务逻辑解耦，把服务框架中SDK 大部分能力剥离出来，下沉到Sidecar，也实现了不同语言的统⼀治理。

服务网格技术优势非常多，但是新架构的引入也会带来新的问题，尤其是对于技术包袱比较重的公
司，将面临的问题，比如：sidecar 性能问题、私有协议支持问题、新旧架构体系如何平滑迁移等等。

平滑迁移必然会面对的两个关于服务发现的问题：
 新旧架构体系如何互相发现，因为迁移过程必然存在两个体系共存的情况，应用需要互相调用；
 注册中心如何支持微服务网格生态，因为istio 目前默认支持的是K8s 的service 服务发现机制；
那么，在Nacos 服务网格生态下是如何解决这些问题的呢？观察如下的架构图，其流量是从云原生网关（云原生网关，它具备的特点是与微服务架构保持兼容，既支持微服务网关，同时又能符合云原生架构，支持K8s 标准的Ingress 网关）进来，然后进入微服务体系，微服务体系中1.0 应用(非mesh 化应用)和已经mesh 化的应用共存。

上图讲解了非mesh 化应用是如何访问已经mesh 化的应用的。从这个架构图可以看到非mesh化的应用还是通过SDK 方式从Nacos 进行服务注册或者服务订阅，已经mesh 化的provider也会注册到Nacos 上，这样非mesh 化的应用也能获取到已经mesh 化的应用服务信息，provider 注册服务⼀般是通过sdk 方式，因为开源envoy 不支持代理注册功能，当然我们阿里内部实现的时候，其实已经把服务注册的能力下沉到sidecar。

另⼀个问题，mesh 化的应用的服务发现是怎么做的。我们可以看架构图的下面这部分，Nacos 已经支持了MCP server 的能力，Istio 是通过MCP 协议从Nacos 获取全量的服务信息列表，然后再转化成XDS 配置下发到envoy，这样即支持了mesh 化应用内的服务发现，也能访问非mesh化的服务，业务在mesh 化过程中服务发现不需要做任何改造，就能无缝迁移。
这里简单介绍下MCP 协议，MCP 协议是Istio 社区提出的组件之间配置同步协议，这个协议在1.8 之后就废弃了，替代方案是MCP over XDS 协议，Nacos 两个协议都兼容。
除了MCP 协议同步方案外，也有其它方案实现注册中心的服务数据同步到ServiceMesh 体系，我们对这些方案做了对比，如下图描述：