先看下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进程中
一、服务端配置:
通过Apollo Portal(管理界面):
先创建一个用户(必须是超级管理员创建用户):
创建完成后就可以用新用户登录了;
新建一个项目:
部门的新建不能通过页面修改,只能通过数据库修改,通过修改organizations里面的值:
应用id:每个应用都需要有唯一的身份标识,我们认为应用身份是跟着代码走的,所以需要在代码中配置使用的;
应用名称:就是应用的名称,用于展示的;
应用负责人默认是应用管理员;
创建完项目后页面:
介绍这个页面之前我先介绍几个概念:
Apollo支持4个维度管理Key-Value格式的配置:
- application (应用)
- environment (环境)
- cluster (集群)
- namespace (命名空间)
application和environment应该不用介绍了,主要是介绍cluster集群和namespace,
-
cluster (集群)
- 一个应用下不同实例的分组,比如典型的可以按照数据中心分,把上海机房的应用实例分为一个集群,把北京机房的应用实例分为另一个集群。
- 对不同的cluster,同一个配置可以有不一样的值,如zookeeper地址。
- 集群默认是通过读取机器上的配置(server.properties中的idc属性)指定的,不过也支持运行时通过System Property指定
-
namespace (命名空间)
- 一个应用下不同配置的分组,可以简单地把namespace类比为文件,不同类型的配置存放在不同的文件中,