前言
在日复一日地使用各种中间件和学习原理时,笔者陷入了迷茫,各种中间件层出不穷:到底何时能学完?技术的本质到底是什么?学习到底怎么才能学习到根源?
但是,不难发现中间件日趋同质化,他们都朝着一个既定目标:进入内存加快运行速度。
但是进入了内存也不意味着快了,还得需要良好的数据结构去保障内存的空间利用和搜索效率。
反复思考,日夜琢磨。我终于得到了万物基于OS这个感触,虽然之前一直听说这句话,但直到最近的深入学习才感受到刻骨。
至此,特地开启一个新的系列,此系列不仅立志于内核相关内容分析,也专注与内核原理研究与各种高性能中间件的关系探索,初步规划内容方向为:操作系统内核架构以及当代高性能中间件架构,操作系统资源同步与JAVA语言中的JUC和中间件应用层面避免开销的举措,内存级中间件的对于内存的管理与操作系统的内存管理等,可随时补充。
如果你非常感兴趣与我接下来写的文章,可以评论留言一直交流,共同学习。
单机架构
互联网万事万物迭代都会出现两个极端:极致性能和极致可用两个方向。
首先明确:鱼和熊掌两只不可兼得。这里说的极致可用为高可扩展性和持续可用性。
对于极致性能(宏内核)
操作系统的内核架构也是如此,最早的一种内核架构为宏内核。顾名思义,各种功能全都高度耦合在一起,减少了调用过程。这种结构的特点就是快而不稳,若出现了蚁穴,这座千里之堤就容易毁于一旦。除此之外,如果有新的功能或者需求加入,整个内核不得不重新编译运行,久而久之启动成本也会呈指数级的增长。对于笔者来说,最开始接触的Javaweb项目也是这一种。
对于极致可用(微内核)
机制的可用我认为他是一种模块化、分层化的结构,每个模块高度聚合,实现自己单独的功能,相同性质的模块可继承同一抽象类等性质。在操作系统的迭代中微内核即所述架构,他提倡内核功能应尽可能少,仅仅存在如进程调度、处理中断、内存空间映射等核心功能,并将宏内核中一个一个的功能做成进程。 这些进程间的通信靠着——消息。非常类似一种消息的转发,和Netty的消息派发和rabbitMq的topic有着异曲同工之妙,但是我更认为后来的中间件都是学习操作系统的相关思路。
关于可用还有一个关键的概念是分层。“多一层封装,多一份灵活。”这是我在开始学习spring的时候听到的话。封装分层不仅能使得代码更加优美规范,还极大提升了代码的灵活度,降低了耦合性,屏蔽了诸多相关人员可以不知道的细节。当然分层的好处还有很多,多多使用更能切身体会。
讲究中庸(混合架构)
对于以上两种极端,无数的演变流程都会将极端中和,得出一个平衡的解决方案。
当下的混合架构就采取了调用的方式,避免的消息的不停流转,也采取了分层的策略,降低了耦合,屏蔽了无关细节。常见的混合架构大致分为三层:内核接口层(对外暴露),内核功能层(依赖硬件层),内核硬件层。减少内核实现的功能,去掉文件系统和网络组件等功能,这部分吸取了微内核的优势。若驱动被加载即成为内核的一部分,提升了性能,这部分吸取了宏内核优势。
总结
由此观之,可见操作系统架构设计思想的通用性,也是我认为他是所有中间件思想的源头,如同代码世界中的《易经》。当然中间件与内核的关系也是相互促进相互影响的。本文还有诸多漏洞,欢迎指导指正,笔者定会裨补缺漏,持续迭代。