Apollo 架构设计

Apollo 架构设计

---

概要介绍

• 英文名称：Apollo¹
• 中文名称：阿波罗
• 组件功能：配置中心
  • 提供不同环境、不同集群的配置中心管理
  • 提供可视化操作界面管理不同环境的配置
  • 提供用户权限、操作流程管理功能
• 引入原因：
  • 解决不同环境需要相同KEY值需要配置不同VALUE
    • 举例：jdbc.url 不同环境需要配置不同的数据库部署地址及用户密码
  • 解决配置变更后的生效时间长的问题
    • 举例：配置文件修改后需要重新部署将新的配置信息生成新的WAR包并发布
• 项目环境²：

英文简写	英文全称	中文释义	环境用途
DEV	Development environment	开发环境	用于开发者调试使用
FAT	Feature Acceptance Test environment	功能验收测试环境	用于软件测试者测试使用
UAT	User Acceptance Test environment	用户验收测试环境	用于生产环境下的软件测试者测试使用
PRO	Production environment	生产环境	用于对外提供服务

---

配置中心

• Autoconfig

  • 出处：阿里
  • 使用：
    • 项目代码
      • maven-autoconfig 引入插件
      • applicaiton.properties.vm 配置模板
      • application.properties 配置内容
      • auto-config.xml 默认配置
    • 部署环境
      • antx.properties

        • 不同应用部署环境都有一个 antx.properties

        • 项目部署时自动将相关的新增配置信息写入到 antx.properties 中

        • 配置信息修改不同步到 antx.properties 中

          • 这样就可以实现不同环境同一个KEY值有不同的VALUE
          • 项目发布时通过CRT/XShell工具远程登录到服务器上，通过vi / vim 命令编辑antx.porperties修改配置信息为当前环境的配置信息

        • 项目构建时配置文件信息读取路径指向 antx.properties

          mvn clean install -U -Dmaven.test.skip -Dautoconfig.userProperties=antx.properties
          

  • 优势：解决了不同环境使用不同配置文件信息的问题
  • 劣势：配置文件信息变更时需要重新打包发布，就是需要重启服务器

• Apollo

  • 出处：携程
  • 使用：
    • 不同环境：Apollo 默认提供不同环境的配置，不同环境有不同的IP+PORT指向
    • 服务部署：在 tomcat/bin/catalina.sh 中通过配置不同环境的IP来识别应读取哪个环境的配置文件

      JAVA_OPTS="-Dapollo.meta=http://ip+port"
      

---

架构剖析¹

• 流程图解
  
• 核心微服务模块
  • ConfigService
    • 服务于 Apollo Client 端
      - 配置信息获取接口（被动） Client --> Meta Service --> Eureka --> ConfigService --> Config Data
      - 配置信息推送接口（主动）
    • 注册在 Eukera 上
      - 部署方式：集群部署
      - 部署数量：项目应用的不同环境分别部署一份
    • 读取数据库 config db
  • AdminService
    • 服务于 Apollo Portal 端（管理界面）
      • 配置管理接口
      • 配置修改发布接口
    • 注册在 Eukera 上
      • 同 ConfigService
      • AdminService ConfigService config-DB 不同环境分别部署一份
      • 启动后注册到 Eukera ，定期发送保活心跳
    • CRUD+发布 --> 数据库 config db
  • Client
    • 为应用获取配置，支持实时更新
    • 通过 Meta Service 获取 ConfigService 的服务列表
    • 使用客户端软辅在SLB（例如：Ribbon）方式路由到目标服务示例，进而调用ConfigService
    • Client和ConfigService保持长连接，通过一种推拉结合(push & pull)的模式，在实现配置实时更新的同时，保证配置更新不丢失
  • Portal
    • 配置管理界面
    • 通过 Meta Service 获取 AdminService 的服务列表
    • 使用客户端软负载SLB方式调用AdminService
    • 操作数据库 Portal DB
• 辅助微服务之间进行服务发现的模块
  • 服务发现是微服务架构的基础，在Apollo的微服务架构中，既采用Eureka注册中心式的服务发现，也采用NginxLB集中Proxy式的服务发现
  • Meta Service
    • Eureka的Proxy 将Eureka的服务发现接口以更简单明确的HTTP接口的形式暴露出来，方便Client/Protal通过简单的HTTPClient就可以查询到Config/AdminService的地址列表
    • 与 ConfigService 部署在一起
    • 引入原因：多语言环境下使用
  • Eukera 服务注册中心
    • 用于服务发现和注册
    • Config/AdminService注册实例并定期报心跳
    • 与 ConfigService 部署在一起
    • 注册原因： AdminService ConfigService 无状态集群方式部署，通过注册在 Eukera ,实现服务发现问题
    • 基于Eukera实现服务发现注册+客户端Ribbo配合实现软路由
  • NginxLB （Software Load Balancer)
    • 和域名系统配合，协助Portal访问MetaServer获取AdminService地址列表
    • 和域名系统配合，协助Client访问MetaServer获取ConfigService地址列表
    • 和域名系统配合，协助用户访问Portal进行配置管理
    • 引入原因：MetaServer 同事时无状态集群方式部署，服务发现，为MetaServer配置域名，指向NginxLB；NginxLB再对MetaServer进行负载均衡和流量转发。Client/Portal通过域名+NginxLB间接访问MetaServer集群。
• DB
  • Config DB
    • ConfigService 与 AdminService 共享数据库
    • 每个环境部署一份
    • 存储内容：不同环境的配置文件信息
  • Portal DB
    • 存储内容：用户权限、项目和配置的元数据
    • 部署一份

---

其他知识

• SLB³
• Ribbon⁴
• 心跳机制⁵

---

1. 微服务架构~携程Apollo配置中心架构剖析 ↩︎ ↩︎

2. 软件开发过程中常用的环境解释DEV FAT UAT PRO ↩︎

3. 负载均衡SLB ↩︎

4. Ribbon详解 ↩︎

5. 服务器心跳机制 ↩︎