最近在梳理一些架构

从高可用的范围来讲,一个系统可以分为3个层次

1.单系统 

什么服务都在一台机器上面。最多有台备份机,定期把文件打包,数据库dump出来,仍在备份机上面。此类系统最蛋疼的事情是单点故障。硬盘坏了就完蛋。即时恢复,也需要手动把环境建立起来,慢慢恢复。

2.主从系统或者说是负载均衡的系统

mysql 来个主从,有主从有从,web服务,2台以上,每台都是一个独立主机。redis ,mongodb 都主从。可以配读写分离,也可以备机直接做backup ,然后遇到单点故障,手动切过去就可以了。恢复时间较短。但是如果碰到大半夜挂了,那就悲催了。

3. 带自动切换的热备

这个就比较好了,故障转移。然后后期在人员慢慢恢复,不影响用户使用。最为推荐。当然难度系统也是比前2者高,mysql的自动切换也不是那么好切的。

运维理念上的问题,其实技术也就摆在那里了,你不是搞大并非,都有很成熟的方案,网上都能找到。这个时间就是看运维理念的问题,把运维简单理解为维稳,不做危险操作,那也是无法避免单点故障。架构上面的改变才能确保客户服务的高可用,但是比较遗憾很多公司都把服务器维护当作开支一点点精简,压缩,不肯划拨机器,那就没办法了,架构上天生有缺陷。导致出了问题恢复时间慢,用户流失厉害。

现在云平台已经日益成熟,很容易的搞多开一些机器来搞高可用,成本也比托管机器小很多。关键是你的理念要有,不然就是埋了个定时炸弹,什么时候爆炸,不知道。

原文地址:https://www.cnblogs.com/gqdw/p/3589893.html