作者 | 怀成

Nacos 简介

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称。目标是构建一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 在阿里巴巴起源于 2008 年五彩石项目（该项目完成微服务拆分和业务中台建设），成长于十年的阿里双十一峰值考验，这一阶段主要帮助业务解决微服务的扩展性和高可用问题，解决了百万实例扩展性问题（10w->100w实例）。2018 年我们深刻感受到开源软件行业的影响，因此决定将 Nacos 开源，输出阿里十年关于服务发现和配管管理的沉淀，推动微服务行业发展，加速企业数字化转型。

随着近几年云原生技术的发展，服务网格技术的提出，越来越多的公司尝试将微服务架构迁移到服务网格架构，这对 Nacos 提出了一个新的诉求，那就是如何更好的支持服务网格生态。

Nacos 无缝支持服务网格

我们先看下微服务 1.0 下的架构，流量从 Tengine 进来，经过微服务网关，然后再进入微服务体系。

这里解释下为什么分了两层网关，第一层 Tegine 是负责流量的接入，核心具备的能力是抗大流量、安全防护和支持 https 证书，追求的是通用性、稳定性和高性能。第二层是微服务网关，这层网关侧重的是认证鉴权、服务治理、协议转换、动态路由等微服务相关的能力，比如开源的 spring cloud gateway，zuul 等都属于微服务网关。

流量进入微服务体系后，会通过微服务框架实现服务间的调用，比如 hsf/dubbo、spring cloud 等等，那么 Nacos 在这里起到的核心作用是服务发现能力，比如 cousumer 会先从 Nacos 获取 provider 的服务列表地址，然后再发起调用，还有微服务网关也会通过 Nacos 获取上游的服务列表。这些能力主要通过 SDK 的方式提供，同时也会在 SDK 上增加一些负载均衡、容载保护的策略。

微服务 1.0 架构主要存在以下几个问题：

1. Tengine 不支持动态配置，包括开源的 Nginx 原生也是不支持的，阿里内部是定期 reload 配置的方式实现配置变更，这导致配置不能及时变更，影响研发效率；
2. Fat SDK 模式下，服务治理、服务发现等逻辑与 SDK 强耦合，如果需要变更逻辑，就得修改 SDK，推动业务方升级；
3. 多语言下需要维护不同语言的 SDK，成本高，服务治理策略难以统一。

随着云原生技术的发展和微服务 2.0 架构的提出，很多公司正在尝试通过服务网格技术去解决微服务 1.0 架构中的问题。在微服务架构 2.0 架构中，流量是通过 ingress 网关接入的，进入微服务体系，与 1.0 架构不同的是引入了数据面 Envoy 和控制面 Istio。

Envoy 以 Sidecar 模式与应用部署在同一个 Pod 中，会劫持应用的进出流量，然后可以通过控制面 Istio 下发的 XDS 配置实现流量控制、安全、可观测能力，这一架构的优势是将服务治理能力与业务逻辑解耦，把服务框架中 SDK 大部分能力剥离出来，下沉到 Sidecar，也实现了不同语言的统一治理。

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

本文主要关注新旧架构体系平滑迁移这个问题，平滑迁移必然会面对的两个关于服务发现的问题：

1. 新旧架构体系如何互相发现，因为迁移过程必然存在两个体系共存的情况，应用需要互相调用；
2. 注册中心如何支持微服务网格生态，因为 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 体系，我们对这些方案做了对比，如下图描述：

Nacos 服务网格生态阿里落地实践

最后给大家介绍下阿里巴巴 Nacos 服务网格生态的实践，下面这张图总体概括了阿里落地的两个场景。

场景一：

钉钉云上和集团互通的场景，本质其实就是混合云场景下的应用互通，我们是用了网关去打通这两个环境，钉钉 vpc（阿里云部署）这边用的是 MSE 云原生网关，集团用的是 Envoy 网关，他们之间使用 Dubbo3.0 的 triple 协议实现网络通讯，网关的控制面都使用的是 Istio，Istio 会通过 MCP 协议从 Nacos 同步服务列表数据。

使用这个架构解决了两个问题：

1、私有云和公有云网络通讯安全问题，因为网关之间使用 mtls 加密通讯；

2、平滑支持微服务架构，因为应用通过 triple 协议调用网关，不需要业务做代码改动，服务发现则是通过 Nacos mcp 去同步数据；

这套架构同时也用于蚂蚁集团互通的场景，就是这张图的左边，蚂蚁的网关使用的是 Mosn on Envoy 的架构。

场景二：

集团的微服务 mesh 化场景，对应这张图的中下部分，内部落地与社区的差异点是，Envoy 直接对接了 Nacos 注册中心，使用这个方案主要还是考虑到性能问题，我们有些应用会有几万的实例 ip，如果通过 EDS 推送，因为数据量过大，会导致 Istio OOM 或者 Envoy 数据面 cpu 飙高等问题。

本文是 Nacos 服务网格生态直播的文本整理，完整直播内容可以参看：https://yqh.aliyun.com/live/detail/26211

Nacos 源代码仓库：https://github.com/alibaba/nacos