声明
原创文章，转载请标注。https://www.cnblogs.com/boycelee/p/17993697
《码头工人的一千零一夜》是一位专注于技术干货分享的博主，追随博主的文章，你将深入了解业界最新的技术趋势，以及在Java开发和安全领域的实用经验分享。无论你是开发人员还是对逆向工程感兴趣的爱好者，都能在《码头工人的一千零一夜》找到有价值的知识和见解。
配置中心系列文章
《【架构师视角系列】Apollo配置中心之架构设计（一）》https://www.cnblogs.com/boycelee/p/17967590
《【架构师视角系列】Apollo配置中心之Client端（二）》https://www.cnblogs.com/boycelee/p/17978027
《【架构师视角系列】Apollo配置中心之Server端（ConfigSevice）（三）》https://www.cnblogs.com/boycelee/p/18005318
《【架构师视角系列】QConfig配置中心系列之架构设计（一）》https://www.cnblogs.com/boycelee/p/18013653
《【架构师视角系列】QConfig配置中心系列之Client端（二）》https://www.cnblogs.com/boycelee/p/18033286
一、架构
基础模型
架构图
架构分层
架构分层可以分为四层，分别是客户端层、网络层、服务层以及数据层，其中客户端层包括Client模块和Admin模块，网络层包括Server模块中的EntryPoint部分和NginxLB以及Eureka，服务层仅包括Server模块。
运行规则
（1）Server将自己注册到注册中心Eureka中，
（2）当三方应用拉取配置时，Client端通过访问域名的方式，请求经过NginxLB访问到EntryPoint并从Eureka中获取到已注册的Server列表及其对应IP、端口信息，这时Client端就可以通过ip+port的形式直接访问到已注册的某个Server实例，获取到对应配置信息。
（3）当管理人员操作配置时，可以通过独立部署的Admin模块（管理平台）直接访问数据库，对配置数据进行增删查改操作。
（4）当管理人员发布配置时，Client端通过访问域名的方式，请求经过NginxLB访问到EntryPoint并从Eureka中获取到已注册的Server列表及其对应IP、端口信息，这时Admin端就可以通过ip+port的形式直接访问到所有已注册的Server实例，获取到对应配置信息。
模块划分
相对于Apollo的分层，Qconfig的分层相对更简单一些，大致分为三个模块分别是Admin模块、Client模块、Server模块。
Admin模块
提供web界面用于配置管理。但与Apollo配置中心不同的地方在于Qconfig的模块划分并没有Apollo这么明确，所有与配置操作相关的逻辑都在Admin模块中。
其中包括：
- 应用创建、查看、修改、发布以及回滚等功能
- 提供修改、发布配置等接口。
- 配置变更时通知Server
Client模块
提供实时配置获取与更新。其与Apollo中的模块职责是一样的。
其中包括：
- 客户端负责从Config Service获取应用的配置信息；
- 监听配置变化。当配置发生更新时，Config Service会通知Client，并出发其进行配置刷新；
- 通过ip + port的方式远程调用Config Service，以获取配置数据。
Server模块
服务于Client端，为客户端提供获取配置的接口。
其中包括：
- 基于长轮询，提供配置更新接口；
- 提供配置获取接口。
二、总结
（1）Apollo和QConfig都是携程集团的配置中心项目，Apollo主要在携程内部使用，而Qconfig主要去哪儿内部使用；
（2）从开源社区维护角度上，相对而言Apollo的开源工作要做得好很多；
（3）从架构设计和代码整洁这两个维度上，个人觉得QConfig要做得更优秀一些。
三、最后
《码头工人的一千零一夜》是一位专注于技术干货分享的博主，追随博主的文章，你将深入了解业界最新的技术趋势，以及在Java开发和安全领域的实用经验分享。无论你是开发人员还是对逆向工程感兴趣的爱好者，都能在《码头工人的一千零一夜》找到有价值的知识和见解。
懂得不多，做得太少。欢迎批评、指正。