文章目录
- 前言
- 技术选型
- 基本架构
前言
long time no see。 前几天去一家小公司待了待，果断还是选择跑路，第三天就去另一家公司考察环境，和主管聊了两个多小时，非常愉快，就是单位薪资砍了一半。哎，旧事莫提了，这里的话给各位踩了个坑：
小公司，真别去，学不到啥，而且项目大概率写得一坨答辩，在那里装了两天孙子，真难受。作为一个应届生，老老实实去个好点的公司刷经验挺好的，钱这玩意儿，目前你都没有价值，也没有足够能够证明你能够创造价值的情况下，就想着你能怎么怎么样，要多少多少钱那个确实不是很现实，至于我就怎么怎么样，你牛逼你骄傲，你特么是幸存者行了吧。还是以学习为主吧，尽可能多卷卷。
技术选型
这里的话，由于我这里的情况，我这里选择websocket+netty的形式来实现消息推送系统。原因有两个：
- 从我自己的毕业业务设计来说，我这里有一个实时聊天的功能，这部分肯定要使用netty来进行实现，所以顺便整体就使用这个来实现，挺好的。
- 我的场景没有那么多什么并发，这个破社区，能够有10qps就算我牛逼，上mq,kafka这种第三方组件的，一部署，服务器内存就不够了，扯那么多干嘛。占了我2个G，可能我服务真正需要的也就占了500MB，1.5G全让mq占了（只是打个比方）等不行的时候，那就升级加机器就完了呗。
- 原来在上个项目当中设计过这样类似的系统，只需要重新设计即可（没错，我就是懒）
基本架构
这里的话，我们直接看到图：
这个的话，就是我们这个消息系统的一个基本的设计，当然代码还没给出来，这里的话，我打算多留几个接口，写个架子，只要是和业务有关的东西，全部通过开放的handler来实现。这样的话，对于业务的适配就会做的很好。当然这个玩意做出来，天生是无法支持集群的，如果要做的话，那么就要在channel这一层做点抽象了，然后再出各种各样相应的措施。当然这个系统的设计过于复杂，已经不是我该考虑的问题了，我就苟个毕设而已。
okey,就水到这里，后面的事情，后面再说嘿嘿~
