毕设之-消息系统设计(websocket+netty)

前言

long time no see。 前几天去一家小公司待了待,果断还是选择跑路,第三天就去另一家公司考察环境,和主管聊了两个多小时,非常愉快,就是单位薪资砍了一半。哎,旧事莫提了,这里的话给各位踩了个坑: 小公司,真别去,学不到啥,而且项目大概率写得一坨答辩,在那里装了两天孙子,真难受。作为一个应届生,老老实实去个好点的公司刷经验挺好的,钱这玩意儿,目前你都没有价值,也没有足够能够证明你能够创造价值的情况下,就想着你能怎么怎么样,要多少多少钱那个确实不是很现实,至于我就怎么怎么样,你牛逼你骄傲,你特么是幸存者行了吧。还是以学习为主吧,尽可能多卷卷。

技术选型

这里的话,由于我这里的情况,我这里选择websocket+netty的形式来实现消息推送系统。原因有两个:

  1. 从我自己的毕业业务设计来说,我这里有一个实时聊天的功能,这部分肯定要使用netty来进行实现,所以顺便整体就使用这个来实现,挺好的。
  2. 我的场景没有那么多什么并发,这个破社区,能够有10qps就算我牛逼,上mq,kafka这种第三方组件的,一部署,服务器内存就不够了,扯那么多干嘛。占了我2个G,可能我服务真正需要的也就占了500MB,1.5G全让mq占了(只是打个比方)等不行的时候,那就升级加机器就完了呗。
  3. 原来在上个项目当中设计过这样类似的系统,只需要重新设计即可(没错,我就是懒)

基本架构

这里的话,我们直接看到图:

这个的话,就是我们这个消息系统的一个基本的设计,当然代码还没给出来,这里的话,我打算多留几个接口,写个架子,只要是和业务有关的东西,全部通过开放的handler来实现。这样的话,对于业务的适配就会做的很好。当然这个玩意做出来,天生是无法支持集群的,如果要做的话,那么就要在channel这一层做点抽象了,然后再出各种各样相应的措施。当然这个系统的设计过于复杂,已经不是我该考虑的问题了,我就苟个毕设而已。

okey,就水到这里,后面的事情,后面再说嘿嘿~

相关推荐
RFG20121 小时前
20、详解Dubbo框架:消费方如何动态获取服务提供方地址?【微服务架构入门】
java·人工智能·后端·微服务·云原生·架构·dubbo
TimberWill3 小时前
SpringBoot整合Srping Security实现权限控制
java·spring boot·后端
米羊1215 小时前
Struts 2 漏洞(上)
java·后端·struts
梵得儿SHI6 小时前
Spring Cloud 实战攻坚:企业级用户服务开发(注册登录 + JWT 认证 + 权限控制)
后端·spring·spring cloud·用户注册与登录·jwt无状态认证体系·rbac权限控制·微服务用户中心
callJJ10 小时前
Spring Bean 生命周期详解——从出生到销毁,结合源码全程追踪
java·后端·spring·bean·八股文
怒放吧德德10 小时前
AsyncTool + SpringBoot:轻量级异步编排最佳实践
java·后端
毅炼10 小时前
Java 集合常见问题总结(1)
java·后端
utmhikari10 小时前
【架构艺术】治理后端稳定性的一些实战经验
java·开发语言·后端·架构·系统架构·稳定性·后端开发
undefinedType11 小时前
Rails ActiveSupport::Cache 缓存存储详解
后端
茶杯梦轩11 小时前
从零起步学习并发编程 || 第二章:多线程与死锁在项目中的应用示例
java·服务器·后端