微服务系列（三）如何选择配置中心

微服务系列（三）如何选择配置中心

前面通过源码分析过了注册中心的实现，本文继续思考如何选择【微服务基础设施组件：配置中心】

对于注册中心，要对于项目特性，并结合注册中心的功能和实现特性来决定匹配度，那么对于配置中心，我们最应该了解的则是其配置信息的组织模式（决定系统的扩展性、可维护性等）、数据的存储方式和通信方式（决定性能、响应速度）、以及组件之间的契合度（笔者认为，如果两个组件之间是完全解耦的又不需要较多的额外开发就能配合工作的话，那么就认为两者的契合度很高）。

git上有很多开源的优秀的配置中心的实现，本文仅针对Apollo、Nacos以及Spring Cloud Config来介绍和分析，本质上spring cloud config应与前面两者划分开。

Apollo：呼声很高，功能很强大，较成熟

Nacos：合并了注册中心的功能，开发中

Spring Cloud Config：知名度高，使用者广泛

前言

由于配置中心的底层实现与注册中心的实现有很多相似之处，笔者将会减少源码分析的部分，重点分析配置中心可能面临的难题以及一些常用的解决方案。

Apollo

Apollo的README.md中有描述这样几个不错的特性（附上界面图）：

• 统一管理不同环境、不同集群的配置
  • Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
  • 同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等
  • 通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
• 配置修改实时生效（热发布）
  • 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。
• 版本发布管理
  • 所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。
• 灰度发布
  • 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。
• 权限管理、发布审核、操作审计
  • 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
  • 所有的操作都有审计日志，可以方便的追踪问题。
• 客户端配置信息监控
  • 可以方便的看到配置在被哪些实例使用
• 提供Java和.Net原生客户端
  • 提供了Java和.Net的原生客户端，方便应用集成
  • 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
  • 同时提供了Http接口，非Java和.Net应用也可以方便的使用
• 提供开放平台API
  • Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。
  • 不过Apollo出于通用性考虑，对配置的修改不会做过多限制，只要符合基本的格式就能够保存。
  • 在我们的调研中发现，对于有些使用方，它们的配置可能会有比较复杂的格式，如xml, json，需要对格式做校验。
  • 还有一些使用方如DAL，不仅有特定的格式，而且对输入的值也需要进行校验后方可保存，如检查数据库、用户名和密码是否匹配。
  • 对于这类应用，Apollo支持应用方通过开放接口在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制
• 部署简单
  • 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
  • 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
  • Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

可以看到，基本涵盖了大部分生产用的功能，是一个比较成熟的中间件，下面就继续了解它的API接入文档。

• 为了支持高可用，需要配置meta server
• 支持SPI扩展，用户可自定义寻址逻辑
• 可配置集群（集群的概念是某命名空间下的多个服务组成的集合）
• Java API接入方式，client模块提供了ConfigService接口提供服务，包括配置拉取、配置监听等功能
• 官方提供了Spring整合Apollo client的文档，但没有提供接入Spring Cloud的实现
• 仅支持xml、properties、xml文件格式的配置
• 提供迁徙方案

大致整理了一下，下面通过源码重点了解以下几个部分：

1. 配置meta server来支持的高可用是如何实现的，可能存在哪些问题
2. 配置的拉取是通过什么协议通信，配置监听又是如何实现的
3. Apollo client会对配置文件进行本地文件缓存，是如何缓存的呢
4. 权限控制采用了什么模式
5. 客户端配置信息监控是如何做到的
6. Apollo server端的配置信息是如何存储的

从官网推荐的文章上找到的一张Apollo架构图，好让我们初步的认识它

这张架构图可以简单回答问题1、4、6：

Config Service提供配置信息的管理，它的高可用依赖于Eureka集群和Meta Service，Meta Service起中转请求的作用，接收发现Config Service和Admin Service服务的请求，并向Eureka请求服务列表并返回给客户端。

运维相关的控制由Admin Service承担，它依赖于Config DB和Portal DB。

Config Service则依赖于Config DB，可以猜测到配置信息也是以表记录的形式存储在数据库中。

下面就用代码说话，完全理解Apollo的运行机制。

->apollo-configservice模块

有metaservice和configservice两个部分，在metaservice中发现configservice和adminservice服务发现的方式是http协议通信的方式。

@RestController
@RequestMapping("/services")
public class ServiceController {
   

  private final DiscoveryService discoveryService;

  private static Function<InstanceInfo, ServiceDTO> instanceInfoToServiceDTOFunc = instance -> {
   
    ServiceDTO service = new ServiceDTO();
    service.setAppName(instance.getAppName());
    service.setInstanceId(instance.getInstanceId());
    service.setHomepageUrl(instance.getHomePageUrl());
    return service;
  };

  public ServiceController(final DiscoveryService discoveryService) {
   
    this.discoveryService = discoveryService;
  }


  @RequestMapping("/meta")
  public List<ServiceDTO> getMetaService() {
   
    List<InstanceInfo> instances = discoveryService.getMetaServiceInstances();
    List<ServiceDTO> result = instances.stream().map(instanceInfoToServiceDTOFunc).collect(Collectors.toList());
    return result;
  }

  @RequestMapping("/config")
  public List<ServiceDTO> getConfigService(
      @RequestParam(value = "appId", defaultValue = "") String appId,
      @RequestParam(value = "ip", required = false) String clientIp) {
   
    List<InstanceInfo> instances = discoveryService.getConfigServiceInstances();
    List<ServiceDTO> result = instances.stream().map(instanceInfoToServiceDTOFunc).