简介：Nacos 是阿里巴巴于 2018 年开源的注册中心及配置中心产品，帮助用户的分布式微服务应用进行服务发现和配置管理功能。随着 Nacos2.0 版本的发布，在性能和扩展性上取得较大突破后，社区开始考虑如何提供更加云原生方向的功能和用法。本次分享主要介绍 Nacos 在 2.0 版本在Kubernetes 环境下对服务发现生态的应用探索成果及后续探索方向的规划。
作者：杨翊（席翁）
议题简介：Nacos 是阿里巴巴于 2018 年开源的注册中心及配置中心产品，帮助用户的分布式微服务应用进行服务发现和配置管理功能。随着 Nacos2.0 版本的发布，在性能和扩展性上取得较大突破后，社区开始考虑如何提供更加云原生方向的功能和用法。本次分享主要介绍 Nacos 在 2.0 版本在Kubernetes 环境下对服务发现生态的应用探索成果及后续探索方向的规划。
**分享人：**杨翊（席翁），Alibaba Nacos PMC，Apache ShardingSphere PMC，目前主要涉猎服务发现及数据库中间件的开发。
目录：
• Nacos2.0简介
• Nacos在K8s中服务发现的应用实践
• Nacos的K8s服务网格应用规划
正文：
一、Nacos2.0简介
1. 什么是Nacos
Nacos/nɑ:kəʊs/是Dynamic Naming and Configuration Service的首字母简称，是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos诞生于阿里巴巴的五彩石项目，在阿里十年的双十一中成长迭代，解决了应用扩展性和大规模治理的问题。为了帮助更多的公司和企业都能享受到微服务带来的便利并加速数字化转型，在2018年阿里巴巴将Nacos进行开源。
Nacos在开源的三年多中，用户的使用场景变得越来越复杂，用户规模越来越庞大，基于Nacos1.0的HTTP架构就暴露出来了性能问题和扩展性问题，于是Nacos进行了2.0的架构升级，引入了Grpc这个更高效的通信协议。并对功能架构做了大量的重构和优化。最终使得Nacos2.0在扩展性和性能上提升了10倍。
2. Nacos2.0架构：
Nacos2.0 架构图，从上到下依次为接入层、通信协议、连接层、功能层、一次性协议、持久化层
a. 接入层
首先是接入层，接入层为用户使用和接入Nacos提供了一个入口，包括一些客户端、OpenAPI、Springboot、阿里巴巴应用框架、Dubbo的RPC框架，也有一些用户（主要是运维人员）通过控制台使用Nacos。
b. 通信协议和连接层
接下来一层是通信协议和连接层。
Nacos2.0的通信协议新增了gRPC协议，也沿用了Nacos1.0的http和UDP协议，这是为了方便已经在使用Nacos的用户能够平滑升级到Nacos2.0上，方便用户升级。
Nacos2.0在连接层上统一进行了请求处理的抽象，并且做了流量控制和负载均衡，以防止Nacos服务端在大量应用注册或配置的时候把服务端压垮导致雪崩效应，影响更多人应用。
c. 功能层
功能层包括服务发现Naming和配置管理Config，Nacos2.0做了大量的重构和优化，也是性能能够提升10倍的另一个原因。
d. 一次性协议
Nacos2.0给服务发现提供的是Distro协议和Raft协议，目前已经将Raft协议替换为SOFA的JRaft协议，新增了Notify协议用于配置管理中来通知配置发生变更。
e. 持久化层
因为有很多的配置信息或服务元数据是需要持久化的，所以推荐在生产环境中使用MySQL这一类的RDS去做持久化会相对稳定一些。但是在不是特别重要的场景下，我们也可以使用Derby数据库或本地的文件系统进行存储。
由于用户场景越来越复杂，Nacos开始做一些插件化的架构改造，例如鉴权、配置加解密以及多类型的数据元支持，这些都是反馈比较多的插件。
目前已经由社区志愿者开发完成了一些插件，正在准备合并主干分支中。
另一方面，对于原生能力适配后续也会根据插件化的方式进行扩展，比如MCP协议、xDS协议。
3. Nacos2.0开源生态
在整个微服务生态中，Nacos也在积极和其他微服务开源社区和产品进行结合。
比如Dubbo、RPC框架和SOFA的RPC框架以及应用框架Spring Cloud Alibaba、还有高可用框架Sentinel（在运行生态中做一些隔断等操作）。
各类网关也用到了Nacos，比如阿里基于Nginx研发的Tengine网关、Spring Cloud Gateway、Zuul都是社区中比较常用的。
Nacos也在和原生社区进行结合，比如MCP协议就是进行数据交换、向Envoy网关推送配置规则、和应用框架（比如Dapr多语言框架）进行结合。
二、Nacos在K8s中服务发现的应用实践
1. 早期的应用实践
早期Nacos及整个微服务应用体系并没有完全接入到K8s的能力体系中（比如服务网格体系），K8s最初是作为一个容器资源调度的平台来使用的，在这个框架下，所有的应用节点以及Nacos自身节点会基于K8s进行部署，用K8s的一些自我恢复以及易于扩容缩容的能力作为资源的调度。
在K8s框架下面，流量依次经过以下两层：
a. 流量首先会从Tengine网关进入，Tengine网关需要承载一些大流量的接入，其核心能力是安全防护和http证书认证，追求的是通用性、稳定性和高性能；
b. 流量进入Tengine网关后，会进入微服务网关。微服务网关侧重的是鉴权的认证和服务的治理，比如流量的动态路由、协议转换（http转Dubbo协议）这样的相关能力；像是Spring Cloud、gateway、Zuul都属于微服务网管类型。流量在经过微服务网关的一个转发和路由后就会进入到整个微服务体系中，在微服务体系中的微服务框架Dubbo或者阿里内部的HSF，以及云上应用框架Spring Cloud Gateway，它们会通过SDK服务注册到Nacos中，同时，可能也会通过Nacos SDK订阅它所依赖的服务，获取到它的服务列表，最后进行流量的调用。
在以上过程中，Nacos的核心作用是服务发现、负载均衡和服务治理，这也是绝大多数公司或开发者熟悉使用的服务框架，这个框架面临的问题如下：
a. Tengine不支持热更新
Tengine网关识别基于Nginx开发的，不支持动态配置，在配置变更后，需要人工进行reload(重新加载)操作才能使变更后的配置生效，这就导致了紧急配置不能及时生效，影响研发效率和线上处理故障的效率；
b. 两层网关成本高
流量经过两层网关（Tengine网关和微服务网关），流量的RT会相对变长，而且架构中如果引入一个插件，系统会变得更加复杂，对应的运维成本和服务器成本会增加；
c. Fat SDK模式，服务治理、服务发现等逻辑与SDK强耦合，升级困难
在Nacos架构中，服务发现能力主要是基于应用所依赖的Nacos SDK所实现的，这会导致SDK和应用的耦合度非常高，SDK一旦出现问题或需要添加一个功能时，就需要应用侧对SDK进行升级，这个升级过程时间长而且难度大；
d. 多语言维护成本高，服务治理策略不统一
不同公司的业务和系统会使用不同的编程语言，维护不同多语言的SDK成本会比较高。不同语言的SDK在实现上会有一定的差别，而且版本演进迟缓，这导致有不能统一功能或治理策略，影响到最终的流量治理情况；
e. 纯粹只拿K8s作为调度，应用程度低
这个框架是纯粹的将K8s作为一个资源调度的工具，并没有使用到K8s提供的一些高级能力比如服务网格。
2. 云原生改造-使用服务网格
为了解决以上5个问题，就需要对应用和框架进行改造。
在改造的时候，我们先看到了K8s服务网格中抽象的服务面和控制面的概念。
控制面就是服务治理中的一个思想，它把所有的流量控制能力下沉到Sidecar中；数据面负责流量转发。
当控制面出现问题的时候，数据面仍然能够通过原来的配合进行流量转发，不会受到影响，这其实和微服务治理的思想是一致的，所以就决定以服务网格为方向进行改造。
改造可分为以下几个方面：
a. 首先要替换微服务网关，因为K8s的网关定义了一套标准的接口，即Ingress网关，Ingress本身就是一个标准的接口或者说是一套能力的定义。具体的Ingress网关实现有很多种方式，比如Envoy网关就是其中之一，并且Envoy网关目前基本上已经成为当前社区的首选，所以我们也将采用Ingress网关、Envoy网关来替换原来的微服务网关。
b. 在应用节点方面，在引入了数据面Envoy和控制面Istio后，Envoy会以Sidecar模式和应用部署在同一个Pod之中，来劫持应用的进驻流量。通过Istio下发的xDS配置来实现流量的控制、安全防护和可观测能力的构建。
这样的架构的优势，是使服务治理能力和业务逻辑能力完全分开了，也能解决一部分多语言的问题。但是在应用过程中，这个架构会遇到很多问题，特别是对于一些技术占比比较大的企业，这个问题会更加严峻：
a. 只有全新的应用可以使用，无法和旧体系互通，无法做到平滑迭代；
b. 应用元数据需要转移到Pod的label或annotation中，维护成本和改造成本高；
c. 注册中心如何支持服务网格生态？
3. 解决方案
a. 将网关升级优化
将两个网关Tengine网关和Envoy网关进行融合，融合后的网关命名为云原生网关。云原生网关同时具备了微服务网关的能力，能够直接对接K8s的所有服务体系，而且具备了一定Tengine网关的能力、https证书认证、安全防护的扩展能力。这个云原生网关的优势就是将两个网关合二为一，这样减少了服务器的部署成本。
这个云原生网关其实已经在阿里云上提供给广大用户生产使用了（可以搜索“微服务引擎MSE”）。
流量经过网关，只需一次转发，这样可以降低整个RT；另一方面，像应用侧这方面的能力可以通过轻量级SDK将逻辑下沉到Sidecar中，然后这种轻量级SDK只是去获取信息，然后直接和Sidecar进行交互，这样大部分逻辑下沉到Sidecar之后，就会降低多语言的维护成本，不需要很大程度的改造业务代码，可能只需要更换一下SDK版本就可以了。
Envoy网关接入服务网格体系后，应用的流量也会被Envoy网关的Sidecar进行转发。在新的接入体系中，未接入服务网格体系的应用可以通过原来的Fat SDK将服务注册到Nacos之上；对于接入了服务网格的应用节点或新应用，可以通过Sidecar将信息注册到Nacos中，Nacos就有了一个全量的服务信息，对于未接入服务网格体系的应用节点来说，可以通过Fat SDK直接进入到所有的服务列表，包括接入和未接入的所有应用，就可以在整个K8s体系中进行一个正确的流量调用。
对于一些接入了服务网格体系的应用节点，可以通过Istio、xDS协议获取到Nacos所有新旧的服务节点，也可以在Envoy网关中进行正确的流量路由。
b. MCP协议和MCP-Over-XDS协议
在Istio和Nacos之间使用MCP协议连接。MCP协议是Istio社区提出的用于服务组件之间服务同步的协议，在1.8版本之后，Istio社区用MCP-Over-XDS协议替换了MCP协议。
Nacos支持MCP协议和MCP Over XDS协议，最终，Nacos可以支持新旧服务系统，也可以通过原来的Fat SDK获取到所有的应用节点，这样就可以实现整个新旧微服务体系中互联互通、平滑迭代，并且能够无缝支持服务网格生态。
4. 阿里落地实践
在阿里的落地实践架构中，中间部分是集团的服务架构，如果新业务或部分应用的灰度节点会接入MSE体系，基于Envoy/Sidecar方式注册到Nacos中，很多正在承载线上业务流量的节点仍然使用旧的SDK的体系进行注册和发现。在Nacos管理的所有服务列表中，通过Istio下发到Ingress的Envoy网关，实现预期的调用。随着灰度程度扩大，会逐渐将原来的Fat SDK模式逐渐全部转化为Envoy/Sidecar模式。
在右边钉钉的架构模型中，因为钉钉本身是一个新的业务，而且它和集团之间依赖关系比较弱，所以它可以直接使用这种云原生网关加服务网格的架构进行落地，流量经过MSE云原生网关，云原生网关中有从Nacos网关中获取到的所有服务的信息，就可以通过Dubbo3协议转发到各个微服务体系框架中，进行和预期一样的调用。
上图左边是蚂蚁的用户流量，它先是经过Tengine网关，然后是经过Mson On Envoy网关，再路由到它们自身的一个SOFA Micro Service体系中进行调用。在跨业务域的调用过程中，云原生网关和Envoy网关也能够很好的进行互相调用、互相发现，这样的话也可以解决跨业务域之间的网络安全性能问题，因为只有网关可以进行互相调用和互相发现，微服务体系之间是不能互相调用和发现的。
三、Nacos的K8s服务网格应用规划
1. 趋势分析
• 根据CNCF的调查，27%的公司正在生产环境中使用微服务网格，也有23%的公司正在评估服务网格技术。服务网格新技术正在被广大社区和开发者所认可；
• 服务网格技术经过这几年的发展逐渐趋于稳定，社区也越来越标准化。比如微软就提出了一套控制面的API标准。但是服务网格技术目前没有在社区内达成共识，反而由XDS演化来的UDPA在CNCF的运作下最有可能成为数据面的标准；
• 统一控制面将是Nacos后续参与服务网格的主要方向,也会成为Nacos未来发展和更新的主要方向。
2. Nacos统一控制面
在K8s服务发现体系中其实类似于动态DNS的能力，实现由域名（服务名）到IP的转换过程，它其实是一个应用级别或Pod级别的信息，根据这个Pod级别的信息来生成对应控制面规则，它的粒度是比较粗的。
如果可以通过将应用中比较复杂的元数据下沉到Pod里面的lable或annotation中，单独维护起来，服务网格原生控制面生成的也是能够满足一定需求的。但是这样对于广大开发者来说，特别是对已经习惯现有体系、同时要维护应用代码和声明式API的开发者来说，是比较难以接受的。
Nacos可以通过一定手段获取到相关信息，可以获取到暴露了哪些接口、输入/输出参数对应的是什么等这类信息，利用这些更细节、更细腻的信息来进行控制面的生成，能够更精细的控制流量的转发（灰度能力），简单来说就是微服务治理能力，这样可以作为原生服务网格能力的增强。
所以Nacos在未来会做一个控制面的功能，比如说直接实现xDS协议、暴露出一系列控制API等），提供给使用Nacos的用户做控制面的管理；同时实现xDS协议对控制面的直接对接，也可以解决一部分由于MCP协议同步大量服务信息所带来的一些问题。
3. Nacos的服务治理生态
其实在整个的实践和落地过程中，将已经运行在微服务产品或微服务体系中的应用迁移到服务网格体系中的代价非常大的，而且这个过程中，对于不同的业务线、不同部门在对接过程中是有很多重复工作的，将微服务体系迁移到微服务网格中同样也会面临这样的问题和阻力。
所以我们希望将Nacos和其它微服务产品共同解决这个问题，可以共同制定一个微服务治理的标准协议，来实现低成本或无成本的无缝对接；也可以将服务治理的标准协议转化成服务网格协议（比如xDS协议），可以快速实现和原生服务网格控制面的对接，让使用微服务产品的用户享受到低成本迁移到服务网格生态的便利，这也是Nacos今后发展的主要方向。
本文为阿里云原创内容，未经允许不得转载。
