2021-10-22

2021-10-22 大型架构之路

文章目录

• • 大型架构之路
• 前言
• 一、技术难点
• 二、常见问题
• • 1.删库&自杀式查询
  • 2.单服务宕机
  • 3.服务器出现问题
• 总结

---

前言

如果人生没有止境，那工科男对于技术的追求肯定是无边际的，当接触到架构我就意识到架构是一种神奇的内容，当我开始接触SSM框架是，虽然这还是一个前后端不分离的框架，但是作为一种官方的框架，还是被很多人认同的，在我看来SSM框架是前后端分离框架的基础，前后端分离只是在SSM框架上对功能实现了一种分区，这是我们所追求的一种方式，现在我们来分析一种扩展型的框架，这个框架不是原生或者官方框架。而是一种应对高并发，实现高可用，应对高搜索，并且能够实现推荐功能，风控功能的一种框架。如下所示：

---

一、技术难点

技术难点主要有：

1.视频/用户/商品访问存储
流
就近节点
视频编解码
断点续传
数据库系统&文件系统隔离

2.并发访问
流媒体服务器
数据集群，分布式存储、缓存
CDN内容分发
负载均衡
搜索引擎

3.消息系统
并发、线程
kafka
nio框架（netty）
…

二、常见问题 1.删库&自杀式查询

需要主机权限直接禁止了rm-rf、fdisk、drop这样的命令。而且数据库现在大概率都是多主多从，多地备份的，容灾也应该是做的很好的，而且光是数据库炸了，那cdn的很多静态资源应该也不会加载不出，整个页面直接404了。

还有就是避免自杀式查询，这种查询会严重损耗性能，也会大量消耗时间。

2.单服务宕机

现在都是前后端分离的，如果是后端挂了，前端很多东西依然是能加载只是数据出不来报错，所以集群要挂也可能是前端挂了，或者前后端一起挂了，但是还是那个问题，现在看起来是所有静态资源都无法访问了。所以如果希望宕机，也是希望前端宕掉，而不是后端宕掉，因为如果是后端宕掉，那么发现的时候会比较晚。但是前端宕掉，那么缓存的静态资源也加载不出来，我们就能立马察觉问题，从而解决问题。

不过这个点我觉得也有一点可能，因为部分服务挂了，导致大量报错，拉挂了集群，其实如果部分服务宕机就能够挂了集群，从某种角度来说，集群设置的太差了，因为我们有着成熟的崩溃恢复方案，那么部分服务挂了后，这样大家反而越会不断刷新页面，就会造成请求拥堵，给其他服务重启增加难度，其他服务器难以重启，那么服务就很难恢复，但是我们要明白，用户是盲目的，也是不懂底层的。他可能只是人为是自己的网速问题，那么在这段时间他就会发出大量的请求，但是这个可能性没我之前说的可能性大。因为大型互联网公司的备灾系统都是十分协调和完备的，我们就举一个阿里巴巴的例子，阿里在三个地方上海，杭州，深圳都有自己的服务器，而且是主从分布的，这种情况任何一个区域的服务器挂掉，我们都是可以立马从备服务器去获取数据的，而且在初始时备份数据是全量备份，后面都是增量备份，这意味着我在平时时需要备份的数据是增量数据，对于阿里的服务器来说，这只是很小的工程量。

3.服务器出现问题

本地服务器互同步，这只是一个低等方案，如果是高等方案，其实很简单，那就是我们从云服务器去拉取增量数据，而云的稳定性是设计云服务器的根本，对于成熟的云服务器，比如说阿里巴巴的阿里云，还有华为的鲲鹏云，最最基本的就是稳定性。

该处使用的url网络请求的数据。

---

总结

大型架构最注重的就是风控，网络安全，数据安全，服务器安全这些最为关键的内容，如果说这上面四项一个没有保证，对于这家公司而言都是致命性的。