简介：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:ks/是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今后倒退的次要方向。

原文链接
本文为阿里云原创内容，未经容许不得转载。