配置中心Apollo入门

Apollo是携程开源配置中心,社区比较火,当前在生产中使用的用户量也非常大。用户侧的功能和使用,本文就不一一介绍了,这方面的文档比较多。这里结合最近在公司环境中的大规模部署,简要做一些概要总结,重点涉及一些分布式部署中可能遇到的问题。

软件架构

配置中心Apollo入门

我们先来对架构有一个总体的认识,上图是apollo的模块架构,接下来我们将对图上各模块做逐一功能职责的介绍。

各模块功能

  • ConfigService

    1. 提供配置获取接口
    2. 提供配置推送接口
    3. 服务于Apollo客户端
  • MetaServer

    1. Portal通过域名访问MetaServer获取AdminService的地址列表
    2. Client通过域名访问MetaServer获取ConfigService的地址列表
    3. 相当于一个Eureka Proxy
    4. 逻辑角色,和ConfigService住在一起部署
  • Eureka

    1. 用于服务发现和注册
    2. Config/AdminService注册实例并定期报心跳
    3. 和ConfigService住在一起部署
  • AdminService

    1. 提供配置管理接口
    2. 提供配置修改发布接口
    3. 服务于管理界面Portal
  • Portal

    1. 配置管理界面
    2. 通过MetaServer获取AdminService的服务列表
    3. 使用客户端软负载SLB方式调用AdminService
  • Nginx LB

    1. 和域名系统配合,协助Portal访问MetaServer获取AdminService地址列表
    2. 和域名系统配合,协助Client访问MetaServer获取ConfigService地址列表
    3. 和域名系统配合,协助用户访问Portal进行配置管理
  • Client

    1. 为应用获取配置,支持实时更新
    2. 通过MetaServer获取ConfigService的服务列表
    3. 使用客户端软负载SLB方式调用ConfigService

配置下发流程

为了突出关键内容,下面流程忽略掉了服务发现的步骤;结合架构图,请自行脑补各模块之间怎么基于DB中的内容来找到目标模块。

  1. 用户在Portal上修改配置,并发布;
  2. 基于配置所在的目标环境,Portal调用对应AdminService的接口来操作发布;
  3. AdminService发布配置后,发送ReleaseMessage到其关联的数据库
  4. ConfigService每秒扫描数据库,一旦发现存在新的消息记录,就通知到消息监听器,由消息监听器通知Client;
  5. Client与ConfigService之间是通过HTTP long-polling来实现长连接的;
  6. 作为一种补偿机制,Client还定期从ConfigService拉取最新配置(默认每5分钟拉取一次,可以自定义);

服务端

服务 端口
config server 8080
admim server 8090
portal server 8070

部署

准备工作

github上下载apollo对应的release包,主要包含三部分:

  • apollo-adminserver
  • apollo-configservice (包含ConfigServer、MetaServer和Eureka)
  • apollo-portal

除了这些jar包之外,还需要mysql数据库和负载均衡,用来向客户端和用户暴露统一的访问地址。

部署架构

下面是部署两套环境DEV、UAT(每套环境都有两个IDC)的一张架构图,具体如下:

配置中心Apollo入门

数据流

在前面的章节我们大概讲了配置发布的流程,这里重点结合负载均衡来讲一下(对理解配置有好处)。

portal-server配置

  • 首先,用户访问UI的请求通过LB-1进来被送到portal server上处理。因此,LB-1应该暴露8070端口,其upstream为多个portal-server的8070端口。
  • portal-server接收发布配置请求之后,需要找到配置所属环境的admin-server来将配置写入到数据库中,并向admin-server发送releaseMessage。为了便于找到各个环境对应的admin-server,portal-server需要去查找对应环境的meta-server,再通过meta-server来查询当前可用的admin-server。各环境与其对应meta-server地址的映射关系,需要我们手动写入到portal-server的配置文件中,具体见架构图。
  • 现在问题来了,假设我们在同一个环境中有多个idc,每个idc为了client不跨地域访问,都只将config-server和admin-server注册到本地域的meta-server上,那么,portal-server应该如何路由需要发送到admin-server的请求呢?答案是:随意!因为对于portal-server来讲,admin-server属于哪一个idc都没有关系,只要它能够正确的访问到该环境的数据库,portal-server就敢大胆的将活儿承包给这个老弟做。
  • 假设我们在lb-2上代理idc-1和idc-2的metadata-server地址,这样会有什么问题吗?举一个例子,如果meta-server-1是健康的,所以lb-2会将请求路由过来处理。但是meta-server-1上注册的所有admin-server都挂掉了,此时这个请求就必然面临超时的异常。但是,portal-server的作者为我们想到了这一点,进入源码查看,会发现portal-server每次都是直接找到可用的admin-server,而不是找到对应的meta-server就终止。

原文 

http://ljchen.net/2019/03/02/配置中心apollo入门/

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 配置中心Apollo入门

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址