目前，在公司内部微服务架构基础设施建设中，技术选型主要基于SpringCloud技术，也就是俗称的“全家桶”。★因为它有微服务架构体系所需的各种服务组件，如服务注册发现（如SpringCloudEureka、Zookeeper、Consul）、API网关路由服务（SpringCloudZuul）、客户端负载均衡（SpringCloudRibbon、By默认情况下，Zuul集成了Ribbon）、服务容错保护（SpringCloudHystrix）、消息总线（SpringCloudBus）、分布式配置中心（SpringCloudConfig）、消息驱动微服务（SpringCloudStream）、分布式链路跟踪服务（春云侦探）。》本文主要讨论组件分布式配置中心之一。SpringCloudConfig配置中心介绍&架构配置中心是微服务架构体系中比较重要的组件之一，SpringCloud官方提供了SpringCloudConfig分布式配置中心的配置center，提供集中的外部配置支持，分为客户端和服务端两部分，服务端称为配置中心，是一个独立的微服务应用，用于连接仓库（如Git，Svn），不为客户端提供获取配置的接口；而客户端是各个微服务应用，通过指定配置中心地址从远端获取配置内容，并在启动时将配置信息加载到应用上下文中。由SpringClo实现udConfig中心默认使用Git来存储配置信息，因此也支持基于Git仓库自身特点的版本控制管理。考察了组件，主要采用了基于消息总线的架构。架构图如下：配置中心架构需要依赖外部MQ组件，如Rabbit、Kafka等实现远程环境事件变化通知，基于Git可以实现客户端的实时配置变化挂钩函数。同时，在架构图的最右边，有一个Selfschedulingreferser。这是我在实践中添加的扩展功能。目的是当依赖的消息组件出现问题时，如果此时更改了Git仓库的配置，可能导致部分或全部客户端无法获取到最新的配置，从而导致客户端应用配置数据无法实现最终一致性，从而导致上线问题。★自调度刷新器是一个定时任务，默认每5分钟执行一次。执行时会判断，如果本地Git仓库版本与远程Git仓库版本不一致，会从配置中心获取最新的配置并加载，保证最终配置的一致性。》实际使用后会发现SpringCloudConfig的配置中心不是很好用，如果是小型项目问题不大，但不适合中大型企业级配置管理，因此，我在比较了业界开源的配置中心后，最终选择了携程开源的Apollo配置中心，解决微服务架构等项目中的配置管理痛点，下面来和SpringCloud做一个更直观的对比Config与Apollo配置中心：ApolloVSSpringCloudConfig通过上面的对比图，发现SpringCloudConfig的缺陷还是挺大的，比如高可用最后一项，Apollo配置中心客户端应用加载完后配置，本地会生成一个缓存文件，即使配置中心的所有服务都宕机了，但是配置c不会更新，但不影响你的服务启动。这在SpringCloudConfig中是不可能的。有人会说，我们可以把应用程序类路径下的应用程序配置文件添加为“口袋使用”。首先，配置不会自动同步，不是SpringCloudConfig本身的功能。另一个原因是现阶段项目中也使用了一些自研的配置中心，但并不尽如人意。部分配置中心只支持xml格式，不支持KV格式；有些配置中心是基于JMX开发的，但是只支持属性配置推送。因此，经过对Apollo配置中心的研究和使用，发现这款产品不仅适用于微服务配置管理场景，还支持xml、json、yml等多种配置格式，支持多语言客户端访问。治理也很完备。携程已经支持10万+实例运行，成熟稳定！开源配置中心对比下图是开源配置中心的详细对比：上述开??源配置中心中，Apollo社区非常活跃，不断更新迭代。在Apollo出现之前，用得比较多的是百度开源的disconf配置中心。disconf的最新代码更新时间是2年前，与Apollo相比，社区活跃度有所下降。Apollo配置中心&架构介绍Apollo（Apollo）是携程框架部开发的分布式配置中心。它可以集中管理不同环境和不同应用程序集群的配置。配置修改后，可以实时推送到应用端，并具有标准化的权限。、流程治理等特性，适用于微服务配置管理场景。服务器基于SpringBoot和SpringCloud开发，不依赖外部容器，易于部署。Java客户端不依赖任何框架，可以运行在所有的Java运行环境中，另外还额外支持Spring/SpringBoot环境。原生支持Java和.Net客户端，也支持其他语言客户端。目前，它支持Go、PHP、Python、NodeJS和C++。主要功能特点：统一管理不同环境、不同集群配置配置变更实时生效（热发布）版本发布管理灰度发布权限管理、发布审核、运行审计客户端配置信息监控，提供Java和.Net原生客户端提供开放性平台API，易于部署，依赖性小。Apollo整体架构设计：各组件功能说明：ApolloHA高可用设计：Apollo客户端架构：客户端架构原理：1.推拉结合客户端与配置中心保持长连接，配置是实时的推送定时拉取配置（默认5分钟）2.本地缓存配置缓存一个配置文件缓存在内存本地3.应用通过Apollo客户端获取最新配置订阅配置更新通知Apollo核心概念：应用（application）每个应用需要有唯一标识——appIdenvironment（环境）Apollo客户端通过不同的环境获取一个应用下的不同实例对应的配置集群（cluster）分组，不同的集群可以有不同的配置。比如北京机房和天津机房可能有不同的kafka或zk地址配置。命名空间（namespace）是一个应用程序下的不同配置的分组，不同的命名空间类似于不同的文件。如：数据库配置、RPC配置等。支持从通用组件继承配置。配置分类私有类型（private）：只能被属于它的应用获取公共类型（public）：必须是全局唯一的。使用场景：部门/组级别的共享配置，中间件客户端配置。关联类型（继承类型）：私有继承公共配置并覆盖；自定义公共组件配置方案。配置项（Item）默认和公共配置使用properties格式；私有配置支持properties/json/xml/yaml/yml格式。定位方式：app+cluster+namespace+item_key权限管理系统管理员拥有所有权限创建者可以代为创建项目，负责人默认为项目管理员，一般创建者=负责人项目管理员可以createclusters,Namespace,managementProject和Namespace权限Edit权限只能编辑不能发布Publish权限只能发布不能编辑普通用户可以搜索查看所有项目配置，但没有相关操作权限在Apollo配置中使用和扩展使用后Apollo配置中心，进一步功能开发已做Extension，接入公司SSO和邮件通知接入。基于SpringCloudConfig微服务架构体系，如果之前使用过SpringCloudConfig配置中心，也可以通过以下方式平滑迁移到Apollo配置中心。SpringCloud微服务项目在pom.xml中引入如下依赖：
