前言
主要还是分享下单体架构和分布式架构 对于配置的理解和认识.以及在不同的思维下 如何看待配置开发和运维部署.作为微服务的入门视角.
配置方式
- 针对于单体架构,配置文件 往往存放在本地目录.根据环境的不同选择不同的资源进行打包.
- 针对于分布式架构,模块实例较多,无法做到 本地配置文件的统一的配置更新.运维成本较高.风险较大.往往需要通过远程 共用的配置中心服务以获取通用配置和配置更新.调用协议包括RPC(TCP)和HTTP等.典型应用如Zookeeper,百度的DisConf,淘宝的Diamond,Spring Cloud Config … 实现不同环境的配置获取和管理更新.甚至可以在不重启服务的情况下实时刷新.
配置分类
- 通用配置:同一个模块不同实例上的 共享配置信息.
- 个性配置:无法共用的配置�信息,并且这类配置往往是和服务器物理信息密切相关,比如IP,端口,路径等.
环境选择
- 意义: 根据不同环境获取不同配置,对不同的资源和数据进行有效应用(或测试).
- 分类:开发环境,测试环境,生产环境…
实践心得
- 分布式应用开发,重度依赖于网络,即使在开发阶段,也需要 保证网络的可用性.
- 对于通用配置(建议结合Git或其他版本管理系统)
- 通用配置原则上需要全部在配置中心进行管理和获取.不可在本地存留.
- 即使在开发阶段 也不可存有通用的本地配置.举个栗子:
需要一个H2(一个java编写的嵌入式数据库,支持JDBC规范,拥有Embedded，Server和In-Memory模式),它的配置信息和配置方式也需要冲配置中心获取. - 如果开发阶段配置中心挂了:
- 首要方案: 处理恢复 配置中心.
- 其次方式: 选择Singleton方式 获取本地配置信息.
- 对于个性配置
- 原则上尽量少.能通用就通用
- 配置基本上是更新不平凡.
- 打包部署
- 根据不同的环境资源进行打包部署.
- 内容包含:
执行脚本:命令尽量少,可包括本地 配置文件的获取路径
执行文件
依赖项目
-
资源文件(主要指 配置资源)
- 记录 配置中心的配置获取方式和Profile选择.
- 记录 个性配置的配置内容.(原则上这类配置内容 应有运维人员统一管理.开发人员提供模板后,不做修改)
总结
分布式配置中心意义,在于 降低配置管理的运维成本,提高生产环境下的部署效率.最直接的表现为 配置文件的维护量减少,并且管理查看更直观.单体架构和分布式架构并不是无法跨越的鸿沟或排斥.但在思维方式上却不应该混淆.它也是OpsDev价值最初级的体现.
