为什么要有分布式配置中心？
微服务架构下，服务的数量视项目的规模大小而定，但数量肯定最少有十几二十个，这些微服务有时候共用一些配置，修改一个配置，这诸多服务都要跟着一起改。任务繁多，而且容易出错。
分布式分配置中心将多个服务的配置集中在一处进行管理，统一修改，实时生效，节约时间的同时还降低出错率。
Apollo简介
关于Apollo的简介，人家自己官网的介绍就是最权威的：
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。
Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。
安装部署指南
Apollo基础模型
该图描述了Apollo的基础模型，其含义：
1.用户在配置中心对配置项进行修改并发布；
2.配置中心通知Apollo客户端有配置更新；
3.Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用。
Apollo核心模块
先来看一张Apollo官方给出的架构图：
有点微服务架构知识就差不多能从这个图上提取出几个核心模块：
· Config Service
· Admin Service
· Eureka集群
· Meta Server
· Client
· Portal
把这几个模块摘出来之后，我们来简单分析一下其架构模型：
· Eureka 是微服务注册中心，Config Service 和 Admin Service 向 Eureka 注册服务。
· Client 通过 Meta Server 从 Eureka 获取Config Service服务列表。
· Portal 通过 Meta Server 从注册中心获取 Admin Service 服务列表。
· Client 和 Portal 侧都会通过 Software Load Balancer 做负载均衡。
上面简单分析是从这个架构图出发做的简要分析，下面我们再来看一下，各个模块的职能是什么。
Config Service
Config Service的服务对象为Apoll客户端，Apollo客户端从Config Service提供的接口获取需要的配置项；
当配置项更新后，Config Service负责推送消息通知给Apollo客户端。
TIP：
· Config Service推送消息采用异步的方式（Spring DeferredResult），从而大大增加长连接数量。
· 目前使用的内置tomcat默认配置是最多10000个连接（可以调整），使用了4C8G的虚拟机实测可以支撑10000个连接，所以满足需求（一个应用实例只会发起一个长连接）。
Admin Service
Admin Service提供了对配置进行管理的接口，包括 修改、发布 等接口，其服务对象是Portal 。
Meta Server
Meta Server相当于一个Eureka Proxy：
· Portal 通过域名访问Meta Server 获取 Admin Service 的地址列表。
· Client 通过域名访问Meta Server 获取Config Service 的地址列表。
Meta Server 和 Config Service 部署在一个JVM中。
Eureka
Eureka 是 Spring Cloud 的重要组件，负责服务的注册发现。
Config Service 和 Admin Service 会向 Eureka 注册服务，并保持心跳。
Eureka 也是和 Config Service 部署在同一个JVM中的。
Portal
通过 Portal 可以对配置进行可视化管理。
· 通过Meta Server获取Admin Service服务列表（IP+Port），通过IP+Port访问服务。
· 在Portal侧做load balance、错误重试。
Client
Client 是Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能。
· 通过Meta Server获取Config Service服务列表（IP+Port），通过IP+Port访问服务。
· 在Client侧做load balance、错误重试。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
