saltsack自动化配置day01：对微服务配置中心的理解

目录

• 微服务专栏地址
• 目录
• 1. 简介
• 2. 微服务配置中心是什么
• 3. 为什么需要微服务配置中心
• 4. 微服务配置中心实现技术
  • 4.1 网罗的实现技术
  • 4.2 Apollo分布式配置中心
    • 4.2.1 基础模型
    • 4.2.2 总体设计
  • 4.3 Spring Cloud config
    • 4.3.1 基础流程
    • 4.3.2 配置实时刷新
• 5. 技术如何选型

 

1. 简介

通过以下几个问题理解微服务中的集中配置中心 
1. 微服务配置中心是什么 
2. 为什么需要微服务配置中心 
3. 微服务配置中心实现技术 
4. 技术如何选型

2. 微服务配置中心是什么

　　集中式配置是将应用系统中对配置信息的管理作为一个新的应用功能模块，区别与传统的配置信息分散到系统各个角落方式，进行集中统一管理，并且提供额外功能。尤其是在微服务架构中，是不可或缺组件，甚至是必要组件之一。

3. 为什么需要微服务配置中心

　　在微服务体系中，服务的数量以及配置信息的日益增多，比如各种服务器参数配置、各种数据库访问参数配置、各种环境下配置信息的不同、配置信息修改之后实时生效等等，传统的配置文件方式或者将配置信息存放于数据库中的方式已无法满足开发人员对配置管理的要求，如：

• 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏
• 时效性：修改配置，需要重启服务才能生效
• 局限性：无法支持动态调整：例如日志开关、功能开关

4. 微服务配置中心实现技术

对微服务的几种成熟或者流行的集中式配置实现技术做个简要对比，重点理解一下apollo配置中心与SpringCloudConfig。

4.1 网罗的实现技术

• Apollo（阿波罗）：是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
• XDiamond：全局配置中心，存储应用的配置项，解决配置混乱分散的问题。名字来源于淘宝的开源项目diamond，前面加上一个字母X以示区别。
• Qconf： 奇虎 360 内部分布式配置管理工具。 用来替代传统的配置文件，使得配置信息和程序代码分离，同时配置变化能够实时同步到客户端，而且保证用户高效读取配置，这使的工程师从琐碎的配置修改、代码提交、配置上线流程中解放出来，极大地简化了配置管理工作。
• Disconf：百度的分布式配置管理平台，专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」
• SpringCloudConfig：为分布式系统中的外部配置提供服务器和客户端支持。

4.2 Apollo分布式配置中心

目前仅对其基础模型以及总体进行理解学习，更多关于Apollo的信息请点击这里查阅其官方文档

4.2.1 基础模型

1. 用户在配置中心对配置进行修改并发布
2. 配置中心通知Apollo客户端有配置更新
3. Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用 
   

4.2.2 总体设计

上图简要描述了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进程中

4.3 Spring Cloud config

这里简单理解基础流程以及实时刷新原理，后续demo以及代码中会结合深入进行理解、使用

4.3.1 基础流程

4.3.2 配置实时刷新

• 与git仓库结合使用时，使用git的web hook监控git仓库中配置信息的变更，一旦有变更，则推送给ConfigServer，进而通过Spring Cloud Bus实现实时更新

5. 技术如何选型

理解需求、技术特点是技术选型的首要任务

目前暂未对其他几个分布式配置中心做深入的了解，但是仍首选Apollo，个人理由如下：

• 配置集中管理：分布式配置中心最基础的要求，满足
• 配置实效性：配置的修改实时生效要求，满足
• 安全性：应用和配置的管理具有完善的权限管理机制，并且新增编辑和发布环节，尽量减少了人工误操作发生的概率，所有的操作都有审计日志，方便追踪，满足
• 配置修改简单：提供的图形化界面形式的配置管理，满足
• 部署简单：依赖非常少，只需要基础的mysql以及java运行环境即可，也提供了对应的一键安装脚本，满足
• 开源：源码的重要性不言而喻，无论是解决问题、扩展新功能、或者后期代替官方渠道进而形成满足自身特定需求的版本，满足

官方理由： 

　　正是基于配置的特殊性，所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台，目前提供了以下的特性：

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