微服务分布式配置中⼼选型Apollo，Consul，Nacos，Springcloudconfig
分布式配置中⼼选型
安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏。
时效性：修改配置，需要重启服务才能⽣效。
局限性：⽆法⽀持动态调整：例如⽇志开关、功能开关。
因此，分布式配置中⼼应运⽽⽣！
范围：Apollo，Consul，Nacos，Spring cloud config
配置中⼼需要符合的条件：
作为配置中⼼，配置的整个管理流程应该具备流程化能⼒，那些停更的组件就不考虑了，有问题都没处问去，最好是操作简单，依赖简单，维护简单，功能稳定。
灰度发布
配置的灰度发布是配置中⼼⽐较重要的功能，当配置的变更影响⽐较⼤的时候，需要先在部分应⽤实例中验证配置的变更是否符合预期，然后再推送到所有应⽤实例。
Spring Cloud Config⽀持通过/bus/refresh端点的destination参数来指定要更新配置的机器，不过整个流程不够⾃动化和体系化。Apollo可以直接在控制台上点灰度发布指定发布机器的IP，接着再全量发布，做得⽐较体系化。Nacos⽀持灰度发布。
CAP
CAP理论是分布式架构中重要理论
⼀致性(Consistency) (所有节点在同⼀时间具有相同的数据)
可⽤性(Availability) (保证每个请求不管成功或者失败都有响应)
分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
Nacos CP+AP, Consul AP
权限管理
配置的变更和代码变更都是对应⽤运⾏逻辑的改变，重要的配置变更常常会带来核弹的效果，对于配置变更的权限管控和审计能⼒同样是配置中⼼重要的功能。
Spring Cloud Config依赖Git的权限管理能⼒，开源的GitHub权限控制可以分为Admin、Write和Read权限，权限管理⽐较完善。Apollo通过项⽬的维度来对配置进⾏权限管理，⼀个项⽬的owner可以授权给其他⽤户配置的修改发布权限。
Nacos具备权限管理能⼒。
版本管理&回滚
当配置变更不符合预期的时候，需要根据配置的发布版本进⾏回滚。Spring Cloud Config、Apollo和Nacos都具备配置的版本管理和回滚能⼒，可以在控制台上查看配置的变更情况或进⾏回滚操作。Spring Cloud Config通过Git来做版本管理，更⽅便些。
配置格式校验
应⽤的配置数据存储在配置中⼼⼀般都会以⼀种配置格式存储，⽐如Properties、Json、Yaml等，如果配置格式错误，会导致客户端解析配置失败引起⽣产故障，配置中⼼对配置的格式校验能够有效防⽌⼈为错误操作的发⽣，是配置中⼼核⼼功能中的刚需。
Spring Cloud Config使⽤Git，⽬前还不⽀持格式检验，格式的正确性依赖研发⼈员⾃⼰。
Apollo和Nacos都会对配置格式的正确性进⾏检验，可以有效防⽌⼈为错误。
监听查询
当排查问题或者进⾏统计的时候，需要知道⼀个配置被哪些应⽤实例使⽤到，以及⼀个实例使⽤到了哪些配置。
Spring Cloud Config使⽤Spring Cloud Bus推送配置变更，Spring Cloud Bus兼容 RabbitMQ、Kafka等，⽀持查询订阅Topic和Consumer的订阅关系。
Apollo可以通过灰度实例列表查看监听配置的实例列表，但实例监听的配置(Apollo称为命名空间)⽬前还没有展⽰出来。
Nacos可以查看监听配置的实例，也可以查看实例监听的配置情况。
基本上，这三个产品都具备监听查询能⼒，在我们⾃⼰的使⽤过程中，Nacos使⽤起来相对简单，易⽤性相对更好些。
多环境
在实际⽣产中，配置中⼼常常需要涉及多环境或者多集，业务在开发的时候可以将开发环境和⽣产环境分开，或者根据不同的业务线存在多个⽣产环境。如果各个环境之间的相互影响⽐较⼩（开发环境影响到⽣产环境稳定性），配置中⼼可以通过逻辑隔离的⽅式⽀持多环境。Spring Cloud Config⽀持Profile的⽅式隔离多个环境，通过在Git上配置多个Profile的配置⽂件，客户端启动时指定Profile就可以访问对应的配置⽂件。
Apollo也⽀持多环境，在控制台创建配置的时候就要指定配置所在的环境，客户端在启动的时候指定JVM参数ENV来访问对应环境的配置⽂件。
Nacos通过命名空间来⽀持多环境，每个命名空间的配置相互隔离，客户端指定想要访问的命名空间就可以达到逻辑隔离的作⽤。
多集
当对稳定性要求⽐较⾼，不允许各个环境相互影响的时候，需要将多个环境通过多集的⽅式进⾏物理隔离。
Spring Cloud Config可以通过搭建多套Config Server，Git使⽤同⼀个Git的多个仓库，来实现物理隔离。
Apollo可以搭建多套集，Apollo的控制台和数据更新推送服务分开部署，控制台部署⼀套就可以管控多个集。
Nacos控制台和后端配置服务是部署在⼀起的，可以通过不同的域名切换来⽀持多集。
讨论
1.Spring Cloud Config原⽣不⽀持配置的实时推送，需要依赖Git的WebHook⽤于存储和修改配置、Spring Cloud Bus通知客户端配置变更，和客户端/bus/refresh端点，⾼可⽤⽅案成本较⾼
2.Apollo分为MySQL，Config Service，Admin Service，Portal四个模块，MySQL存储Apollo元数据和⽤户配置数据; Config Service提供配置的读取、推送等功能，客户端请求都是落到Config Service上; Admin Service提供配置的修改、发布等功能，Portal操作的服务就是Admin Service; Portal提供给⽤户配置管理界⾯；功能强⼤，社区活跃，但较为复杂，部署组件较多，运维成本⽐⾼。
符合条件的组件consul，nacos
consul
依赖：不依赖其他组件
应⽤内/外：属于外部应⽤，侵⼊性⼩
ACP原则：遵循CP原则（⼀致性+分离容忍） 服务注册稍慢，由于其⼀致性导致了在Leader挂掉时重新选举期间真个consul不可⽤。
版本迭代：⽬前仍然进⾏版本迭代
集成⽀持：⽀持SpringCloud K8S集成
访问协议：HTTP/DNS
雪崩保护：不⽀持雪崩保护
集成：SpringCloud集成，K8S集成
⾃动注销实例：不⽀持
界⾯：英⽂界⾯，不符合国⼈习惯
上⼿：复杂⼀点
nacos
依赖：mysql
应⽤内/外：属于外部应⽤，侵⼊性⼩
ACP原则：通知遵循CP原则（⼀致性+分离容忍） 和AP原则（可⽤性+分离容忍）
版本迭代：⽬前仍然进⾏版本迭代，最近的提交是⼏天前
集成⽀持：⽀持Dubbo 、SpringCloud、K8S集成
访问协议：HTTP/动态DNS/UDP
分布式和微服务的关系雪崩保护：⽀持雪崩保护
集成：SpringCloud集成，Dubbo集成，K8S集成
⾃动注销实例：⽀持
界⾯：国产服务，中⽂界⾯，符合国⼈习惯
上⼿：极易，中⽂⽂档，案例，社区活跃
Consul实际上是和Nacos⽐较相似的产品，虽然Consul⽬前的主要发展⽅向放在了Service Mesh，但是Consul最初⽀持的服务发现和配置管理，也是Nacos的两⼤功能。
虽然Nacos在Consul之后以与之相似的部署架构开源，但这并不意味着Nacos在功能和架构上也模仿Consul，Nacos的架构和功能是由阿⾥巴巴内部⼗年的运⾏演进经验得来，所以⼆者的⽐较也⼀定会让⼤家更加了解他们的定位和演进⽅向是完全不⼀样的。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。