Apollo 接入规范+Demo

先看下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格式的配置：

1. application (应用)
2. environment (环境)
3. cluster (集群)
4. namespace (命名空间)

 application和environment应该不用介绍了，主要是介绍cluster集群和namespace，

• cluster (集群)

  • 一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。
  • 对不同的cluster，同一个配置可以有不一样的值，如zookeeper地址。
  • 集群默认是通过读取机器上的配置（server.properties中的idc属性）指定的，不过也支持运行时通过System Property指定

• namespace (命名空间)

  • 一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，