问题都在
如果给我一根杠杆,我可翘起地球。如果给我时间,我可解决一切问题,或许几分钟,或许几年,或许趋近永远。
不谈成本的策略就是耍流氓。不同公司,不同业务场景,不同规模,应对方式不可能完全相同,适合自己的才是最好的。
有备无患
这里的备,是狭义的备,就是数据备份。持久化数据备份,操作系统的备。对于目前的IaaS层,一般都有完整的机制,对于小规模系统或单机系统,管你是中病毒、被恶意删库,突然硬件故障等,备份是你的保留招,无法做到业务不中断,业务不丢数据,但尽可能减少了损失。
架构简洁
简单而不简陋。在牛逼的架构,新人不好理解、老人不好维护就不是一个好架构。架构是为解决问题而产生的,而不是有了架构才去解决问题。如何做功能完整、运行稳定、性能优异且维护简单?局部由于历史积累或业务原因可能存在复杂度,但整体结构应该是简洁的。
持续改进
最求简洁是一个目标,但总有一个认知局限性。变是永恒,变是就应该为了解决问题并尽可能结构上更简化,如果结构更复杂了,那得跳出当前问题更全局范围反思解决方式是否合适。
问题发生
边界很重要,在复杂的软件最终总是被分解并团队协作完成。数据流划分好节点,故障后锁定范围,通过剔除故障服务和引流快速恢复。目前以kubernetes为基础的云架构有很多解决方案,主要还是如何落地并结合好业务问题。
按需选择
对于小应用或小企业应用,7*24只是梦想,早期软件体系能上个集群就不错了,稳定性不单软件问题,还有硬件问题。硬件层面公有云厂商资源可靠性要比自建服务器好很多,毕竟就算硬件级故障,也能快速迁移到其它机器。单机应用基于docker这样的容器运行一个单体或微服务,如果不是软件业务层面问题,稳定性都能保证,最差就是健康检查失败后的重启自愈。
有点规模的企业,直接上个kubernetes云架构,这个源自互联网生态的体系,终极目标就是永不停服。当然也还要结合业务来设计业务架构,让整体落地并可持续更新。
互联网大鳄们就更复杂了,除了做自己业务,顺便把自己云服务器推一推,硬件软件一条线全链搞定。网易云音乐前期服务中断两个小时,被大家各种吐槽,按官方说法和现象看,应该是数据有问题导致都用不了,否则可能仅影响部分用户,技术上相信网易应该有充足的技术积累,可能运维过程中存在瑕疵导致故障。
尽量200吧。