论高可用的“妙”处

论高可用的“妙”处

在互联网行业中高可用,目前看来有三种用法。分别是:
1.业务量的增加后,由于市场的需要必须保障核心业务的稳定性。我在这里把称之为 “正常”模式。
2.业务量根本还没有,而且还是新上项目。但是由于服务的启动导致时间的延长(上分钟不能提供服务),所以要做多节点部署
要用前端的高可用,来解决这种程序不能立马提供服务的问题。这种我在这里称之为“斗比”模式。
3.平台不差钱,流量和业务都没有增加也没有接入前。就考虑了高可用。多节点这种,我在这里称之为“高富帅”模式
正常模式,我在这里不谈论。因为市场决定一切、核心服务的强需求,理所当然的。今天的我的观点主要在斗比模式的高可用。

斗比模式的高可用有几个问题。

由于服务的这种延迟启动,导致必须要借用“高可用”的“斗比”模式来进行解决了。比如下面的流程:

1.由于服务的启动时长,不能及时的提供服务。在部署的时候,需要发布成多节点。
需要在升级的时候,先要在摘掉负载均衡上第一个斗比节点。然后升级,升级启动几分钟的时间内,由于服务本身还未启动。然而tomcat(这里指某个基于tomcat的一些java业务服务)
端口已经启动,显然这个时候不能将节点放入负载均衡。那么将进入几分钟漫长的等待(这个时候千万要祈祷java线程别崩溃)后,验证日志ok后再将节点加入负载均衡。并让
节点服务能在负载均衡生效。
2.在升级第2个斗比节点的时候,如法炮制。

针对这种斗比模式,本人有如下观点:
1.这种模式是坑运维和坑老板
2.这种模式是用运维工具去弥补程序设计的严重缺陷
3.这种模式是给平台化、自动化一杯毒酒
4.这种模式是用高可用、灰度这种“正常”模式来装高逼格,用装高逼格的方法论来掩饰程序设计上的缺陷。

 

评论关闭。