阿里云微服务（二） 分布式服务配置中心以及Nacos的使用场景及实现介绍

如果说注册中心是用来在微服务中进行寻址，帮助一个服务调用另一个服务，那么服务配置的作用就是可以更方便的修改各个服务的配置，举个例子，如果我们使用配置文件进行配置信息，如果要修改某一个配置项的话，我们就需要重新打包，发布，但是如果使用配置中心的话，则只需要修改即可

关于为神马要使用配置中心，我觉得主要有以下几个原因：
1.分离的多环境配置
2.更灵活的管理权限
3.更高的安全性

关于1.分离的多环境配置
在同样的情况下可能需要不同的配置环境
如下，我们在配置中心nacos中添加一个配置信息


在服务中进行测试看能否读取配置信息

可以从下图看到读取配置信息成功

刚才的配置信息是在properties中配置的，那如果将配置文件改为yaml会怎么办呢？


可以看到读取了yaml文件的信息
这之后可以从Nacos中及时观察到两个配置文件，可以更加方便的对文件进行管理

关于配置信息的话常见的情况下同一份代码可能会在不同的场景上在profile和namespace上有不同的配置
profile是在不同的profile下可以有同样的配置项但是有不同的值
如下在环境中将profile更改为develop

使用应用名称+profile的命名来进行创建

关于namespace的不同
新建一个namespace training

记录下他的namespace id

添加到配置中

可以看到读取namespace的配置信息成功成功
关于Nacos
Nacos主要有服务注册和发现，健康检查以及访问策略三个功能

下图是nacos和zookeeper以及Eureka的对比

可以看到Nacos可以自由的选择一致性协议，关于一致性协议如何选择的问题，可以理解为
如果单次写请求的成败很重要，则应该保证cp的一致性，因为cp的一致性牺牲了服务整体的可用性来换取数据的一致性
如果单次请求的成败不是很重要，而是可以通过后续数据补偿机制来保持数据一致性，则应该保证ap的一致性
除此之外，Nacos在访问策略上也有自己的优势
服务端的访问策略更灵活，因为不需要客户端的修改以及使用过程中可以更灵活的调整

在数据服务模型中，服务和集群可以存储不同的服务配置来进行服务的管理，像一些具体信息比如ip和端口可以交给实例进行管理即可
Nacos的实现中主要分为下面几个模块

用户接口模块中定义了初步的权限校验，参数校验以及数据的转换
推送模块管理所有的订阅端，以及推送的触发，聚合以及去重等工作
健康检查模块支持服务端探测和客户端上报
访问策略通过不同的访问策略对服务端进行过滤，目前支持的访问策略有基于标签的访问策略

进行数据的存储以及server之间的同步来保证数据的一致性