共计 6294 个字符，预计需要花费 16 分钟才能阅读完成。
简介：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 今后倒退的次要方向。
原文链接
本文为阿里云原创内容，未经容许不得转载。
