90%的开发都不太考虑这个,但只要出问题直接公司完蛋!

共 2423字,需浏览 5分钟

 ·

2021-04-06 18:51

前不久的这条新闻或许大家已经有所耳闻:

位于法国斯特拉斯堡的 OVH 数据中心被大火烧毁。据悉,火灾导致多个数据中心无法服务,大量客户网站瘫痪,部分客户数据完全丢失且无法恢复,这是数据中心历史上史无前例的灾难性事件。

我们今天不讨论火灾的原因、OVH损失多少,而是想重点说说在这次火灾中受影响的用户与背后的系统设计缺陷

在此次事件中损失最惨的是一家名叫Rust的游戏制造商,该游戏制造商失去了其公司名下游戏所有的欧洲服务器,储存在服务器上的数据全部丢失。

也许很多读者的第一反应是:玩家花费大量精力财力的账号没了,一定是伤心欲绝!

其实,从公司角度来说,他们的损失更为惨重,因为数据丢失也就意味着客户丢失,同时也意味着客户虚拟资产的丢失。这样的灾难对于企业来说,往往面临的就是一个结果:倒闭!

当知道会发生这个结果的时候,相信大家都会开始想起来,怎么不做备份啊之类的疑问?甚至也有读者可能会说,云服务商没有备份么?云服务商要赔钱!

然而大家是否有想过,当你来操盘负责系统架构设计的时候,你是否有去考虑和设计数据灾备的方案呢?是不是只顾着业务实现了?对于灾备的考虑是不是很多人都没有放到很重要的位置去看?

今天,就借最近这个血的教训,来跟大家聊聊这个很多开发人员都会忽略的点!

下面的内容是之前我在星球分享的一篇文章《前往架构师路上的建议(5):新手架构最容易忽略的点!》,当时是因为连续参与了几家客户的培训和咨询之后,引发的关于数据灾备的思考。


最近因为培训与咨询业务,接触了不少创业公司。在给这些公司讲架构课的时候,发现这些创业公司在设计与实现过程中,都忽略了一个非常重要的点:数据灾备。

事后,我也思考了这个问题,为什么创业公司很容易遗漏这个点呢?可能是由于大多创业公司的开发团队核心人员,大多来自一二线互联网公司的高级开发人员(一般都是原企业缺少上升空间,但自身开发能力不错,如果看好创业方向,确实是很容易出来拼一下的)。而在做开发的时候,很多思考的范围都是在如何做好业务需求,让实现更容易在未来做扩展,对于性能可以水平伸缩。而对于数据的灾备,在大公司中,很多就是专职架构师或运维团队去主导和处理的。于是,这部分的设计,对于他们来说,可能比较陌生,就不容易想到。

所以,我将这点加到了这个系列中来,希望大家在成为架构师的路上,把这部分知识与技能都可以完善起来!

数据灾备的重要性

有的同学可能会问:我的数据库已经是主从结构、集群化架构了啊。如果有部分节点挂了,数据还是好的呀。这样做是不是就已经ok了呢?

我可以很明确的说:还不够!即使你是一家创业公司,也一样如此!在介绍一些灾备方案之前,我们先来说说数据灾备的重要性,我们为什么一定要做灾备?为什么你是创业公司,也一样是第一重要的事情!

要说明白这个重要性很简单,大家只要思考一个问题:如果你的业务系统跑了一阵,突然某一天,数据丢了,没有办法恢复!这个时候,你的公司还能不能继续经营和生存下去?(如果你觉得可以,欢迎留言说说你的业务领域以及如何起死回生。)

在历史上,AWS曾经也发生过因断电等原因导致数据丢失而引发的诉讼。由于数据丢失,导致相关企业无法正常运营,最终走向倒闭关门的境地。而所有的诉讼,无一例外的AWS完胜,其核心原因就是这些企业的应用架构上没有做好对数据的灾备方案,而非云计算及服务商的问题。也就是我们常说的,使用姿势不对导致的后果,运营商并不负责!

所以,从做架构开始,数据资产的第一重要性是你要谨记的。如果没有数据的灾备方案,你公司的业务随时可能因为一场事故而土崩瓦解!

数据灾备的实现方案

数据灾备的方案其实很简单,在做具体方案的时候,你主要做的就是根据你当前企业的情况可以付出多少成本,来确定做什么级别的备份。

具体方案的制定上,你需要思考两个问题:

第一个问题:哪些数据要灾备

虽然现在云服务的存储不贵,但是如果我们把所有的数据都去做了灾备,显然也是一种浪费。所以,对数据有选择性的做备份,才是一名好架构师的表现。

第二个问题:要应对多大的灾难

这个问题的根本就是备份数量以及备份地点的选择。

之前提到过如果数据库已经是高可用的,那么这里面的数据确实已经具备了一定的灾难应对能力,但为什么说这样的灾备级别不够呢?因为通常在线业务的数据库集群都在一个机房,甚至一个机架。由于物理上的部署原因,他所能应对的灾难是很优先的,对于机器级别的灾难,他可以应对,但是当遭遇火灾或更大的自然灾害的时候,这样的部署方案显然是无法应对的。

所以,对于创业公司来说,最基本的灾备方案除了同机房的高可用集群之外,还需要有一个异地机房的备份是最基本的要求。如果有必要,还能扩大这个范围(不光跨城市,还可以跨大陆板块等策略)或是扩大备份数量来进一步增加灾备级别。

最后,灵魂一问:你们公司目前的业务系统是否有做数据灾备呢?

如果有做,那么方案是怎么样的呢?留言分享下吧!

P.S. 补充一句,本文主要讨论的是数据灾备,核心解决的是数据存储的安全性。不要与“两地三中心”、“异地多活”等高可用架构混为一谈。


往期推荐

MySQL主从原理,基于快速学习一门技术的3种方式!

一起学习下一线大厂的分布式唯一ID生成方案!

分库分表这样玩,可以永不迁移数据、避免热点

为什么阿里不允许用Executors创建线程池,而是通过ThreadPoolExecutor的方式?

为什么培训班出来的程序员总遭人嫌弃?


如果你喜欢本文,欢迎关注我,订阅更多精彩内容
关注我回复「加群」,加入Spring技术交流群

免费领取:算法刷题笔记


关于星球,我就不放二维码了,对里面内容感兴趣的童鞋,点击阅读原文查看过去几年我们都聊了些啥有趣的话题

浏览 19
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报