【架构师系列】Apollo配置中心之架构设计（一）
原创文章，转载请标注。https://www.cnblogs.com/boycelee/p/17967590
声明
原创文章，转载请标注。https://www.cnblogs.com/boycelee/p/17967590
《码头工人的一千零一夜》是一位专注于技术干货分享的博主，追随博主的文章，你将深入了解业界最新的技术趋势，以及在Java开发和安全领域的实用经验分享。无论你是开发人员还是对逆向工程感兴趣的爱好者，都能在《码头工人的一千零一夜》找到有价值的知识和见解。
配置中心系列文章
《【架构师视角系列】风控场景下的配置中心设计思考》 https://www.cnblogs.com/boycelee/p/18355942
《【架构师视角系列】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
一、什么是配置中心？
配置中心是集中管理和动态更新应用配置信息的服务，服务能够在不停机的情况下新增或修改配置信息，具有以下关键特点：
（1）集中管理。配置中心集中存储服务所需要的各类配置信息；
（2）动态变更。应用服务不需要重启就可以从配置中心动态获取到最新数据；
（3）通知机制。当服务配置发生变化时，配置中心可以提供通知机制，通知应用程序关心的配置发生变化。
能够提高系统的可维护性、灵活性和实时性。
二、传统配置有什么问题？
传统配置会使用本地静态文件作为存储介质。就存在这几个问题：
（1）动态修改。本地静态文件修改时必须重启应用，无法做到动态修改；
（2）统一管理。存储格式、存储地点都杂乱无章，无法对配置进行统一规范和约束；
（3）即时生效。配置完成后，需要多机器部署完成，修改配置才能够生效。无法做到及时通知、及时生效。
三、配置中心的场景
大体场景有如下这几种：
（1）系统相关。如线程池配置信息、缓存大小、连接池大小、熔断/限流阈值等；
（2）业务相关。如活动文案、推广活动、积分规则、价格策略等；
（3）开关相关。A/B Test、特性开关、推送开关等；
（4）安全相关。数据库连接信息、加密秘钥、账号密码等。
四、架构设计
（1）基础模型
（2）详细架构
架构图分为三层，分别是客户端层、网络层以及服务层。其中客户端层包括client模块、portal模块，网络层包括Load Balancer（Nginx）和Mata Server以及Eureka，服务层包括Config Service模块和Admin Service模块。
六、模块介绍
客户端层
Client
- 客户端负责从Config Service获取应用的配置信息；
- 监听配置变化。当配置发生更新时，Config Service会通知Client，并出发其进行配置刷新；
- 通过ip + port的方式远程调用Config Service，以获取配置数据。
Portal
- 管理平台，提供配置中心的管理功能，包括应用创建、查看、修改、发布以及回滚等功能
网络层
NginxLB
- Client、Portal通过域名的方式访问MetaServer，Nginx作为负载均衡器；
- Nginx将请求分发到每个Meta Server服务实例，结合Eureka可以动态地获取到注册中心注册的服务实例（Config Service、Admin Service）列表。
Meta Server
- Meta Server封装Eureka Client，通过Eureka Client获取Config Service和Admin Service的服务信息，Client与Portal不需要关心注册中心的服务发现问题；
- Client和Portal通过ip+port的方式访问Client Service 与 Admin Service
- Meta Server是逻辑概念与Config Service模块一起部署在同一实例中；
- Meta Service还提供其他注册中心的封装类，其中包括Consul、Nacos、Kubernetes等；
Eureka
- Eureka是用于服务注册与服务发现的注册中心，Config Sevice与Admin Service会定期向注册中心上报心跳；
- Eureka与Config Service部署在一起，简化部署和管理。
- 相对于Zookeeper其部署方式更便捷。
服务端层
Config Service
- 服务于Client模块；
- 提供获取配置的接口；
- 基于长轮询，提供配置更新接口；
Admin Service
- 服务于Admin模块；
- 提供配置管理接口；
- 提供修改、发布配置等接口。
七、思考
1、为什么NginxLB与Eureka一起使用？不使用Eureka是否可行？
（1）负载均衡（Nginx LB）。具有高可用和容错的特性，当Apollo配置中心节点出现故障时，负载均衡器可以将流量重新路由到其他可用的节点上，从而实现系统的稳定性。
（2）服务注册与发现（Eureka）。Eureka可以帮助配置中心实现动态的服务注册和发现。Config Service动态注册到Eureka中，而Client通过Eureka获取可用节点列表。从而实现动态获取配置中心节点变化。
（3）综合使用Nginx负载均衡和Eureka注册中心，可以提高配置中心的可用性和容错性。这种架构允许系统在动态环境中灵活地处理配置中心（Config Service）节点的变化，并且确保客户端（Client）始终能够访问到可用的的配置中心（Config Service）节点。
（4）不使用Eureka，只使用Nginx负载均衡是可行的。这种情况下配置中心节点（Config Service）由Nginx进行负载均衡和请求分发，不需要Eureka进行服务注册与服务发现。优点是架构简单，缺点是Nginx虽然可以感知到节点不可用，但其并不具备动态节点管理的能力，当新的节点加入时，Eureka能够及时发现且自动地处理，而Nginx则需要人工干预。
2、Confg Service 、Admin Service以及Portal为什么作为独立应用单独部署？
（1）Confg Service和Admin Service独立部署，是从功能解耦上考虑，Confg Service服务于Client端负责处理配置相关逻辑，而Admin Service服务于Portal管理平台，提供接口给Portal进行使用。从产品迭代角度来分析Admin Service因为服务于Protal管理平台其迭代频率会高于Confg Service，分开独立部署能够提升开发灵活性以及降低发布风险。
（2）Admin Service和Portal独立部署，是为了环境隔离时，Protal能够调用不同Service提供的API接口，进行不同环境配置的统一管理。
最后
《码头工人的一千零一夜》是一位专注于技术干货分享的博主，追随博主的文章，你将深入了解业界最新的技术趋势，以及在Java开发和安全领域的实用经验分享。无论你是开发人员还是对逆向工程感兴趣的爱好者，都能在《码头工人的一千零一夜》找到有价值的知识和见解。
懂得不多，做得太少。欢迎批评、指正。
