Apollo系列之架构设计（一）

原创文章，转载请标注。https:https://www.cnblogs.com/boycelee/p/17967590

一、什么是配置中心？
二、传统配置有什么问题？
三、配置中心的场景
四、架构设计
- （1）基础模型
- （2）详细架构
六、模块介绍
七、思考
- - 1、为什么NginxLB与Eureka一起使用？不使用Eureka是否可行？
  - 2、Confg Service 、Admin Service以及Portal为什么作为独立应用单独部署？
最后

一、什么是配置中心？

配置中心是集中管理和动态更新应用配置信息的服务，服务能够在不停机的情况下新增或修改配置信息，具有以下关键特点：

（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接口，进行不同环境配置的统一管理。

最后

懂得不多，做得太少。欢迎批评、指正。