APOllO服务器性能,动态配置中心apollo介绍

一.背景

随着技术部dubbo服务的使用，应用和机器数量急剧增长，程序配置也愈加繁杂：各种功能的开关、参数的配置、服务器的地址等等。同时，我们对程序配置的期望值也越来越高：配置修改后实时生效，灰度发布，分环境、分集群管理，完善的权限、审核机制等等。

在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足我们对配置管理的需求。

动态配置中心的意义：随时对程序发号施令

于是我们要采用配置中心去处理上述问题。通过配置中心，我们可以方便地管理微服务在不同环境中的配置，从而可以在运行时动态调整服务行为，真正实现配置即『控制』的目标。

1.一系列的背景，我们需要动态配置。

2.动态配置需要治理。

静态配置VS动态配置中心：

静态配置只能在项目重启的时候配置，没有实时性，同时增加了运维成本，同时增加可用性风险。

动态配置不用重启项目，实时配置生效，没有运维成本，可用性不受影响。

数据库配置VS动态配置中心

数据库配置造成数据库访问很高，数据库挂了就不可用，新增属性要开发页面数据库等不灵活，没有灰度，历史版本管理，分类管理等。

动态配置在数据库，本地硬盘，内存都保存，保证了可用性。属性改变了才会访问数据库，数据库的访问量不高。提供配置后即生效，不需要额外的开发。

提供灰度，历史版本，分类管理等功能。

二.apollo介绍：

1.基础模型：

Apollo 的基础模型：

image.png

用户在配置中心对配置进行修改并发布

配置中心通知 Apollo 客户端有配置更新

Apollo 客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

[图片上传失败...(image-15d0c-1556444319516)]

2.治理能力

1)统一管理不同环境、不同集群的配置。

2)支持灰度发布。

3)支持已发布的配置回滚。

4)完善的权限管理、操作审计日志。

Apollo 配置中心的管理界面如下图所示。

image.png

3.可用性

配置中心控制了整个微服务的运行时的行为，这样它的可用性就要求很高。

1)客户端高可用:

image.png

客户端和服务端保持了一个长连接，从而能第一时间获得apollo服务端配置更新的推送。

客户端还会定时从 Apollo 配置中心服务端拉取应用的最新配置；

这是一个 fallback 机制(补偿机制)，为了防止推送机制失效导致配置不更新；

客户端定时拉取会上报本地版本，所以一般情况下(配置没有变化)，对于定时拉取的操作，服务端都会返回 304 - Not Modified。

客户端从 Apollo 配置中心服务端获取到应用的最新配置后，会保存在内存中，所以我们的应用程序来获取配置的时候其实始终是从内存中获取的；

客户端还会把从服务端获取到的配置在本地文件系统缓存一份；

这主要是为了容灾，假设应用程序重启的时候，恰好远端服务全挂了，或者网络有故障，应用程序依然能从本地恢复配置。

通过这种推拉结合的机制，以及内存和本地文件双缓存的方式，有效地保证了客户端的可用性。

2)服务端高可用:

image.png

首先最下面是一个 DB，我们的配置是放在 DB 里的，然后在 DB 之上有两个服务：Config Service 和 Admin Service；

Config Service 提供配置的读取、推送等功能，服务对象是 Apollo 客户端；

Admin Service 提供配置的修改、发布等功能，服务对象是 Apollo Portal(管理界面)；

Config Service 和 Admin Service 都是多实例、无状态部署，所以需要将自己注册到 Eureka 中并保持心跳；

在 Eureka 之上我们架了一层 Meta Server 用于封装 Eureka 的服务发现接口，主要是为了让客户端和 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 进程中；

通过上述的设计，可以看到整个服务端是无单点，有效地保证了服务端的可用性。

4.实时性：

我们希望我们的配置能够迅速触达应用。

image.png

5.适用场景

1)开关

1.发布开关:用于发布过程中

有些新功能依赖于其它系统的新接口，而其它系统的发布周期未必和自己的系统一致，可以加个发布开关，默认把该功能关闭，等依赖系统上线后再打开；

有些新功能有较大风险，可以加个发布开关，上线后一旦有问题可以迅速关闭。

**注意：一旦功能稳定后需要及时清除**发布开关**代码。**

2.灰度开关

A/B 测试：针对特定用户应用新的推荐算法；针对特定百分比的用户使用新的下单流程

白名单：可以事先发到生产环境，只对内部用户打开，测试没问题后按时对全部用户开放

注意：一旦功能稳定后需要及时清除灰度开关代码。

3.运维开关：运维开关通常用于提升系统稳定性

大促前可以把一些非关键功能关闭来提升系统容量；当系统出现问题时可以关闭非关键功能来保证核心功能正常工作。

注意：运维开关可能会长期存在，而且一般会涉及多个系统，所以需要提前规划

2)服务治理

1.黑白名单

对于一些关键服务，哪怕是在内网环境中一般也会对调用方有所限制，比如：

有敏感信息的服务可以通过配置白名单来限制，只有某些应用或 IP 才能调用

某个调用方代码有问题导致超大量调用，对服务稳定性产生了影响，可以通过配置黑名单来暂时屏蔽这个调用方或 IP

一般的做法是在 RPC 框架层添加校验逻辑，结合配置中心的动态推送能力来实现动态调整黑白名单配置。

3)数据库迁移

数据库的迁移也是挺普遍的，比如：原来使用的 SQL Server，现在需要迁移到 MySQL，(同时因为系统整合造成的mysql数据库之间的数据迁移也适用)这种情况就可以结合配置中心来实现平滑迁移：

单写 SQL Server，100% 读 SQL Server；

初始化 MySQL；

双写 SQL Server 和 MySQL，100% 读 SQL Server；

线下校验、补齐 MySQL 数据；

双写 SQL Server 和 MySQL，90% 读 SQL Server，10% 读 MySQL；

双写 SQL Server 和 MySQL，100% 读 MySQL；

单写 MySQL，100% 读 MySQL；

切换完成。

image.png

上述的读写开关和比例配置都可以通过配置中心实现动态调整。

4)动态日志级别

服务运行过程中，经常会遇到需要通过日志来排查定位问题的情况，然而这里却有个两难：

如果日志级别很高(如：ERROR)，可能对排查问题也不会有太大帮助

如果日志级别很低(如：DEBUG)，日常运行会带来非常大的日志量，造成系统性能下降

为了兼顾性能和排查问题，我们可以借助于日志组件和配置中心实现日志级别动态调整。

5)动态数据源

数据库是应用运行过程中的一个非常重要的资源，承担了非常重要的角色。

在运行过程中，我们会遇到各种不同的场景需要让应用程序切换数据库连接，比如：数据库维护、数据库宕机主从切换等。