介绍：Nacos是阿里巴巴于2018年发布的开源注册中心和配置中心产品，帮助用户的分布式微服务应用进行服务发现和配置管理功能。随着Nacos2.0的发布，社区开始考虑在性能和扩展性上有了重大突破后，如何提供更多的云原生功能和使用方式。本次分享主要介绍了Nacos在Kubernetes环境下服务发现生态2.0版本的应用和探索成果，以及后续探索方向的规划。作者：杨毅（席翁）主题介绍：Nacos是阿里巴巴于2018年开源的一款注册中心和配置中心产品，帮助用户的分布式微服务应用进行服务发现和配置管理功能。随着Nacos2.0的发布，社区开始考虑在性能和扩展性上有了重大突破后，如何提供更多的云原生功能和使用方式。本次分享主要介绍了Nacos在Kubernetes环境下服务发现生态2.0版本的应用和探索成果，以及后续探索方向的规划。分享者：杨毅（席翁），阿里巴巴NacosPMC，ApacheShardingSpherePMC，目前主要从事服务发现和数据库中间件开发。内容：?Nacos2.0介绍?Nacos服务发现在K8s中的应用实践?NacosK8s服务网格应用规划正文：1.Nacos2.0介绍1.什么是NacosNacos/nɑ:k??s/是DynamicNamingandConfigurationService的首字母缩写，是一个动态服务发现、配置管理和服务管理平台，更容易构建云原生应用。Nacos诞生于阿里巴巴的彩石项目。它在阿里巴巴十年双十一期间不断成长和迭代，解决了应用扩展和大规模治理的问题。为了帮助更多的公司和企业享受微服务带来的便利，加速数字化转型，阿里巴巴在2018年开源了Nacos，Nacos已经开源三年多了。用户的使用场景越来越复杂，用户规模越来越大。基于Nacos1.0的HTTP架构暴露了性能和扩展性问题，因此Nacos进行了2.0架构的升级，引入了更高效的通信协议Grpc。并对功能架构做了很多重构和优化。最终Nacos2.0在扩展性和性能上提升了10倍。2、Nacos2.0架构：Nacos2.0架构图，从上到下分别是接入层、通信协议、连接层、功能层、一次性协议、持久层接入层首先是接入层，接入层为用户使用和接入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框架和SOFARPC框架、应用框架SpringCloudAlibaba、高可用框架Sentinel（在运行生态中做一些隔离等操作）。Nacos也用在各种网关中。比如阿里基于Nginx开发的Tengine网关，SpringCloudGateway，Zuul都是社区常用的。Nacos也在与原生社区进行整合。比如MCP协议是为了数据交换，将配置规则推送到Envoy网关，结合应用框架（比如Dapr多语言框架）。二、Nacos服务发现在K8s中的应用实践1、早期应用实践早期，Nacos和整个微服务应用体系并没有完全接入K8s的能力体系（比如服务网格体系），K8s本来就是作为容器资源调度平台使用。在这个框架下，所有的应用节点和Nacos自身的节点都会基于K8s进行部署，利用K8s的一些自恢复和易扩缩容的能力作为资源调度。在K8s框架下，流量依次经过以下两层：流量会先从Tengine网关进入，需要承载一些大流量的接入。其核心能力是安全保护和http证书认证，追求的是通用性。稳定性和高性能；b.流量进入Tengine网关后，会进入微服务网关。微服务网关侧重于鉴权和服务治理，比如流量的动态路由以及协议转换（http转Dubbo协议）等相关能力；SpringCloud、gateway、Zuul都是微服务网管类型。流量经过微服务网关转发路由后，进入整个微服务系统。在微服务体系中，微服务框架Dubbo或者阿里巴巴内部的HSF，以及云应用框架SpringCloudGateway，它们都会通过SDK服务注册到Nacos中。同时，它也可能通过NacosSDK订阅它所依赖的服务，获取它的服务列表，最终调用流量。在上述过程中，Nacos的核心作用是服务发现、负载均衡和服务治理。这也是大多数公司或开发者所熟悉的服务框架。该框架面临的问题如下：a．Tengine不支持Tengine网关热更新标识基于Nginx开发，不支持动态配置。更改配置后，需要手动重新加载（reload）操作才能使更改后的配置生效。导致应急配置没有及时生效，影响研发效率和在线处理故障的效率；b.两层网关成本高。当流量经过二层网关（Tengine网关和微服务网关）时，流量的RT会相对较长，如果在架构中引入插件，系统会变得更加复杂。相应的运维成本和服务器成本会增加；C。FatSDK模式，服务治理、服务发现等逻辑与SDK强耦合，难以升级。在Nacos架构中，服务发现能力主要基于应用所依赖的NacosSDK。这会导致SDK和应用程序之间的耦合度非常高。一旦SDK出现问题或者需要增加功能，就需要在应用端升级SDK。这个升级过程耗时长，难度大；d.治理策略不统一。不同公司的业务和系统会使用不同的编程语言，维护不同的多语言SDK的成本会比较高。不同语言的SDK实现会存在一些差异，版本演进缓慢，导致无法统一功能或治理策略，影响最终的流量管理情况；它纯粹使用K8s作为资源调度的工具，并没有使用服务网格等K8s提供的一些高级能力。2.云原生改造——使用服务网格为解决以上五个问题，需要对应用和框架进行改造。在改造过程中，我们首先看到了K8s服务网格中抽象服务平面和控制平面的概念。控制面是服务治理中的一种思想，将所有的流量控制能力下沉到Sidecar；数据平面负责流量转发。当控制面出现问题时，数据面仍然可以通过原有的协作转发流量，不受影响。这其实和微服务治理的思想是一致的，所以我们决定往服务网格的方向改造。改造可分为以下几个方面：a．首先要更换微服务网关，因为K8s网关定义了一套标准接口，即Ingress网关。Ingress本身就是一个标准的接口或一组能力定义。有很多方法可以实现特定的Ingress网关。比如Envoy网关就是其中之一，Envoy网关基本上已经成为了现在社区的首选，所以我们也会用Ingress网关和Envoy网关来代替原来的微服务网关。b.在应用节点方面，数据面引入Envoy，控制面引入Istio后，Envoy会以Sidecar的方式与应用部署在同一个Pod中，劫持应用的入站流量。通过Istio下发的xDS配置，可以构建流量控制、安全防护和可观察性。这样的架构的好处是将服务治理能力和业务逻辑能力完全分离，也可以解决一些多语言的问题。但是在应用的过程中，这种架构会遇到很多问题，尤其是对于一些技术占比比较大的企业，这个问题会更加严重：只能使用全新的应用，不能与旧系统互通。平滑迭代；b.应用元数据需要转移到Pod的标签或注解中，维护成本和改造成本高；C。注册中心如何支撑服务网格生态？3.解决方案升级优化网关。将Tengine网关和Envoy网关这两个网关进行整合，并将整合后的网关命名为云原生网关。云原生网关也具备微服务网关的能力，可以直接对接K8s的所有服务系统，具备一定的Tengine网关能力、https证书认证、安全防护扩展能力。这种云原生网关的好处是将两个网关合二为一，降低了服务器的部署成本。这个云原生网关其实已经在阿里云上提供给用户生产使用了（可以搜索“微服务引擎MSE”）。流量经过网关，只需要转发一次，可以降低整体RT；另一方面，应用端的能力可以通过轻量级的SDK把逻辑下沉到sidecar，然后这个轻量级的SDK只是用来获取Information，然后直接和Sidecar交互，这样大部分逻辑就被淹没了在Sidecar中，这样会降低多语言的维护成本，并且不需要很大程度的修改业务代码，可能只需要更改SDK版本即可。Envoy网关接入服务网格系统后，应用流量也会通过Envoy网关的sidecar进行转发。在新的接入系统中，没有接入服务网格系统的应用可以通过原有的FatSDK在Nacos上注册服务；对于接入服务网格系统的应用节点或新应用，可以通过Sidecar注册信息到Nacos中，Nacos拥有全量的服务信息。对于没有接入服务网格系统的应用节点，可以直接通过FatSDK进入所有服务列表，包括所有接入和未接入的节点。应用程序，可以在整个K8s系统中进行正确的流量调用。对于接入服务网格系统的部分应用节点，可以通过Istio和xDS协议获取Nacos的所有新旧服务节点，并在Envoy网关中进行正确的流量路由。b.MCP协议和MCP-Over-XDS协议使用MCP协议连接Istio和Nacos。MCP协议是Istio社区提出的用于服务组件间服务同步的协议。在1.8版本之后，Istio社区将MCP协议替换为MCP-Over-XDS协议。Nacos支持MCP协议和MCPOverXDS协议。最终Nacos可以支持新老服务系统，也可以通过原有的FatSDK获取所有应用节点，从而实现整个新旧微服务系统的互联互通和平滑迭代，并且可以无缝衔接支持服务网格生态。4、阿里的落地实践在阿里的落地实践架构中，中间部分是集团的服务架构。如果新业务的灰度节点或者一些应用会接入MSE系统，会基于Envoy/Sidecar注册到Nacos中，很多承载在线业务流量的节点还是使用旧的SDK系统进行注册和发现。在Nacos管理的所有服务列表中，通过Istio发送到Ingress的Envoy网关实现了预期的调用。随着灰度的扩大，原有的FatSDK模式将逐渐转变为Envoy/Sidecar模式。右边钉钉的架构模型中，由于钉钉本身是一个新业务，与集团之间的依赖关系比较弱，所以可以直接使用这种云原生网关加服务网格的架构进行落地。通过MSE云原生网关，云原生网关拥有从Nacos网关获取的所有服务信息，可以通过Dubbo3协议转发到各个微服务系统框架，如期进行相同的调用。上图左侧是Ant的用户流量，先经过Tengine网关，再经过MsonOnEnvoy网关，再路由到自己的SOFA微服务系统进行调用。在跨业务域调用的过程中，云原生网关和Envoy网关之间也可以很好的相互调用和发现。这样也可以解决跨业务域之间的网络安全性能问题，因为只有网关可以相互调用和相互发现，微服务系统不能相互调用和发现。三、NacosK8s服务网格应用方案1、趋势分析?根据CNCF调查，27%的企业在生产环境中使用微服务网格，23%的企业正在评估服务网格技术。新的服务网格技术正在得到社区和开发者的认可；?服务网格技术经过几年的发展逐渐趋于稳定，社区也越来越规范。例如，微软针对控制平面提出了一套API标准。但是，服务网格技术在社会上还没有达成共识。相反，由XDS演化而来的UDPA，在CNCF的运作下，最有可能成为数据平面的标准；?统一控制面将是Nacos未来参与服务网格的主要方向。也将成为Nacos未来发展更新的主要方向。2.K8s服务发现系统中的Nacos统一控制面其实类似于动态DNS的能力，实现了域名（服务名）到IP的转换过程。它实际上是应用程序级别或Pod级别的信息。根据Pod-levelInformation生成相应的controlplane规则，其粒度比较粗。如果能将应用中比较复杂的元数据下沉到Pod中的标签或注解中，单独维护，服务网格生成的原生控制平面也能满足一定的要求。但这对于大多数开发人员来说是无法接受的，尤其是对于习惯于现有系统并同时维护应用程序代码和声明式API的开发人员而言。Nacos可以通过一定的方式获取相关信息，比如暴露了哪些接口，输入/输出参数对应的是什么等等，并利用这些更详细、更细腻的信息生成控制面，可以更精细化的转发控制流量（灰度能力），简单来说就是微服务治理能力，可以作为原生服务网格能力的增强。所以Nacos未来会做一个控制平面的功能，比如直接实现xDS协议，暴露一系列控制API等）提供给使用Nacos的用户来管理控制平面；同时，实现xDS协议与控制面的直连，也可以解决MCP协议同步大量服务信息带来的一些问题。3.在Nacos服务治理生态的整个实践和实施过程中，将已经运行在微服务产品或微服务系统中的应用迁移到服务网格系统的成本是非常高的，而且在这个过程中，对于不同的业务线和不同的部门在对接过程中有很多重复性工作。将微服务系统迁移到微服务网格，也会面临这样的问题和阻力。所以，我们希望Nacos和其他微服务产品能够共同解决这个问题。我们可以共同制定微服务治理的标准协议，实现低成本或无成本的无缝对接；我们还可以将服务治理的标准协议转化为服务网络。网格协议（如xDS协议）可以快速实现与原生服务网格控制面的对接，让使用微服务产品的用户可以低成本享受到服务网格生态迁移的便利。这也是Nacos未来发展的主要方向。原文链接本文为阿里云原创内容，未经许可不得转载。
