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

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

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

讲Z平台,可能需要提前介绍Y服务;讲Y服务,可能需要提前介绍X知识。

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

由于基础,可能部分同学会觉得简单;由于大家所在公司处于不同阶段,所以在实现上会介绍不同阶段的公司应该如何来实现。

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

  • 是什么
  • 什么场景,为什么会用到,存在什么问题
  • 常见方案及痛点
  • 不同阶段公司,不同实现方案

希望大伙有收获。

一、啥是集群?

互联网典型分层架构如下:

  • 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两个实例组成

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

画外音:关于高可用架构,详见文章《竟啥才是互联网架构“高可用》。

画外音:缓存如果没有高可用要求,可能是单机架构,而不是集群。

二、集群信息

什么是集群信息?

一个集群,会包含若干信息(额,这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服务

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

三、存在什么问题?

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

  • 每个应用场景,所需集群信息都不一样(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,谁痛谁知道

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

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

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

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

早期方案

通过全局配置文件,实现集群信息集中管理,举例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来操作

长期方案

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

配置中心的细节,网上的分析很多,之前也撰文写过,细节就不再本文展开。

五、总结

集群信息管理,是架构设计中非常容易遗漏的一环,但又是非常基础,非常重要的基础设施,一定要在早期规划好:

  • 传统的方式,分散化管理集群信息,容易导致耦合
  • 集中管理集群信息,有全局配置,信息服务,配置中心三个阶段

六、调研

调研一、对于集群信息管理,你的感受是:

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

调研二、对于自动化运维,你的感受是:

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

原文发布于微信公众号 - 架构师之路(road5858)

原文发表时间:2018-01-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏搜云库

保证分布式系统数据一致性的6种方案

在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要满足要...

1.8K7
来自专栏Linyb极客之路

系统架构之高可用服务层设计

众所周知,服务层主要用来处理网站业务逻辑的,是大型业务网站的核心。比如下面三个业务系统就是典型的服务层,提供基础服务功能的聚合

1182
来自专栏码匠的流水账

OpenMessaging概览

OpenMessaging是阿里牵头发起的分布式消息模型标准,其api规范首先在rocketmq中落地实现。通过这个标准可以简化各种消息中间件的高复杂性和不兼容...

2491
来自专栏EAWorld

微服务来了,配置怎么办?

配置管理是个简单的小话题,程序员都已经非常熟悉,咋就跟微服务挂上钩了呢? 前些年没提微服务架构的时候,大家也都会做配置管理相关的事情,比如我接触过的很多项目都做...

3666
来自专栏猿人谷

三种Linux服务器监控技术的对比

本文介绍三种Linux服务器监控技术的优缺点,其中有SNMP代理(客户端)方式、SSH方式、安装私有代理(客户端)方式等内容。 Linux系统的强大的功能和绚丽...

2337
来自专栏开源优测

有那么几张图给大家看看

731
来自专栏网络产品使用分享

【腾讯云的1001种玩法】利用 Auto Scaling 节省30%成本

公有云提供了很多免费的高级功能,很多中小用户以为自己用不上。实际上稍微研究一下,就能享受很多便利和节省不少成本。 本方案就是利用弹性伸缩(auto-scalin...

9240
来自专栏Java编程技术

分布式事务- TCC编程式模式

严格遵守ACID的分布式事务我们称为刚性事务,而遵循BASE理论(基本可用:在故障出现时保证核心功能可用,软状态:允许中间状态出现,最终一致性:不要求分布式事务...

1563
来自专栏程序员互动联盟

【专业技术】Android如何实现推送?

存在问题: 现在各种实时推送消息不时的在我们手机通知里闪烁,而windowphone搞了那么久在加上,实时消息要求的是实时性。在我们开发中如何掌握这种实时模式呢...

5685
来自专栏匠心独运的博客

过来人的经验,谈谈一致性处理方案—分布式事务(DTS)

传统事务是使用数据库自身的事务属性(ACID),而数据库自身的事务属性是局限于当前实例,不能实现跨库。而对于大型分布式/微服务集群系统中,不仅存在着跨库的事务,...

3834

扫码关注云+社区

领取腾讯云代金券