蔚县网站建设公司,福田瑞沃q5,建网站租服务器多少钱,做网站大简介#xff1a;Nacos 是阿里巴巴于 2018 年开源的注册中心及配置中心产品#xff0c;帮助用户的分布式微服务应用进行服务发现和配置管理功能。随着 Nacos2.0 版本的发布#xff0c;在性能和扩展性上取得较大突破后#xff0c;社区开始考虑如何提供更加云原生方向的功能和…简介Nacos 是阿里巴巴于 2018 年开源的注册中心及配置中心产品帮助用户的分布式微服务应用进行服务发现和配置管理功能。随着 Nacos2.0 版本的发布在性能和扩展性上取得较大突破后社区开始考虑如何提供更加云原生方向的功能和用法。本次分享主要介绍 Nacos 在 2.0 版本在Kubernetes 环境下对服务发现生态的应用探索成果及后续探索方向的规划。
作者杨翊席翁 议题简介Nacos 是阿里巴巴于 2018 年开源的注册中心及配置中心产品帮助用户的分布式微服务应用进行服务发现和配置管理功能。随着 Nacos2.0 版本的发布在性能和扩展性上取得较大突破后社区开始考虑如何提供更加云原生方向的功能和用法。本次分享主要介绍 Nacos 在 2.0 版本在Kubernetes 环境下对服务发现生态的应用探索成果及后续探索方向的规划。 分享人杨翊席翁Alibaba Nacos PMCApache 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和配置管理ConfigNacos2.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今后发展的主要方向。 原文链接
本文为阿里云原创内容未经允许不得转载。
