Apollo与nacos--配置中心

Apollo配置中心动态生效机制，是基于http长轮询请求和Spring扩展机制实现的。在Spring容器启动过程中，Apollo通过自定义的BeanPostProcessor和BeanFactoryPostProcessor将参数中包含${…}占位符和@Value注解的Bean注册到Apollo框架中定义的注册表中。然后通过http长轮询不断的去获取服务端的配置信息，一旦配置发生变化，Apollo会根据变化的配置key找到对应的Bean，然后修改Bean的属性，从而实现了配置动态生效的特性。


配置格式校验
Apollo和Nacos都会对配置格式的正确性进行检验，可以有效防止人为错误。
环境隔离
在实际生产中，配置中心常常需要涉及多环境或者多集群，业务在开发的时候可以将开发环境和生产环境分开，或者根据不同的业务线存在多个生产环境

服务发现选型

No.1 可用性
在CAP原则中，consul，etcd，zookeeper将重点放在了CP，可用性有所丢失，这个对于数据型的服务是很有必要的。但是对我们作为注册中心使用而言，更关注可用性，在数据不一致时各服务集群提供部分可用的服务列表对我们的服务而言是可以接受的。即针对同一个服务，可能不同的节点存储的是服务不同的实例列表，这对我们的服务不会造成关键性的影响；但是如果由于注册中心的主节点宕机导致一个长时间段的重新选举，在重新选举过程中服务功能不可用，这会对我们造成非常大影响。因此针对我们的服务暂不考虑consul，etcd，zookeeper。

No.2 集成
我们的服务框架是spring cloud，这个是所有注册中心组件都支持的

No.3 web管理页面
consul，eureka，nacos都提供有web管理页面，但consul和erueka是英文界面，只有nacos是中文界面，并且仅有nacos后台管理页面支持上下线操作。

No.4 上手难度&社区活跃度
nacos上手简单，全中文文档，社区活跃，版本更新迭代中；
consul上手稍难，但社区活跃（需要较好的英文阅读能力），版本更新迭代中；
eureka上手简单，社区完善，但已于2018年七月停止开源计划。
综合考虑，选型nacos。