思考Netty的设计
最近给小伙伴做一个netty的分享,好久没研究了,又拿出来重新熟悉了一下netty的框架设计。温故还是能知新的。
netty领域
netty确实很强大,有很多值得我们学习和借鉴的地方,从最早学习这个框架的时候感觉还是从里面的每一个比较细的点去学习,没有由点到面。
认识了各种框架,越来越觉得一个好的中间件或框架,应该能专注于解决一个核心领域问题,比如netty要解决的就是java通信问题,屏蔽了底层的通信细节,将复杂的IO线程处理逻辑和业务处理逻辑分离,也就是分层设计,netty负责了通信的这一层。
设计像netty一样的中间件应该考虑什么
设计一个中间件,首先应该考虑的问题是,我需要解决什么问题?然后应该要考虑领域模型的设计。这个也是很关键的,一个框架如果要能持续迭代和优化10年,应该有清晰的和稳定的领域模型。我们业务开发中的领域模型应该是和商业业务相关的,而中间件的领域模型应该是跟计算机,网络通信,IO等切实相关的。
netty的核心领域模型就是抽象了几个核心接口,ByteBuf + ChannelHandler + ChannelPipeline + EventLoop 大部分的工作都是在对这几个模块的加强和优化。EventLoop可以支持各种类型,ByteBuf可以堆内也可堆外,围绕着内存分配, 在迭代的过程中,因为直接内存虽然读写快但是分配和回收速度慢,所以有了自己的对象池和内存池。当核心领域模型确定了,发展路线也就确定了,特别是一个开源项目,多人协作,更加需要一个大家都清晰的模型。直到今天我看netty的github的社区更新也是蛮频繁的,这是一个社区维护的开源项目,坚持了这么多年非常难能可贵,这样的项目生命力也很强。
总结收获
- 个人觉得,一个好的框架, 不应该是能做非常多的事情,功能多牛逼,而应该是专注自己的这一块领域,可以不断的迭代优化,越做越精。
- 公司的项目开发中也应该是这样,一个项目,随着用户的增多需求的增多,是自然而然功能越来越丰富。
- 但是如果一个项目要能适应后续的发展,首先需要确定自己的核心领域,不应该什么都往里面丢,要划清楚项目的边界。围绕着核心领域模型,要有清晰的架构设计,来支撑快速的迭代和发展。