Apollo系列 -- 简介及工作原理

首先这里说的Apollo不是百度的Apollo无人驾驶哈~ 而是携程框架部门研发的Apollo配置中心~ 参考：Apollo配置中心设计

Apollo简介

• Apollo是携程框架部门研发的分布式配置中心
• 集中化管理应用的不同环境和不同集群的配置
• 配置修改后能够实时推送到应用端
• 具备规范的权限、流程治理等特性

Apollo组成部分

Apollo包括服务端和客户端

• Config Service
  • 提供配置获取接口
  • 提供配置更新推送接口（基于Http long polling）
    • 服务端使用Spring DeferredResult实现异步化，从而大大增加长连接数量
    • 目前使用的tomcat embed默认配置是最多10000个连接（可以调整），使用了4C8G的虚拟机实测可以支撑10000个连接，所以满足需求（一个应用实例只会发起一个长连接）。
  • 接口服务对象为Apollo客户端
• Admin Service
  • 提供配置管理接口
  • 提供配置修改、发布等接口
  • 接口服务对象为Portal
• Meta Server
  • Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port）
  • Client通过域名访问Meta Server获取Config Service服务列表（IP+Port）
  • Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
  • 增设一个Meta Server的角色主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件
  • Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致
• Portal
  • 提供Web界面供用户管理配置
  • 通过Meta Server获取Admin Service服务列表（IP+Port），通过IP+Port访问服务
  • 在Portal侧做load balance、错误重试
• Apollo Client
  • Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能
  • 通过Meta Server获取Config Service服务列表（IP+Port），通过IP+Port访问服务
  • 在Client侧做load balance、错误重试

　服务端：基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器
java客户端：不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持

Apollo特性

• 统一管理不同环境、不同集群的配置
• 配置修改实时生效（热发布）
• 版本发布管理--所有配置都有版本概念，便于配置的回滚
• 灰度发布--点了发布后只对部分应用实例生效，等观察一段时没问题后再推送给所有应用实例
• 权限管理、发布审核、操作审计
  • 权限管理--有完善的权限管理
  • 发布审核--配置管理分了编辑发布两个环节，减少人为错误
  • 操作审计--所有操作都有审计日志，可以方便追踪问题
• 客户端配置信息监控--可以在界面上方便看到配置在被那些实例使用
• 提供java和.net原生客户端，方便应用集成
• 提供了http接口，非java和.net应用也可以方便地使用
• 提供开放平套API
• 部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来

执行流程

• 用户在配置中心对配置进行修改并发布
• 配置中心通知Apollo客户端有配置更新
• Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

工作原理

上图简要描述了Apollo的总体设计，从下往上看：

• Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
• Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
• Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
• 在Eureka之上我们架了一层Meta Server用于封装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进程中