论高可用的“妙”处
在互联网行业中高可用，目前看来有三种用法。分别是：
1.业务量的增加后，由于市场的需要必须保障核心业务的稳定性。我在这里把称之为 “正常”模式。
2.业务量根本还没有，而且还是新上项目。但是由于服务的启动导致时间的延长（上分钟不能提供服务），所以要做多节点部署
要用前端的高可用，来解决这种程序不能立马提供服务的问题。这种我在这里称之为“斗比”模式。
3.平台不差钱，流量和业务都没有增加也没有接入前。就考虑了高可用。多节点这种，我在这里称之为“高富帅”模式
正常模式，我在这里不谈论。因为市场决定一切、核心服务的强需求，理所当然的。今天的我的观点主要在斗比模式的高可用。
斗比模式的高可用有几个问题。
由于服务的这种延迟启动，导致必须要借用“高可用”的“斗比”模式来进行解决了。比如下面的流程：
1.由于服务的启动时长，不能及时的提供服务。在部署的时候，需要发布成多节点。
需要在升级的时候，先要在摘掉负载均衡上第一个斗比节点。然后升级，升级启动几分钟的时间内，由于服务本身还未启动。然而tomcat（这里指某个基于tomcat的一些java业务服务）
端口已经启动，显然这个时候不能将节点放入负载均衡。那么将进入几分钟漫长的等待（这个时候千万要祈祷java线程别崩溃）后，验证日志ok后再将节点加入负载均衡。并让
节点服务能在负载均衡生效。
2.在升级第2个斗比节点的时候，如法炮制。
针对这种斗比模式，本人有如下观点：
1.这种模式是坑运维和坑老板
2.这种模式是用运维工具去弥补程序设计的严重缺陷
3.这种模式是给平台化、自动化一杯毒酒
4.这种模式是用高可用、灰度这种“正常”模式来装高逼格，用装高逼格的方法论来掩饰程序设计上的缺陷。