0


留念 · 大学时代最后的系统设计图

文章目录

留念

应几位朋友之邀,放一下图,也给自己留个纪念,数年后回想起,曾经我花了半年迭代出这么一个设计,哈哈,不知道到时候是什么感觉,会不会像我现在看一年前的设计图一样感觉傻,还是为进步而开心。

然后,本文的所有知识点都在我的其他博客中可以找到,我不会放链接,信我的,在我的博客主页搜索;


当前架构

土是土了点,应该能叫“架构图”了吧。
在这里插入图片描述

稍微解释一下:

网络层:muduo + pb + tcp/ip + api安全接口设计。
选择 muduo 是因为它是我目前技术栈里最高可用的网络库了。注:我的毕设是一个高可用系统。
选择 pb,我试过,同样一个包,pb 压缩后所占空间直接是 json 的 1/5 左右,甚至对于 0 值,pb 是直接省略的,这也可以拿来做文章的。就算选用了 pb,在字段上我依旧极致省略,首先就统统都是 int,字符串的话就映射成 int。其次 int 一定要尽量拼凑到 8 位数才发,如果超出 8 位,那就用 long。再怎么样,一个字段总比四个字段要省。
选择 tcp/ip,我就不说话了吧。
api 安全接口设计,自行了解。

业务层:这里的业务都被我抹掉了,不过有几点要注意的,通用的。
1、分布式系统要注意分布式锁。
2、对于登录业务要注意二次登录。
3、对于注册业务,采用自增 id 的时候要掂量一下,分布式环境的自增 id 没那么简单。可以在我的博客主页搜索一下“自增 id”。
3、对于 MySQL 可以考虑存储过程,只要不是太复杂,因为存储过程的调试是真的要呕血三升的,我调过。
4、业务和数据库之间一定要做熔断。
5、最好能有 IP 限流模块,这个模块开发的晚,就没在图中展示了。因为我自己系统的特殊性,我就设定,不论你是谁,一秒都只能访问一次,因为我默认你需要阅读一下我返回的内容。那会不会误杀?不可能的,我告诉你,绝对不可能,只要是从我手上出去的客户端,那都是要做防抖的。

其他的暂时还没想到,想到我也不再补了。

持久层:持久层选用 MySQL + Redis。这里要注意:
1、MySQL 有条件的话最好单独部署到别的机子上,没必要,那个网络 I/O 的开销,跟MySQL 的磁盘 I/O 比起来那真不算什么了。
2、有能力一定要做存储过程,前提是要做好调试存储过程的心理准备。
3、Redis 有条件的话最好跟业务层放在一台机子上,Redis是什么?吹破天了它也是个缓存,缓存你不跟主机放一起你要去自立门户吗?然后多走那一圈 I/O?要知道,后端开发很大的一个瓶颈就在于网络I/O,木有带宽呀!!!
4、数据字典。数据字典非常重要,在项目分析阶段一定要有明确的数据字典,而且一定要做单例模式。可以改,但是不能没有,也不能多实例。不然到后期就知道什么叫痛苦了,到时候模棱两可的数据越改越迷糊了。
5、很重要的一点:基准测试。在架构设计之前就要做好的事情。MySQL 可以使用专门的基准测试工具 sysbench,redis 更简单了,人家有自带的。

HA:根据基准测试的结果来设定 HA。不要到时候你的环境只能 hold 住一台 MySQL,你来个主从复制哈,然后跑过来说为什么我的 MySQL 查询这么缓慢,屁话,既要马儿跑,又要马儿不吃草…

性能监控:promethues(存储数据) + NodeExporter(采集数据) + G什么的(数据可视化)


对于图中两个框架,我的博客里也都有。
RPC:远程接口调用。
ORM:对象关系映射。

ORM 比较简单,RPC 可能不是那么好理解。其实图中 RPC 的位置在上一个版本我写的是:命令 + 门面。这两个设计模式我已经删了,当时觉得过于简单,这里我补一下:
命令模式:在业务层存放一个哈希表,键值对形式为

<业务id:业务函数指针>

,通过函数调用 get_handle,传入业务id,执行函数指针。
门面模式:整个业务层只对外开放这么一个函数调用 get_handle。

有这两个框架,我可以将我的系统层层解耦,相互之间谁也不要认识谁,我大权在握哈哈。


当前部署

只有这么一个架构图是不够看的,因为你不知道怎么部署。我有一部分代码是在部署图上体现的。

在这里插入图片描述

简单解释一下:
可以看到,整个系统都是部署在 docker 上的,做了状态剥离。
状态剥离:将 各种 IP、Port 等配置项移出,填写在 Deployment.json 文件中,此后不管你想把哪个组件挪到哪台机子上,那随便你。
平滑升级:将状态进行剥离之后,那想做平滑升级就很简单了,做一个观察者模式,监控 deployment.json 中 version 的变化,只要 version 变化了,就重新读取配置项。至于新旧组件的交替,那至少得等新的上位了,再把旧的关了嘛。所以这里需要考虑一下你的资源是否充足。
平滑迁移:那我还能说什么呢,状态你都剥离了,我又全在 docker 上,你直接一锅端了呗。


下一版架构图

结束的是毕设,不是我的项目。

在这里插入图片描述

简单讲一下变更:
1、业务层拆分微服务,核心业务单独划分,零碎业务凑到一起办了。后面的业务都需要走登录这一块,也想过将登录业务直接作为伴生业务划到网络层的 pod 里面去,但是想了想万一登录业务崩了,连带整个网络层一起崩了。所以:做好熔断、

2、既然业务都拆了,说明流量大了。那 Redis 也拆了吧,用来做锁的单独一块儿,用来承载数据库热点数据的单独一块儿。

3、MySQL 暂时不拆,但是要有能分库分表的能力。


下一版部署图

为什么叫下一版,而不是这一版,其实架构图上也看不出来嘛,因为理论上是实现的了的。
看了部署图,就知道为什么叫 “下一版” 了。

在这里插入图片描述

你猜我是哪里不行哈哈。最底下那两块儿,目前还没部署成功…


如果有学弟学妹想做一下以后方便写在自己的简历上,一定要私信我。呈现在这里的就是这么几张图,但是你不知道的是它们每张图,背后都有十几张图的迭代,项目都是从最简单的开始做起,越滚越大越滚越大,一上来就高屋建瓴的,咱不是那天才哈…


本文转载自: https://blog.csdn.net/qq_43762191/article/details/124915271
版权归原作者 看,未来 所有, 如有侵权,请联系我们删除。

“留念 &middot; 大学时代最后的系统设计图”的评论:

还没有评论