SpringCloud（pig框架）：Nacos第一篇

概览

欢迎来到 Nacos 的世界！

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service的首字母简称，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

什么是 Nacos？

服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理：

Nacos 的关键特性包括:

• 服务发现和服务健康监测
  Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。
• 动态配置服务
  动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
• 动态 DNS 服务
  动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。Nacos 提供了一些简单的 DNS APIs TODO 帮助您管理服务的关联域名和可用的 IP:PORT 列表.
• 服务及其元数据管理
  Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。

Nacos 地图

一图看懂 Nacos，下面架构部分会详细介绍。

• 特性大图：要从功能特性，非功能特性，全面介绍我们要解的问题域的特性诉求
• 架构大图：通过清晰架构，让您快速进入 Nacos 世界
• 业务大图：利用当前特性可以支持的业务场景，及其最佳实践
• 生态大图：系统梳理 Nacos 和主流技术生态的关系
• 优势大图：展示 Nacos 核心竞争力
• 战略大图：要从战略到战术层面讲 Nacos 的宏观优势

为什么需要服务注册与发现

• 如下图，当 A用户服务调用B订单服务时，一般情况下会使用 httputils 请求 B服务的 IP:port (http://192.168.0.200:8080/xxx) 即可。但是当 B订单服务的网络信息（IP等）发生改变则A对应服务的代码配置也要做对应的修改，增加服务间的耦合性和运维部署的复杂性。

 

• 如下图， 当A用户服务调用B订单服务时，为了保证B服务（服务提供方）的高可用，我们会对B服务部署多份，然后通过NGINX 反向代理，提供统一的服务地址 。 我们需要根据每个B服务节点的信息，实时维护nginx stream config 非常的繁琐。

解决方案

如下图 当服务调用方调用某个服务的时候，可以通过服务名字去服务注册发现中心获取可用的服务，服务发现中心会从内存的服务列表获取所有可用的服务，然后负载均衡根据既定的规则选择一个服务将 HTTP 服务 ip port 返回给调用方。

传统项目处理配置的问题

1. 静态化配置

大多数在项目配置写在例如 application.propertie，然后将各类 参数配置、应用配置、环境配置、安全配置、业务配置 都写到这个文件里。当项目代码逻辑中需要使用配置的时候，就从这个配置文件中读取。这种做法虽然简单，但如果参数需要修改，就非常的不灵活，甚至需要重启运行中的项目才能生效。

2. 配置文件无法区分环境。

由于配置文件是放在项目中的，但是我们项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置参数理论上都是不同的，所以我们在配置文件中根据不同环境配置不同的参数，这些都是手动维护，在项目发布的时候，极其容易因开发人员的失误导致出错。

3. 配置文件过于分散

如果一个项目中存在多个逻辑模块独立部署，每个模块所使用的配置内容又不相同，传统的做法是会在每一个模块中都放一个配置文件，甚至不同模块的配置文件格式还不一样。那么长期的结果就是配置文件过于分散混乱，难以管理。

4. 配置修改无法追溯

因为采用的静态配置文件方式，所以当配置进行修改之后，不容易形成记录，更无法追溯是谁修改的、修改时间是什么、修改前是什么内容。既然无法追溯，那么当配置出错时，更没办法回滚配置了。

Nacos 配置中心

传统配置的方式已经暴露出了很多问题，其他的诸如：历史版本管理，权限控制，安全性等等问题，是传统的配置文件无法解决的！

随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：

• 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏；
• 时效性：修改配置，需要重启服务才能生效；
• 局限性：无法支持动态调整：例如日志开关、功能开关；

因此，我们需要配置中心来统一管理配置！把业务开发者从复杂以及繁琐的配置中解脱出来，只需专注于业务代码本身，从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率，并为运维的细力度管控、应急处理等提供强有力的支持。

Nacos Server：官方部署方式

文档链接：Nacos 快速开始

Nacos Server：源码部署方式（SpringPig为例）

git下载地址：pig: 基于Spring Boot 2.7、 Spring Cloud 2021 & Alibaba、 SAS OAuth2 的微服务RBAC 权限管理系统。 记得上边点个star 关注更新。微服务交流群见底部二维码。

使用模块：pig-register
数据库初始化脚本：pig_config.sql

Nacos运行效果

Nacos客户端使用

配置和初始化

  
        
            com.alibaba.cloud
            spring-cloud-starter-alibaba-nacos-discovery
        
        
        
            com.alibaba.cloud
            spring-cloud-starter-alibaba-nacos-config
        

server:
  port: 9999

spring:
  application:
    name: @artifactId@
  cloud:
    nacos:
     #服务发现地址：nacos server服务器地址 
      discovery:
        server-addr: pig-register:8848
     #配置中心地址：nacos server服务器地址
      config:
        server-addr: pig-register:8848
  config:
    #配置监听格式
    import:
      - optional:nacos:[email protected]@.yml
      - optional:nacos:${spring.application.name}[email protected]@.yml

引入效果（pig-gateway为例）

服务发现效果

参考文档：

什么是 Nacos

前言 · 语雀