英文全称Dynamic Naming and Configuration Service，即动态命名和配置服务，即服务注册与发现。
二、Ncaos的作用之服务注册与发现（1）原生API请求流程：
用户服务需要调用权限验证服务，即会在内部配置文件中配上权限验证服务IP加端口192.168.1.1:8080 在调用的时候即可找到权限验证服务的地址。
用户服务属于消费方。
权限验证服务属于服务提供方。
（2）nginx负载均衡
但是，随着项目的发展，并发量提高，单台权限验证服务器无法满足项目的请求，则项目架构进一步演化，我们会配置多分权限验证服务，以满足高并发的用户服务请求，然后在中间层加入nginx进行负载均衡配置。用户服务端只需要配置统一的权限验证接口地址，即可让nginx自动去进行负载均衡，轮询调用空闲的权限验证服务。
但是这种方式需要我们需要根据每个权限验证服务节点的信息，实时维护nginx stream config 非常的繁琐，也不利于项目的后期维护，若某个权限验证服务挂掉，或者出现网络异常，也不能及时发现，造成轮询到该服务上的请求失败，所以需要一套服务注册管理工具来管理各个服务。
（3）nacos注册中心
nacos注册中心请求流程：
①权限验证服务将自己注册到nacos注册中心。并且统一使用服务名称作为唯一标致。一个服务名称有多个实例，即权限验证服务可以有多个不同的部署点。
②用户服务在调用时，只需要请求统一的服务名称。
③注册中心将根据服务名称找到该服务名称下所有的实例，根据负载均衡算法，找出一个可用的实例的IP:端口，返回给用户服务，用户服务拿到返回的地址，即可调用该服务下的可用实例。
三、Ncaos的作用之配置中心1.传统项目处理配置
（1）静态化配置
大多数在项目配置写配置文件中，然后将各类参数配置、应用配置、环境配置、安全配置、业务配置 都写到这个文件里。当项目代码逻辑中需要使用配置的时候，就从这个配置文件中读取。这种做法虽然简单，但如果参数需要修改，就非常的不灵活，甚至需要重启整个项目才能生效。
（2）由于配置文件是放在项目中的，但是我们项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置参数理论上都是不同的，所以我们在配置文件中根据不同环境配置不同的参数，这些都是手动维护，在项目发布的时候，极其容易因开发人员的失误导致出错。
（3）配置文件过于分散
如果一个项目中存在多个逻辑模块独立部署，每个模块所使用的配置内容又不相同，传统的做法是会在每一个模块中都放一个配置文件，甚至不同模块的配置文件格式还不一样。那么长期的结果就是配置文件过于分散混乱，难以管理。
2.nacos配置中心
随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：
- 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏；
- 时效性：修改配置，需要重启服务才能生效；
- 局限性：无法支持动态调整：例如日志开关、功能开关；
因此，我们需要配置中心来统一管理配置！把业务开发者从复杂以及繁琐的配置中解脱出来，只需专注于业务代码本身，从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率，并为运维的细力度管控、应急处理等提供强有力的支持。
