Nacos 2.3.0 正式版发布，Nacos Controller 项目开源

新版本发布

Nacos 2.3.0-BETA 版本经过 1 个多月的社区测试，修复了部分的问题并对部分新功能的使用进行了少量优化后，于 2023 年 12 月 7 日正式发布。

Nacos 2.3.0 版本基于 2.3.0-BETA 版本为基础，主要进行了如下更新：

• 基于能力协商机制，支持通过 Grpc 的方式进行持久化服务实例的注册及删除。
• Console UI 中显示更多内容，例如部署模式等。
• 对参数校验功能的实现方式进行优化。
• 对 TopN 指标的实现进行重构，优化准确性和内存消耗。

详细的更新日志请查看：

## Feature
[#11393] Support register or deregister persistent instance by grpc.

## Enhancement&Refactor
[#11275] Enhance console ui deploy, show more information like `mode`.
[#11298] Strip groupNamePrefix of instance serviceName at register or deregister.
[#11310] Simplify the validate method for serviceinfo.
[#11342] Simplify BatchDeregister instances conditions to ip and port.
[#11343] Simplified parameters checker control logic.
[#11352] Refactor topN logic to enhance memory usage and accuracy.

## BugFix
[#10353] Handling DataIntegrityViolationException and DuplicateKeyException together.
[#11299] Fix console ui auth pagination failure.
[#11382] Fix console ui listening query pagination failure.
[#11384] Fix console ui comparing configuration failure.
[#11390] Fix Config EncryptionPluginService order problem.
[#11442] Fix listen configuration check failed without namespace.

## Dependency
[#11216] Declare httpcore as direct dependency to fix avoid conflict.
[#11396] Upgrade jackson same with spring boot dependency.
[#11439] Upgrade some UI component to solve security problem.

Nacos Controller 项目开源

在云原生下，应用代码与运行环境可以通过 Helm 或 Kustomize 等软件进行交付、维护、CICD，但应用的 Nacos 配置依然需要手工地迁移、或使用控制台修改发布配置。借助于 Nacos Controller**[1]**项目，我们可以将 Nacos 配置管理下移到 Kubernetes 集群中，又或是可以将 Kubernetes 中 ConfigMap 配置上移到 Nacos 控制台中，从而实现统一管理能力。

Nacos 配置下移到 Kubernetes 集群中

工作机制

Nacos Controller 监听集群内的 DC 资源，当 DC 资源发生变化时，Nacos Controller 将其中的配置内容同步到 Nacos Server 中。

简易 Demo

在 Nacos Controller 中，我们定义了一份 CRD：DynamicConfiguration（简称 DC），我们将 Nacos 配置保存在 ConfigMap 中，对配置的任何修改都通过 DC 将其中的配置同步到对应的 Nacos 服务端中。在后续的配置维护中，直接修改对应的 ConfigMap 即可。以下是一份简易的 Demo 示例：

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>

Kubernetes 配置上移到 Nacos 控制台

工作机制

首先需要用户创建 DC 资源指定需要同步哪些 DataId，Nacos Controller 根据读取到的 DC 配置，选择性监听 Nacos Server 中的相关配置并将配置改动同步到 Kubernetes 集群中。

简易 Demo

云原生下，应用除了需要加载 Nacos 配置外，还可能依赖一些环境变量，比如 JVM 参数通过环境变量注入。做得比较好的方式是通过 ConfigMap 等 Kubernetes 原生方式管理配置，通过引用的方式传递给应用 Pod。在 Nacos Controller 中，我们可以定义一份 DC，将 Nacos 服务端中的某些 DataId 同步到 Kubernetes 集群中的 ConfigMap 中，从而实现配置的统一管理。以下是一份示例 Demo：

apiVersion: nacos.io/v1
kind: DynamicConfiguration
metadata:
    name: dc-demo-server2cluster
spec:
  dataIds:
  - APP1_JVM_PARAMS
  - APP2_JVM_PARAMS
  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 的场景下，一个微服务应用的配置被分割成两部份，一部分存放管理在 Kubernetes 集群中的 Secret 或 ConfigMap 中，另一部份存放管理与 Nacos 配置中心。对于运维人员，我们需要知道哪些配置是存放在何处且同时需要对两个平台的配置管理操作均有所了解，一来是增加了运维人员的知识门槛，二来是增加了应用配置运维的操作成本。通过 Nacos Controller 项目，我们将应用的所有配置集中于一处管理，降低应用配置运维的门槛与复杂性。

面向 Kubernetes 运维偏好的用户

通过 Nacos Controller 项目，我们将应用与应用配置的交付和维护集中在 Kubernetes 集群中。

以下通过一份 Helm 应用 Chart 包说明如何集中管理。

.
├── Chart.yaml
├── charts
├── conf
│   ├── application-dev.properties
│   ├── application.properties
│   ├── consumer-app.properties
│   └── provider-app.yaml
├── templates
│   ├── consumer.yaml
│   ├── dc.yaml
│   └── provider.yaml
└── values.yaml

以上是一份 Chart 包目录结构，其中 conf 目录存放的是 Nacos 配置，文件名即 DataId，文件内容即对应的 Content。在 templates/dc.yaml 中，我们定义一份 ConfigMap 来组装这些配置。templates 目录中的 consumer.yaml 与 provider.yaml 分别是应用定义。

apiVersion: v1
kind: ConfigMap
metadata:
  name: nacos-config
  namespace: {{ .Release.Namespace }}
data:
  {{- range $path, $_ := .Files.Glob "conf/**" }}
  {{ $path | base }}: |-
{{ $.Files.Get $path | indent 4}}
  {{- end }}

使用上述方式定义好应用与配置后，可以借助 git 实现应用、配置的版本管理。当需要发布应用或配置时，修改对应文件后，执行 helm upgrade 命令即可。

面向 Nacos 运维偏好的用户

Nacos 配置管理能力使得应用可以动态调整运行配置，但对于一些特殊的参数，如 JVM 参数、特殊环境变量、特殊目录文件等内容，Nacos 配置管理依然无法涵盖。在 Kubernetes 集群中，我们一般将环境变量或一些特殊文件配置写入 ConfigMap 中，通过 envFrom 能力将内容引用到环境变量中或者 volumeMount 挂载到文件系统中。这样的配置管理能力与 Nacos 配置管理能力是散开的，不利于统一管理。借助于 Nacos Controller，我们将这些配置上移到 Nacos 控制台中，进行统一管理。

以下是一份 Demo 应用，通过 Nacos 控制台管理 JVM 启动参数：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: demo-app
        image: openjdk:8 #替换为你的应用镜像
        command: ["/bin/sh", "-c", "java -jar ${JVM_PARAMS} /app.jar"]
        env:
        - name: JVM_PARAMS # 从ConfigMap中载入JVM参数到环境变量中
          valueFrom:
            configMapKeyRef:
              name: nacos-config
              key: APP1_JVM_PARAMS

---
apiVersion: nacos.io/v1
kind: DynamicConfiguration
metadata:
    name: nacos-config
spec:
  dataIds:
  - APP1_JVM_PARAMS
  - APP2_JVM_PARAMS
  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>

在 Nacos 控制台中，修改 DataId：APP1_JVM_PARAMS 后，配置将自动同步到集群的 ConfigMap 中。只需重启相关应用，则对应的 JVM 参数将自动变化。成功实现将应用的所有配置集中管理在 Nacos 上。

展望

2.X 后续计划

从 2021 年 3 月 2.0.0 正式版发布至今，2.X 版本已经走了接近2年时间，如今 2.3.0 版本发布，完成了大部分功能的插件化提炼，在之后的 2.3.X 版本中，会主要对当前版本的问题进行修复，并做出小范围的功能优化。同时对于 2.4.0 版本，会作为一个 Nacos3.0 的过度版本，对大量代码进行优化重构，在提升稳定性、健壮性的同时，提升易用性和可观测性，向 Nacos3.0 版本平稳过度。

3.0 计划

Nacos 社区同时也开启了关于 Nacos3.0 的畅想和规划，Nacos 将会从统一控制面、支持国产化、存储计算分离等方向进一步演进 Nacos 的功能和架构，欢迎社区积极参与到新版本的建设中。

About Nacos

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

相关链接：

[1] Nacos Controller

https://github.com/nacos-group/nacos-controller

[2] Karsonto

https://github.com/karsonto

[3] Daydreamer-ia

https://github.com/Daydreamer-ia

作者： 杨翊

原文链接

本文为阿里云原创内容，未经允许不得转载。