集群信息管理，架构设计中最容易遗漏的一环

准备系统性介绍“技术体系规划”了，这是第一篇。

监控平台，服务治理，调用链跟踪，数据收集中心，自动化运维，自动化测试… 不少要讲，却没想好从哪里入手。

讲Z平台，可能须要提早介绍Y服务；讲Y服务，可能须要提早介绍X知识。

思来想去，准备从技术体系里，最容易被遗漏，很是基础，却又很是重要的“集群信息管理”开始介绍。

因为基础，可能部分同窗会以为简单；因为你们所在公司处于不一样阶段，因此在实现上会介绍不一样阶段的公司应该如何来实现。

仍是一如既往的按照“架构师之路”的思路：

• 是什么
• 什么场景，为何会用到，存在什么问题
• 常见方案及痛点
• 不一样阶段公司，不一样实现方案
  但愿大伙有收获。

1、啥是集群？

互联网典型分层架构以下：

• web-server层
• service层
• db层与cache层

为了保证高可用，每个站点、服务、数据库、缓存都会冗余多个实例，组成一个分布式的系统，集群则是一个分布式的物理形态。

额，好拗口，通俗的说，集群就是一堆机器，上面部署了提供类似功能的站点，服务，数据库，或者缓存。

如上图：

• web集群，由web.1和web.2两个实例组成
• service集群，由service.1/service.2/service.3三个实例组成
• db集群，由mysql-M/mysql-S1/mysql-S2三个实例组成
• cache集群，由cache-M/cache-S两个实例组成

与“集群”相对应的是“单机”。

画外音：关于高可用架构，详见文章《究竟啥才是互联网架构“高可用”》。
画外音：缓存若是没有高可用要求，多是单机架构，而不是集群。

2、集群信息

什么是集群信息？

一个集群，会包含若干信息（额，这tm算什么解释），例如：

• 集群名称
• IP列表
• 二进制目录
• 配置目录
• 日志目录
• 负责人列表
  画外音：集群IP列表不建议直接使用IP，而建议使用内网域名，详见文章《小小的IP，大大的耦合》。

何时会用到集群信息呢？

不少场景，特别是线上操做，都会使用到各类集群信息，例如：

• 自动化上线
• 监控
• 日志清理
• 二进制与配置的备份
• 下游的调用（额，这个最典型）

这些场景，分别都是如何读取集群信息的？

通常来讲，早期会把集群信息写在配置文件里。

例如，自动化上线，有一个配置文件，deploy.user.service.config，其内容是：
name : user.service
ip.list : ip1, ip2, ip3
bin.path : /user.service/bin/
ftp.path : ftp://192.168.0.1/USER_2_0_1_3/user.exe

自动化上线的过程，则是：

• 把可执行文件从ftp拉下来
• 读取集群IP列表
• 读取二进制应该部署的目录
• 把二进制部署到线上
• 逐台重启
  画外音：啥，尚未实现自动化脚本部署？还处在运维ssh到线上，手动执行命令，逐台机器人肉部署的刀耕火种阶段？赶忙照着这个方案，作自动化改造吧。

又例如，web-X调用下游的user服务，又有一个配置文件，web-X.config，其内容配置了：
service.name : user.service
service.ip.list : ip1, ip2, ip3
service.port : 8080

web-X调用user服务的过程，则是：

• web-X启动
• web-X读取user服务集群的IP列表与端口
• web-X初始化user服务链接池
• web-X拿取user服务的链接，经过RPC接口调用user服务

日志清理，服务监控，二进制备份的过程，也都与上述相似。

3、存在什么问题？

上述业务场景，对于集群信息的使用，有两个最大的特色：

• 每一个应用场景，所需集群信息都不同（A场景须要集群abc信息，B场景须要集群def信息）
• 每一个应用场景，集群信息都写在“本身”的配置文件里

一句话总结：集群信息管理分散化。

这里最大的问题，是耦合，当集群的信息发生变化的时候，有很是多的配置须要修改：

• deploy.user.service.config
• clean.log.user.service.config
• backup.bin.user.service.config
• monitor.config
• web-X.config
• …

这些配置里，user服务集群的信息都须要修改：

• 随着研发、测试、运维人员的流动，不少配置放在哪里，逐步就被遗忘了
• 随着时间的推移，一些配置就被改漏了
• 逐渐的，莫名其妙的问题出现了
  画外音：ca，谁痛谁知道

如何解决上述耦合的问题呢？

一句话回答：集群信息管理集中化。

4、如何集中化管理集群信息

如何集中化管理集群配置信息，不一样发展阶段的公司，实现的方式不同。

早期方案

经过全局配置文件，实现集群信息集中管理，举例global.config以下：
[user.service]
ip.list : ip1, ip2, ip3
port : 8080
bin.path : /user.service/bin/
log.path : /user.service/log/
conf.path : /user.service/conf/
ftp.path :ftp://192.168.0.1/USER_2_0_1_3/user.exe
owner.list : shenjian, zhangsan, lisi

[passport.web]
ip.list : ip11, ip22, ip33
port : 80
bin.path : /passport.web/bin/
log.path : /passport.web/log/
conf.path : /passport.web/conf/
ftp.path :ftp://192.168.0.1/PST_1_2_3_4/passport.jar
owner.list : shenjian, zui, shuaiqi

集中维护集群信息以后：

• 任何须要读取集群信息的场景，都从global.config里读取
• 任何集群信息的修改，只须要修改global.config一处
• global.config会部署到任何一台线上机器，维护和管理也很方便
  画外音：额，固然，信息太多的话，global.config也要垂直拆分

中期方案

随着公司业务的发展，随着技术团队的扩充，随着技术体系的完善，经过集群信息管理服务，来维护集群信息的诉求原来越强烈。
画外音：慢慢的，配置太多了，经过global.config来修改配置太容易出错了

如上图，创建集群信息管理服务：

• info.db ：存储集群信息
• info.cache ：缓存集群信息
• info.service ：提供集群信息访问的RPC接口，以及HTTP接口
• info.web ：集群信息维护后台

服务的核心接口是：
Info InfoService::getInfo(String ClusterName);
Bool InfoService::setInfo(String ClusterName, String key, String value);

而后，统一经过服务来获取与修改集群信息：

• 全部须要获取集群信息的场景，都经过info.service提供的接口来读取集群信息
• 全部须要修改集群信息的场景，都经过info.web来操做

长期方案

集群信息服务能够解决大部分的耦合问题，但仍然有一个不足：集群信息变动时，没法反向实时通知关注方，集群信息发生了改变。更长远的，要引入配置中心来解决。

配置中心的细节，网上的分析不少，以前也撰文写过，细节就再也不本文展开。

5、总结

集群信息管理，是架构设计中很是容易遗漏的一环，但又是很是基础，很是重要的基础设施，必定要在早期规划好：
传统的方式，分散化管理集群信息，容易致使耦合
集中管理集群信息，有全局配置，信息服务，配置中心三个阶段

6、调研

调研1、对于集群信息管理，你的感觉是：

• ca，没考虑过这个问题，一直是分散式管理
• 在使用全局配置文件
• 在使用信息管理服务
• 在使用配置中心

调研2、对于自动化运维，你的感觉是：

• ca，啥是运维，都是研发在线上乱搞
• 有专门的运维，但一直是人肉运维
• 运维在使用脚本，实现了自动化
• 运维都下岗了，在使用平台，实现了平台化

嗯，有道理，得转发一下。

下期预告：监控平台架构细节本期推荐：框架组件，究竟要不要自研？