【架构师视角系列】Apollo配置中心之架构设计(一)

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

声明

原创文章,转载请标注。https://www.cnblogs.com/boycelee/p/17967590
《码头工人的一千零一夜》是一位专注于技术干货分享的博主,追随博主的文章,你将深入了解业界最新的技术趋势,以及在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

一、什么是配置中心?

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

(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开发和安全领域的实用经验分享。无论你是开发人员还是对逆向工程感兴趣的爱好者,都能在《码头工人的一千零一夜》找到有价值的知识和见解。
懂得不多,做得太少。欢迎批评、指正。

posted @ 2024-01-16 14:30  码头工人  阅读(361)  评论(0编辑  收藏  举报