一篇文章浅谈Apollo底层及原理

前文提要

每个微服务内部都有一块进行读取，如果配置变更了，先要更新项目，再把项目重新上传，或者登陆远程服务器更改配置文件，但是整个jar包（配置）上传，整个项目都需要重启。而配置的更改，我们只需要改几个字符就可以了。

但是如果我们项目引入了配置中心服务器就非常方便了，配置中心客户端们连接配置中心。在配置中心，将轻量级的配置推送给服务器，进行软件的热部署，不需要重启，就可以进行项目的配置变更。重量级配置，比如数据库的配置，推送过去，重启微服务，一般都是秒级的，微服务非常快，方便将我们的配置进行变更，不容易改错。

常见的配置中心对比

SpringConfig：最早出现的单纯的配置中心，不支持推送，更新配置。有一个接口，每个服务都要掉用一下，引入MQ，发一条消息，更新配置

Nacos、Consul：可基于Key Value做一些简单的配置，这两个只作为基本的配置中心使用

Disconf：

Apollo（阿波罗）：支持很多功能，配置审计、历史记录，上级审核完成才能发布，回滚，灰度发布 （携程开发的产品）

Apollo原理图

Apollo会推送、拉取两种方式，推拉结合，改完配置，马上把最新的配置更新给你，然后客户端每隔一分钟会把配置更新一下

Apollo的架构图

管理平台

模块描述

1.最左上角蓝色的Client是Java客户端，需要动态更新配置，而Meta不一定是Java写的，可以通过http请求的方式，获取最新地址

2.PortalDB（管理信息）和Portal（界面）是Portal门户

3.管理平台界面可以理解为Portal，界面

4.ConfigDB

5.ConfigService

6.AdminService高可用要多个，注册到Eureka上，并且兼容各种跨域语言，对Eureka做了封装代理，通过http代理就可以获得到了。可以通过nginx的反向代理做负载均衡

其它

所有的操作，都能在这里操作，这里就叫门户，如添加、修改、删除配置。在项目启动的时候，通过MetaServer获取Config的地址，拉的时候建立一个长链接，就可以推送了。一个Config支持一万个微服务长链接，AdminServer主要提供管理接口

Portal有个专门的数据库，配置环境，都在Portal库里面，但是用户配置不在PortalDB库里面，有个专门的库ConfigDB。

区别：PortalDB主要配置环境，比如dev、uat环境

            ConfigDB真正的配置（配置库），比如项目中url

推送

拉取顺序：ConfigService从ConfigDB中拉取，返回给Client

但是Portal是如何知道ConfigService和AdminService地址是啥呢？

首先添加个注册中心，Eureka portal，先通过Eureka获取ConfigService和AdminService地址，将最新的配置拉过来，或者推送过去，并且做一个负载均衡。

众所周知，Apollo服务的不止可以是Java项目，也可服务于.net配置中心，C#配置中心，但是他们连接Eureka非常复杂，所以就抽出个MetaServer，相当于一个代理，代理提供http接口，通过http接口访问的方式，可以获取ConfigService或者AdminService的注册地址。

Apollo可以用app.id来区分应用号，一个阿波罗可以配置多个项目。一个包打天下，发生产，可以说生产环境的配置，发测试，可以是测试环境的配置。配置文件在宿主机上进行实现。同步配置、比较配置、配置审计、灰度发布。现在很多情况都可以结合docker实现秒级重启。

灰度发布：一个服务器，一个集群，5-6台服务器，我们只在一台服务器上更新，然后更新其他的，可以回滚到任何版本。