Netty的逻辑架构设计理解
背景
- 模仿Netty的架构设计,探索原因。
- Netty的逻辑架构设计,是怎样的?
- Netty的逻辑架构设计,为什么是合理的?
过程
-
Netty的逻辑架构设计,来源书籍《Netty权威指南》
a) Reactor通信调度层监听网络的读写和连接操作,负责将网络层的数据读取到内存缓冲区中,然后触发各种网络事件,例如连接创建,连接**,读事件,写事件等,将这些事件触发到Pipeline中,由Pipeline管理的职责链来进行后续处理。
b) 职责链
负责事件在职责链中的有序传播,同时负责动态地编排职责链。
c) 业务逻辑编排层
协议开发者(可以复用),业务开发者(针对某个特殊场景,不可复用)。
-
为什么说设计是合理的?
a) 这三层的设计把线程模型和协议差异给屏蔽掉了。有序地把业务逻辑编排到职责链中。
b)每一层负责自己的事情。
Reactor通信调度层 ----> 职责链 ----> 业务逻辑编排层(协议逻辑编排)。
处理通信调用的。只需要关心自己的网络相关问题。
处理职责传播的。只需要编排和传播。
业务逻辑层关心自己的具体功能处理。(处理编解码的一次编解码和二次编解码,以及我们的具体业务逻辑处理)
-
从Netty逻辑架构设计中能够学到什么?
a) 站在巨人肩上。 一个架构设计,甚至小到一个功能点的设计,直接模仿这样的分层思路。
b)架构拆分。需要对业务领域的深刻理解。类似于DDD思想。这样的设计是比较好的。
c) 功能拆分。概念间没有冗余的东西。像拆大象一样,把相关概念充分解耦,这样概念设计就会清晰易懂。
d) 事物是发展变化的。一开始的设计,一定不是最终的结果。会根据具体情况,逐渐去优化的,这是一个过程,不是一锤子买卖。体会到这一层很重要。因为:做什么项目,都应该快速把第一版本做出来。
e) 如果负责一个项目。那么项目的架构应该怎么设计呢?具体某个功能应该怎么设计呢?
架构:分层。
功能:CPU密集型,IO密集型,混合型,还是功能有与第三方交互(数据库)。f) 理解设计。技术知识异常丰富,没有必要掌握非常底层的逻辑。应该把精力和时间用在设计上。怎么利用好工具(Java编程语言,idea,其他框架)设计出一个东西。重点是设计。比如学习架构思想、设计模式和成熟的开源产品,比如Netty、Tomcat、Redis和RocketMQ等开源代码。从开源代码中学习写作方式、设计和思考等。
小结
- 架构设计:思考分层。
- 功能设计:考虑到,是CPU密集型,IO密集型还是混合型以及是否与第三方有交互(数据库)。
- 时间和精力应该用在哪儿,是值得思考的一件事。尤其是这个知识年代。
- 读万卷书,不如行万里路;行万里路,不如高人指路;有高人指路,不如自己去悟。话虽这样说,但是如果,能够利用到前人的经验教训,那么就完全没有必要自己再去悟了。