Apollo之架构

角色

1. ConfigService：独立的无状态的微服务，用于Apollo Client进行配置获取。Apollo Client与ConfigService保持长连接，通过推拉结合（push和pull）的方式，在实现配置实时更新的同事，保证配置更新不丢失。

   • 提供配置获取接口
   • 提供配置推送接口
   • 服务于Apollo客户端

2. AdminService：独立的无状态的微服务，用于Portal做配置管理，Portal通过调用AdminService进行配置管理和发布。ConfigService和AdminService共享ConfigDB，每个环境都需要单独部署一套ConfigService、AdminService和对应的ConfigDB

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

3. Portal：用于存放用户权限、项目和配置的元数据信息。Portal只需要部署一份，可以管理多套环境，有一个独立的PortalDB数据库

   • 配置管理界面，主要用于人使用
   • 通过MetaServer获取AdminService的服务列表
   • 使用客户端软负载SLB方式调用AdminService

4. Apollo Client

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

隐藏角色

1. Eureka

   • 用于服务发现和注册
   • ConfigService和AdminService注册实例
   • 和ConfigService在一起部署

2. MetaServer

   • 主要用于跨语言客户端，封装Eureka接口，提供HTTP接口获取地址列表，相当于一个Eureka Proxy
     • Portal通过域名访问MetaServer获取AdminService的地址列表
   • Client通过域名访问MetaServer获取ConfigService的地址列表
   • 和ConfigService在一起部署

3. Nginx

   • 协助Portal访问MetaServer获取AdminService地址列表
     • 协助Client访问MetaServer获取ConfigService地址列表
   • 协助用户访问Portal进行配置管理

架构

1. 在不考虑服务发现的情况下，Apollo的架构可以简化为
   

2. 在实际生产环境，因为AdminService和ConfigService都是无状态的微服务，并且是集群部署的。这样就存在一个疑问，Portal如何找到AdminSerivce？Client如何找到ConfigService？ 为了解决服务发现问题，Apollo使用了Eureka组件（集群部署），AdminService和ConfigService启动后都会注册到Eureka集群中，Portal和Client可以从注册中心发现相应的服务地址
   

3. 因为Apollo要考虑多语言接入问题。但是Eureka(包括Ribbon软负载)原生仅支持Java客户端，如果要为多语言开发Eureka/Ribbon客户端，这个工作量很大，所以需要找到一种跨语言的解决方案。Apollo引入了一个新的角色Meta Server（相当于是Eureka Proxy），将Eureka的服务发现接口进行封装，以新的HTTP接口方式暴露给外部。这样不同语言的Client就可以通过HTTP接口直接查询到AdminService和ConfigService的地址了。Meta Server也是一个无状态的微服务，一般不会直接访问Meta Server，而是在前面加一层负载均衡（比如Nginx）。Portal一般也是通过负载均衡访问（单机部署也没问题，毕竟宕机只影响后台操作）
   

4. 为了简化部署，实际打包是将ConfigService、Eureka、Meta Server打成一个包，部署在一个JVM内