灾难

针对昨天发生的“灾难”,有必要做一次记录。

全站奔溃,节点几乎全部掉线,精力透支,万幸的是数据库完好无损;这也为后面的全站重建带来一点信心。这是一场由简单的前后端分离引发的连锁反馈,时间的起因对象存储确实有极大的吸引力:

  • 集群性

对象存储系统可以在一个集群内以ScaleOut*方式线性扩展,可以直接根据储存数规模增减储存节点,甚至跨地域实现集群,而不受文件数量、文件大小和文件系统容量的限制。提高业务灵活性,免去传统硬件移植或大规模升级硬件的麻烦。 
 

  • 共享性

对象存储软件可被看作专门的文件系统,各个接口为提供服务存在,因此能够方便地实现数据共享。
  

  • 易于维护

对象存储空间可以统一管理,基于单一的平面地址空间,可以实现数据合理自动路由的存储,省去了使企业存储系统时刻处于生产工作状态的复杂且昂贵的管理成本。  

  • 负载均衡

对象存储集群的每个节点都是独立的,访问负载可以平均分配到集群中的所有节点上,避免出现NAS和集群文件系统中常见的资源利用不合理的问题。并且可以让数据读取自动选择合理的节点,保证系统性能最大化。)

  • : Scale out is a growth architecture or method that focuses on horizontal growth, or the addition of new resources instead of increasing the capacity of current resources (known as scaling up).

那么对于建站(静态页面)来说,个人业主看重的是低廉的价格、较好的国际访问速度、较高的抗攻击特性(?)、较强的资源扩充能力》...其实就前后端分离而言(站库分离),数据库的保护是至关重要的,指向数据库的IP需要保证隐蔽且不容易被封锁;前端页面首先保证其可访问性与灵活性,无论是部署在虚拟主机、oss、VPS上,都有各自的优势。

目前站点还有许多需要改进的地方:

  • 安全性

主站目前部署在阿里云,性能勉强够用的情况下随时都面临一瞬被挤宕机的风险,其次避免不了小量的访问攻击,这同样容易造成网站的长时间不可访问。所以需要做的有且不仅仅有整站的oss备份,数据库备份,部分域名的CDN保护等;另外前后分离也属于安全性措施之一,我不会放弃。

  • 拓展业务

dev版本加入了邮件5分钟验证,借此机会更新发件服务商;Quan、Surge的托管支持也是少量用户的需求。

  • 线路维护

针对 CDN+ws 的不稳定因素,需要有中转线路+gost隧道的备选方案。

昨天经历了长时间无法服务的情况,给了自己和团队警示:数据备份至关重要,团队伙伴的支持和协助是雪中送炭让我能在谜团中喘口气相处对应的解决办法,相信有K的不断支援我们会越来越强。

本文链接:

https://my.ziao.bid/index.php/archives/30/
1 + 9 =
1 评论
    runchen.ethChrome 80Windows 10
    4月12日 回复

    你的博客很酷哦!
    这个是怎么搭建的?