Nacos 在云原生架构下的演进

本文涉及的产品
云原生网关 MSE Higress,422元/月
性能测试 PTS,5000VUM额度
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 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 内容包含几个部份:


  1. dataIds:哪些 DataId 是我们关心的。
  2. nacosServer:这些配置将被同步到 NacosServer 的哪个命名空间、分组,并且提供了 Nacos Server 的访问必要信息。
  3. strategy:同步配置时的偏好策略。
  4. 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 中,只有两处差别。


  1. spec.strategy.syncDirection:这个配置表明了配置的同步方向。
  2. 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. 白屏变更:通过云产品权限控制变更,同时享受完整应用运维能力。
  2. 黑屏变更途径 1:通过 Kubernetes RBAC 权限体系控制变更,同时享受完整应用运维能力。
  3. 黑屏变更途径 2:只关心应用本身和应用运行时配置,在不引入其他认知概念的情况下,享有默认的应用运维能力(如可观测、无损发布等)。



下一步规划


当前 NacosController 项目已经初步实现了 DynamicConfiguration 概念,解决了 Nacos 核心能力之一的配置管理与 Kubernetes 融合问题。


下一步我们将围绕 Nacos 的另一个核心能力:服务动态发现,将其与 Kubernetes 进行融合,从而解除应用程序对于 Nacos SDK 的依赖,以及降低 Nacos 体系微服务应用与非 Nacos 体系应用间的调用门槛。


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
1月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
1月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
1月前
|
安全 Java API
Nacos 3.0 Alpha 发布,在安全、泛用、云原生更进一步
近期,我们欣喜地宣布 Nacos 3.0 的第一个版本 Nacos 3.0-ALPHA 已经发布。Nacos 3.0 的目标是在 2.0 的基础上,进一步优化安全性、易用性和标准化。同时,我们将引入更多功能,帮助用户在分布式协调、AI 大模型、云原生等多种场景中更好地使用 Nacos,以提升其广泛适应性。
125 12
|
3天前
|
人工智能 编解码 自然语言处理
AI运用爆发时代, 视频服务云原生底座“视频云”架构的全智能再进化
本文介绍了AI运用爆发时代下,视频服务云原生底座“视频云”架构的全智能再进化。随着AI技术的发展,视频内容和交互方式正经历深刻变革。文章从背景、视频AI应用挑战、视频云网端底座、AIGC时代的全智能化及未来展望五个方面展开讨论。重点阐述了云、网、端三者如何深度融合,通过AI赋能视频采集、生产、分发和消费全流程,实现视频处理的智能化和高效化。同时,展望了未来AI在视频领域的创新应用和潜在的杀手级应用。
|
1月前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####
|
1月前
|
弹性计算 运维 Cloud Native
云原生架构的崛起与未来展望
在数字化转型的浪潮中,云原生架构凭借其高效、灵活和可扩展的特性,正逐渐成为企业IT战略的核心。本文旨在探讨云原生架构的定义、关键特性、实施优势以及面临的挑战,同时展望未来的发展趋势。通过深入分析,我们期望为读者提供一个关于云原生架构全面而深入的视角,助力企业在云计算时代做出更明智的决策。
51 3
|
1月前
|
Cloud Native API 持续交付
云原生时代的微服务架构设计
随着云计算的蓬勃发展,云原生概念逐渐成为IT行业的热点。本文将通过深入浅出的方式,介绍在云原生环境下,如何设计一个高效、可扩展的微服务架构。文章不仅涉及理论概念,还将结合实际代码示例,帮助读者理解微服务架构的核心要素和设计原则,以及如何在云平台上实现这些设计。
|
2月前
|
Cloud Native 持续交付 云计算
云原生技术在现代IT架构中的转型力量####
本文深入剖析了云原生技术的精髓,探讨其在现代IT架构转型中的关键作用与实践路径。通过具体案例分析,展示了云原生如何赋能企业实现更高效的资源利用、更快的迭代速度以及更强的系统稳定性,为读者提供了一套可借鉴的实施框架与策略。 ####
33 0
|
1月前
|
Cloud Native API 持续交付
云原生架构下的微服务治理策略与实践####
本文旨在探讨云原生环境下微服务架构的治理策略,通过分析当前面临的挑战,提出一系列实用的解决方案。我们将深入讨论如何利用容器化、服务网格(Service Mesh)等先进技术手段,提升微服务系统的可管理性、可扩展性和容错能力。此外,还将分享一些来自一线项目的经验教训,帮助读者更好地理解和应用这些理论到实际工作中去。 ####
52 0
|
1月前
|
Cloud Native 持续交付 云计算
云原生架构的崛起:企业数字化转型的加速器
在当今快速发展的技术环境中,企业正面临着前所未有的变革压力。本文深入探讨了云原生架构如何成为推动企业数字化转型的关键力量。通过分析其核心概念、优势以及实施策略,本文旨在为读者提供对云原生技术的全面理解,展示其在现代企业中不可或缺的作用。
34 0