Nacos 在云原生架构下的演进
背景
Nacos 提供的最核心能力是动态服务发现与动态配置管理能力,在云原生环境下,借助云产品,如 EDAS(企业级分布式应用服务)平台中,我们可以很轻松地使用 K8s 来托管 Nacos 体系的微服务应用,同时又享有全链路流量治理、可观测、极致弹性等能力。
云原生下的应用由两个主要部分组成:不可变基础设施(代码、运行时)与配置。在这里配置是一个非常广泛的概念,它包含了运维配置(如副本数、发布策略、流量策略等),也包含了运行时配置(如环境变量、文件系统、运行时配置等)。通过 Kubernetes 提供的标准接口,我们可以很方便地修改上述配置。然而令人苦恼的是,Nacos 提供的配置管理能力,在当下却不能融入 Kubernetes 提供的标准接口中。
随之而来的头号问题:应用交付需要分两步走,1. 发布 Nacos 配置,2. 发布应用。尤其是 Nacos 配置发布过程,依赖于用户编程对接 OpenAPI 或者人工登录控制台进行白屏操作。这里引入一个问题值得我们思考,运维接口不统一、不标准,使得应用生命周期管理有所割裂,进而带来运维效率降低、技术门槛拔高的成本问题。
Nacos 与 Kubernetes 的桥梁
归其根本,我们需要看清问题的本质。Nacos 项目所解决根本问题是微服务技术架构下,实现应用间的动态服务发现能力与应用配置管理能力。Kubernetes 平台所解决的问题是大规模应用集合的管理难题。因此,想要解决前面所述的问题,我们引入 NacosController 项目,它作为链接 Nacos 和 Kubernetes 的桥梁,通过 Kubernetes 运维接口管理 Nacos 能力。
项目地址: https://github.com/nacos-group/nacos-controller
当前 NacosController 项目已经实现了 DynamicConfiguration 概念(后文简称 DC)。通过这个概念,我们可以定义 Nacos 配置与 K8s 配置的同步策略,进而使用 Kubernetes 标准运维接口管理 Nacos 配置。当然,打开一下“脑洞”,我们也可以通过这个概念使用 Nacos 管理应用的常见运行时配置(如环境变量、文件系统)。
应用配置在桥梁中通行载体
通过 NacosController 项目,我们建立起了 NacosServer 与 Kubernetes 的桥梁,我们再引入 DynamicConfiguration 的概念用来解决配置管理的问题。DC 概念承载了从哪里找到配置以及内容,并将其同步到哪里去的信息,有了这样一份简洁明了的 DC 资源,我们可以很轻松地定义一些同步行为,如将 Kubernetes 中的配置同步到 NacosServer 中,又或是将 NacosServer 中的配置同步到 Kubernete 中。基于 DC 概念,我们凝练出两种主要使用场景。
将配置同步到 NacosServer 中
我们先看一份 DC 的定义,以下这份 DC 定义了将配置从 Kubernetes 集群中同步到 Nacos Server 去。这份 DC 内容包含几个部份:
- dataIds:哪些 DataId 是我们关心的。
- nacosServer:这些配置将被同步到 NacosServer 的哪个命名空间、分组,并且提供了 Nacos Server 的访问必要信息。
- strategy:同步配置时的偏好策略。
- objectRef:配置的数据载体。
apiVersion: nacos.io/v1 kind: DynamicConfiguration metadata: name: dc-demo-cluster2server spec: dataIds: - data-id1.properties - data-id2.yml nacosServer: endpoint: <your-nacos-server-endpoint> namespace: <your-nacos-namespace-id> group: <your-nacos-group> authRef: apiVersion: v1 kind: Secret name: nacos-auth strategy: syncPolicy: Always syncDirection: cluster2server syncDeletion: true objectRef: apiVersion: v1 kind: ConfigMap name: nacos-config-cm --- apiVersion: v1 kind: ConfigMap metadata: name: nacos-config-cm namespace: default data: data-id1.properties: | key=value key2=value2 data-id2.yml: | app: name: test --- apiVersion: v1 kind: Secret metadata: name: nacos-auth data: ak: <base64 ak> sk: <base64 sk>
通过这样一份简单清晰的 DC 资源,我们将 Kubernetes 中的 ConfigMap 与 Nacos 中的配置管理建立了关系,当然设计之中并不局限于 ConfigMap,可以是任意的 Kubernetes 资源作为数据载体。不同的数据载体在 Kubernetes 侧有着不同的使用场景,如 ConfigMap 载体可以作为环境变量或文件系统挂在到 Pod 中,hashicorp vault 载体实现了配置安全加密等等。
在这样的场景下,我们成功将微服务应用的主要配置维护动作统一到了 Kubernetes 侧。借助一些三方工具,我们可以很轻易的搭建一些功能特性。比如基于 git、kubectl、jenkins,可以很方便的搭建一套带有版本控制、权限控制、自动化更新的配置变更流水线。又或是借助 helm、customize 等软件,我们可以将应用定义与应用配置真正打包在一起,实现一件交付。
将配置同步到 Kubernetes 中
既然 Nacos 配置的管理行为可以通过 DC 概念集成到 Kubernetes 接口中,那么反过来也是可以做到的。下面这份 DC 资源,定义了将 Nacos 中的配置同步到 Kubernetes 中。与上面定义将配置从 Kubernetes 同步到 Nacos 中,只有两处差别。
- spec.strategy.syncDirection:这个配置表明了配置的同步方向。
- spec.objectRef:从 Nacos 中将配置同步到 Kuberntes 中时,我们可以不指定数据载体,那么会默认使用一个同名的 ConfigMap 作为数据载体。
apiVersion: nacos.io/v1 kind: DynamicConfiguration metadata: name: dc-demo-server2cluster spec: dataIds: - data-id1.properties - data-id2.yml nacosServer: endpoint: <your-nacos-server-endpoint> namespace: <your-nacos-namespace-id> group: <your-nacos-group> authRef: apiVersion: v1 kind: Secret name: nacos-auth strategy: syncPolicy: Always syncDirection: server2cluster syncDeletion: true --- apiVersion: v1 kind: Secret metadata: name: nacos-auth data: ak: <base64 ak> sk: <base64 sk>
如此一来,我们将 Kubernetes 中配置的管理行为统一到了 Nacos Server 侧。借助 Nacos 的特性能力,如丰富的权限控制、历史版本追溯等能力,对于 Kubernetes 中的配置也能享受到这些特性。当然本质上解决的还是将配置管理的集中在一处的问题。
云原生下高效运维微服务应用
阿里云的企业级分布式应用服务(EDAS)中,根据多年云上微服务应用托管经验,将服务治理、可观测、弹性等能力融合集成在一起,沉淀出 CloudApp 概念。当前 CloudApp 已经集成了 DynamicConfiguration 概念,并针对其中 nacosServer 访问配置做了简化。在 EDAS 环境中,只需要对 Kubernetes 原生 Workload(如 Deployment/StatefulSet)增加一个 label,即可自动启用服务治理、可观测等能力。以下是一份简单的 helm demo,对于用户而言,没有繁琐的各种概念入侵,只需要专注于应用本身。借助于 CloudApp 概念,极大地降低了微服务应用最佳实践的技术门槛,同时又极大地提升了微服务应用的运维效率。
apiVersion: apps/v1 kind: Deployment metadata: name: demo-app-1 labels: edas.alibabacloud.com/app: demo-app-1 spec: replicas: 1 selector: matchLabels: app: demo-app-1 template: metadata: labels: app: demo-app-1 spec: containers: - name: main image: registry.cn-hangzhou.aliyuncs.com/edas-demo-project/consumer:1.0 --- apiVersion: nacos.io/v1 kind: DynamicConfiguration metadata: name: for-app1 spec: dataIds: - data-id1.properties - data-id2.yml nacosServer: namespace: <EDAS 微服务空间ID> group: <配置分组> strategy: syncPolicy: Always syncDirection: cluster2server syncDeletion: true objectRef: apiVersion: v1 kind: ConfigMap name: nacos-config-cm --- apiVersion: v1 kind: ConfigMap metadata: name: nacos-config-cm namespace: default data: data-id1.properties: | key=value key2=value2 data-id2.yml: | app: name: test
从 CloudApp 的技术架构图上,可以看出有三条主要变更渠道,可以根据运维偏好选择合适的变更方式。
- 白屏变更:通过云产品权限控制变更,同时享受完整应用运维能力。
- 黑屏变更途径 1:通过 Kubernetes RBAC 权限体系控制变更,同时享受完整应用运维能力。
- 黑屏变更途径 2:只关心应用本身和应用运行时配置,在不引入其他认知概念的情况下,享有默认的应用运维能力(如可观测、无损发布等)。
下一步规划
当前 NacosController 项目已经初步实现了 DynamicConfiguration 概念,解决了 Nacos 核心能力之一的配置管理与 Kubernetes 融合问题。
下一步我们将围绕 Nacos 的另一个核心能力:服务动态发现,将其与 Kubernetes 进行融合,从而解除应用程序对于 Nacos SDK 的依赖,以及降低 Nacos 体系微服务应用与非 Nacos 体系应用间的调用门槛。
作者:之卫
本文为阿里云原创内容,未经允许不得转载。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
得物云原生容器技术探索与落地实践
一、前言 得物 App 作为互联网行业的后起之秀,在快速的业务发展过程中基础设施规模不断增长,继而对效率和成本的关注度也越来越高。我们在云原生技术上的推进历程如图所示,整体上节奏还是比较快的。 从 2021 年 8 月开始,我们以提升资源使用率和资源交付效率为目标,开始基于云原生技术建设整个服务体系的高可用性、可观测性和高运维效率,同时要保证成本可控。在容器化过程中我们遇到了很多的挑战,包括:如何将存量的服务在保持已有研发流程不变的情况下,做到容器化部署和管理;容器化之后如何做到高效地运维;如何针对不同的业务场景,提供不同的容器化方案等等。此外,通过技术手段实现持续的成本优化是我们的长期目标,我们先后建设落地了画像系统、混部方案和调度优化等方案。本文把得物在推进云原生容器技术落地过程中相关方案和实践做一些总结和梳理,欢迎阅读和交流。 二、云原生应用管理 云原生应用管理方式 容器与 ECS 的资源形态是有差异的,所以会造成在管理流程上也会有不同之处。但是为了尽可能降低容器化带来的使用体验上的差异,我们参考业内容器应用 OAM 模型的设计模式,对容器的相关概念做了屏蔽和对等解释。例如:以“...
- 下一篇
云原生场景下,AIGC 模型服务的工程挑战和应对
作者:徐之浩、车漾 “成本”、“性能”和 “效率”正在成为影响大模型生产和应用的三个核心因素,也是企业基础设施在面临生产、使用大模型时的全新挑战。AI 领域的快速发展不仅需要算法的突破,也需要工程的创新。 大模型推理对基础设施带来更多挑战 首先,AI 商业化的时代,大模型推理训练会被更加广泛的使用。比较理性的看待大模型的话,一个大模型被训练出来后,无外乎两个结果,第一个就是这个大模型没用,那就没有后续了;另一个结果就是发现这个模型很有用,那么就会全世界的使用,这时候主要的使用都来自于推理,不论是 openAI 还是 midjourney,用户都是在为每一次推理行为付费。随着时间的推移,模型训练和模型推理的使用比重会是三七开,甚至二八开。应该说模型推理会是未来的主要战场。 大模型推理是一个巨大的挑战,它的挑战体现在成本、性能和效率。 其中成本最重要,因为大模型的成本挑战在于模型规模越来越大,使用的资源越来越多,而模型的运行平台 GPU 由于其稀缺性,价格很昂贵,这就导致每次模型推理的成本越来越高。而最终用户只为价值买单,而不会为推理成本买单,因此降低单位推理的成本是基础设施团队的首要任务...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Red5直播服务器,属于Java语言的直播服务器
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker使用Oracle官方镜像安装(12C,18C,19C)