apollo在项目的使用

Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。

功能:

  • 统一管理不同环境、不同集群的配置,以命名空间namespace为最小粒度进行配置,一个服务引入了这个命名空间,即使用了该命名空间的配置。
  • 配置修改实时生效
  • 版本发布管理
  • 灰度发布
  • 权限管理、发布审核、操作审计
  • 客户端配置信息监控

使用:

  • 服务端的配置:

    • 新建appId,appId可以理解为是一套应用。在appId新建namespace添加配置内容。Namespace可以理解为是配置的集合,原先一个yml文件存放配置,现在可以通过某个环境 ,某个appId下的namespace引入。
  • 客户端的使用:

    • 引入maven包并在启动类加入@EnableApollo即可,通过meta.server,appId和namespace找到所需的配置。可以理解为在apollo的配置就在配置文件里。通过@Value,@ConfigurationProperties引入的变量不受影响,对代码的入侵比较小。
    • 监听配置的变化,不同的namespace
  • 在项目的使用:

    • 把配置信息放入apollo。直接的做法是每个服务使用一个namespace,但是经过梳理发现,有些配置是多个服务共同使用的。
    • 服务的配置进行分类:

      • 通用:Log,eureka,feign调用相关的
      • 某些服务公用:database(openapi monitor) redis(card openapi double) kafka activemq ElasticSearch
      • 各自的服务拥有单独的namespace

经过分类后,如果要修改数据库地址,redis地址,或者新增一个中间件的地址,只用新增namespace,在配置文件引入/修改该namespace即可。
如果想更改某个服务的配置,在相应的namespace下修改,并重启docker服务。可以看到发布历史,有哪些实例在使用。
项目是用docker部署的,原先一部分配置在服务里,一部分配置在docker-compose里,改造后尽可能所有的配置都放在apollo里,apollo的配置放在docker-compose.yml里,docker-compose.yml可以引入公共的配置文件env_file,真正的apollo配置存放文件,包括apollo.meta,app.id,apollo.cacheDir,不用再通过profile.active区分。一些无法通过apollo配置的放在服务的配置或docker的配置中。理论上能当在服务的配置文件里的都能放在apollo里。
每个服务只需一个配置文件,甚至不用配置文件。为了本地开发的方便,在本地放置了sit环境的配置。
通过apollo.meta区分不同的环境,apollo.meta变量通过docker-compose文件的公共配置env_file引入

需要注意的:

  • 配置的备份
  • 假设两个人对同一个服务进行开发,需要修改配置
  • Application里的配置会实时生效,自定义的namespace不会。
  • 开关,限流额度,路径
  • 对于日志级别,database等需要更新bean的,需要写代码

Namespace的类型:

  • 私有:namespace从属于appId,只有配置了该appId才可访问
  • 公有:只要连上了apollo就能使用,属于所有应用,全局唯一
  • 关联:属性是私有的,可以理解为在继承公有属性的基础上,可对公有属性进行修改

其他的功能:

  • 密钥管理,保护配置不被其他应用获取
  • 权限分配:以namespace为粒度分配修改,发布,查看的权限
  • 添加集群
  • 配置覆盖,前面的会覆盖后面的,尽可能不要覆盖,保证配置的唯一性

架构:
apollo在项目的使用_第1张图片
从逻辑上来说比较清晰,将配置的编辑/发布与客户端获取配置分开,用两个服务实现
Portal通过调用admin service接口修改配置
Client通过config service接口获取配置
为了保证高可用,添加了一层eureka,client和portal通过eureka调用接口服务。
为了使不同语言的client可通过http接口即可获取admin service和config service的信息,eureka上搭建Meta service,用来封装服务发现的细节,不用关心背后的注册中心和服务发现组件(用于不同语言的服务注册到eureka上)。

完整架构如下:
apollo在项目的使用_第2张图片
主要模块:

  • Config Service:配置的读取、推送等,服务对象是Apollo客户端
  • Admin Service:配置的修改、发布等,服务对象是Apollo Portal(管理界面)
  • Config Service和Admin Service都是多实例、无状态部署,所以需要将自己注册到Eureka中并保持心跳
  • Meta Server:在Eureka之上搭建,用于封装Eureka的服务发现接口:

    • Client通过域名访问Meta Server获取Config Service服务列表(IP+Port),而后直接通过IP+Port访问服务,同时在Client侧会做load balance、错误重试
    • Portal通过域名访问Meta Server获取Admin Service服务列表(IP+Port),而后直接通过IP+Port访问服务,同时在Portal侧会做load balance、错误重试
  • 为了简化部署,实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

服务端设计:
apollo在项目的使用_第3张图片
Admin service发布了配置修改的事件,所有config service收到消息并通知客户端修改配置。
有两个值得去探索的点:

  • Admin service发布事件的方式:可以用中间件redis,activemq实现。这里为了减少外部组件的依赖,通过数据库实现。

apollo在项目的使用_第4张图片
具体的做法是Admin发布一条配置后,这个配置肯定属于某个namespace,在ReleaseMessage表插入一条记录AppId+Cluster+Namespace,config service有一个线程每秒扫描ReleaseMessage表,如果有新的消息记录,就通知客户端更新配置。所以配置如果有更新,一般一秒内就可通知到客户端。

  • Config service通知客户端的方式:客户端发起获取配置的请求,config service用defferResult将请求挂起,如果60秒内没有感兴趣的namespace配置发生变化,返回304,否则立即返回变化后的配置。使用defferResult可以提高请求的并发量

客户端设计:
apollo在项目的使用_第5张图片

  • 客户端和服务端保持了一个长连接,从而能第一时间获得配置更新的推送。(通过Http Long Polling实现)
  • 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。

    • 这是一个fallback机制,为了防止推送机制失效导致配置不更新
    • 客户端定时拉取会上报本地版本,所以一般情况下,对于定时拉取的操作,服务端都会返回304 - Not Modified
    • 定时频率默认为每5分钟拉取一次,客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖,单位为分钟。
  • 客户端从Apollo配置中心服务端获取到应用的最新配置后,会保存在内存中
  • 客户端会把从服务端获取到的配置在本地文件系统缓存一份

    • 在遇到服务不可用,或网络不通的时候,依然能从本地恢复配置
  • 应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知
  • 测试环境下多环境部署SIT,QA,UAT,用一套画面管理不同的环境:

apollo在项目的使用_第6张图片

与spring的集成原理
Spring的ApplicationContext会包含一个Environment,在服务启动的时候把参数注入即可。

你可能感兴趣的