分布式配置服务实践领会

前言

主要还是分享下单体架构和分布式架构 对于配置的理解和认识.以及在不同的思维下 如何看待配置开发和运维部署.作为微服务的入门视角.

配置方式

1. 针对于单体架构,配置文件 往往存放在本地目录.根据环境的不同选择不同的资源进行打包.
2. 针对于分布式架构,模块实例较多,无法做到 本地配置文件的统一的配置更新.运维成本较高.风险较大.往往需要通过远程 共用的配置中心服务以获取通用配置和配置更新.调用协议包括RPC(TCP)和HTTP等.典型应用如Zookeeper,百度的DisConf,淘宝的Diamond,Spring Cloud Config … 实现不同环境的配置获取和管理更新.甚至可以在不重启服务的情况下实时刷新.

配置分类

1. 通用配置:同一个模块不同实例上的 共享配置信息.
2. 个性配置:无法共用的配置�信息,并且这类配置往往是和服务器物理信息密切相关,比如IP,端口,路径等.

环境选择

1. 意义: 根据不同环境获取不同配置,对不同的资源和数据进行有效应用(或测试).
2. 分类:开发环境,测试环境,生产环境…

实践心得

1. 分布式应用开发,重度依赖于网络,即使在开发阶段,也需要 保证网络的可用性.
2. 对于通用配置(建议结合Git或其他版本管理系统)
   • 通用配置原则上需要全部在配置中心进行管理和获取.不可在本地存留.
   • 即使在开发阶段 也不可存有通用的本地配置.举个栗子:
     需要一个H2(一个java编写的嵌入式数据库,支持JDBC规范,拥有Embedded，Server和In-Memory模式),它的配置信息和配置方式也需要冲配置中心获取.
   • 如果开发阶段配置中心挂了:
     • 首要方案: 处理恢复 配置中心.
     • 其次方式: 选择Singleton方式 获取本地配置信息.
3. 对于个性配置

• 原则上尽量少.能通用就通用
• 配置基本上是更新不平凡.

4. 打包部署
   • 根据不同的环境资源进行打包部署.
   • 内容包含:

     • 执行脚本:命令尽量少,可包括本地 配置文件的获取路径

     • 执行文件

     • 依赖项目

     • 资源文件(主要指 配置资源)

       • 记录 配置中心的配置获取方式和Profile选择.
       • 记录 个性配置的配置内容.(原则上这类配置内容 应有运维人员统一管理.开发人员提供模板后,不做修改)

总结

分布式配置中心意义,在于 降低配置管理的运维成本,提高生产环境下的部署效率.最直接的表现为 配置文件的维护量减少,并且管理查看更直观.单体架构和分布式架构并不是无法跨越的鸿沟或排斥.但在思维方式上却不应该混淆.它也是OpsDev价值最初级的体现.