Apollo基本使用

转自:配置中心 & Apollo基本使用

一、Apollo(配置中心)

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

Apollo服务端基于Spring Boot 和Spring Cloud开发,打包后可以直接运行,不需要额外部署Tomcat等应用容器。

Apollo客户端不依赖任何框架,能够运行于所有Java运行时环境,同时对Spring/Spring Boot 环境也有较好的支持。

二、Apollo特性

A、统一管理配置
Apollo提供了一个统一界面集中式管理不同的环境(environment)、不同的集群(cluster)、不同的命名空间(namespace)的配置。

同一份代码部署在不同的集群,可以有不同的配置,比如zk的地址。

通过命名空间(namespace)可以很方便的支持多个不同应用共享同一份配置,同时还允许应用对共享的配置进行覆盖。

B、配置修改实时生效(热发布)
用户在Apollo修改完配置并发布后,Apollo客户端能实时(1s)接收到最新的配置,并通知到应用程序。

C、版本发布管理
所有的配置发布都有版本概念,从而可以方便的支持配置的回滚。

D、客户端配置信息的监控
可以方便的看到配置在被哪些实例使用。

E、便于集成
支持Spring Placeholder,Annotation和Spring Boot 的ConfigurationProperties,方便应用使用。

三、配置中心解决的痛点

随着程序功能的日益复杂,程序的配置日益增多:各种功能的开关、参数的配置、服务器的地址……
对程序配置的期望值也越来越高:配置修改后实时生效。灰度发布,分环境、分集群管理配置,完善的权限、审核机制……

天猫相关,可独立启动的应用17个,涉及到的作业52个,接口8个,web平台1个。
每个应用维护着一份自己的配置文件,平均每个应用配置文件数为4个,其中大量的配置项是相同的。
比如:appKey、secretKey、sessionKey、tmall.openapi.url等等。

冗余配置带来的问题很多:

  • 一致性难以保证
  • 维护成本高
  • 不同环境之间容易误用

四、Apollo执行流程

在这里插入图片描述

  1. Apollo客户端和Apollo服务端保持长连接,从而能在第一时间获得配置更新的推送
  2. Apollo客户端会定时从Apollo服务端拉取应用的最新配置
    • fallback机制,防止推送机制失败导致配置不更新
    • Apollo客户端定时拉取上报本地版本,所以一般情况下,对于定时拉取的操作,服务端会返回304-Not Modified(?)
    • 拉取频率为5分钟一次,客户端可以指定
  3. Apollo客户端从Apollo服务端获取到应用的最新配置后,会保存在内存中
  4. 客户端会把从服务端获取到的配置在本地文件系统缓存一份
    • 在遇到服务不可用,或网络不通的时候,依然能从本地恢复配置
  5. 应用程序从Apollo客户端获取最新的配置,订阅配置更新通知。

五、Apollo的安全性和可用性分析

A、安全性
配置文件除了改变程序行为之外,可能还包含一些敏感信息,比如: 开放接口的tokenId、secretKey、数据库账号等
Apollo有一个默认的超级用户,可以在安装的时候初始化密码。
Apollo登录可以对接SSO,使用域账户登录。具体参考:Portal实现用户登录功能
Apollo在创建每个应用(映射到物理上的应用:转单、拉单)的时候,强制创建者指定一个owner,只有这个owner用户拥有该应用配置的编辑、发布权限。每个namespace(相当于.properties的概念)除了owner拥有全部权限,也可以给他人单独授权,这样就可以将配置项按照不同的安全级别划分到不同的namespace中,从而实现更小粒度的权限控制:比如db相关的namespace只有运维能编辑、发布。

B、可用性
配置中心作为基础服务,可用性要求非常高,下面描述了不同场景下Apollo的可用性:

1.某台config service下线,无影响,config service无状态,客户端重连其它config service。

2.所有config service下线,客户端无法读取最新配置,Portal无影响,客户端重启时,可以读取本地缓存配置文件。

3.某台admin service下线,无影响,Admin service无状态,Portal重连其它admin service。

4.所有admin service下线,客户端无影响,portal无法更新配置。

5.某台portal下线,无影响,Portal域名通过slb绑定多台服务器,重试后指向可用的服务器。

6.全部portal下线,客户端无影响,portal无法更新配置。

7.某个数据中心下线,无影响,多数据中心部署,数据完全同步,Meta Server/Portal域名通过slb自动切换到其它存活的数据中心。

按照官方的分析,只要部署时避免ConfigService(包含Meta Server)、AdminService、Protal Server单点。并且对各节点加上存活监控(以便短时间内dump节点的恢复),就能在保证高可用性。

在admin可以看到哪些实例(具体到IP)应用了哪些配置,上面原理中有体现,客户端也会定时上报自己的配置版本,避免了「推送失败,而服务端不知道」的情况。

六、web-admin端部署

Meta Server:这个一般是针对分布式存储集群而言的,metadata server存储的是实际的数据的位置(例如文件1在哪个机器上),又称元数据服务器。
ConfigService: 用于提供给client获取配置信息,以及配置更新后通知client的服务;ConfigService仅为client提供服务,且每个环境对应相应的ConfigService集群。
Admin Service:提供配置管理接口,提供配置修改发布接口,服务于管理界面Portal
Client:为应用获取配置,支持实时更新,通过MataServer获取ConfigService服务列表,使用客户端软负载SLB方式调用ConfigService
Portal:配置管理界面,通过MetaServer获取AdminService的服务列表,使用客户端负载SLB方式调用AdminService

七、应用端接入

7.1、具体的分部式部署指南如下:

分布式部署指南

apollo部署

7.2、Java程序集成Apollo

1)首先在pom.xml中引入apollo的引用。
2)告诉应用程序获取的是apollo配置的哪个项目的配置信息,即配好appid
appId
3)将具体的环境配置(比如dev,uat,pro)直接配在具体的服务器上,将环境配置信息与应用进行一个解耦。一个机器只要确定是用于生产环境它就几乎确定下来,不会变了。在服务器中的/opt/settings/server.properties文件中进行配置具体的环境。直接告诉应用程序我这台机器指向哪几台机器(具体的环境)。
4)通过代码调用apollo的配置信息,在resources/META-INF下填写配置信息,配置该项目对应的namespace即可使用
5)使用方法直接在变量上面加@Value(“${***}”)即可

八、工作原理

Apollo工作原理

1、Config Service 提供配置的读取、推送等功能,服务对象是Apollo客户端
2、Admin Service 提供配置的修改、发布等功能,服务对象是Apollo Portal (管理界面)
3、Config Service和 Admin Service都是多实例、无状态部署,所以需要将自己注册到Eureka中并保持心跳
4、在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
5、Client通过域名访问Meta Server获取Config Service服务列表(IP+Port),而后直接通过IP+Port访问服务,同时在Client侧会做load balance、错误重试
6、Portal 通过域名访问Meta Server获取Admin Service服务列表(IP+Port),而后直接通过IP+Port访问服务,同时在Portal侧会做load balance、错误重拾
7、为了简化部署。我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐