一文贯穿操作系统内核架构与当代软件架构迭代

前言

在日复一日地使用各种中间件和学习原理时，笔者陷入了迷茫，各种中间件层出不穷：到底何时能学完？技术的本质到底是什么？学习到底怎么才能学习到根源？
但是，不难发现中间件日趋同质化，他们都朝着一个既定目标：进入内存加快运行速度。
但是进入了内存也不意味着快了，还得需要良好的数据结构去保障内存的空间利用和搜索效率。
反复思考，日夜琢磨。我终于得到了万物基于OS这个感触，虽然之前一直听说这句话，但直到最近的深入学习才感受到刻骨。
至此，特地开启一个新的系列，此系列不仅立志于内核相关内容分析，也专注与内核原理研究与各种高性能中间件的关系探索，初步规划内容方向为：操作系统内核架构以及当代高性能中间件架构，操作系统资源同步与JAVA语言中的JUC和中间件应用层面避免开销的举措，内存级中间件的对于内存的管理与操作系统的内存管理等，可随时补充。
如果你非常感兴趣与我接下来写的文章，可以评论留言一直交流，共同学习。

单机架构

互联网万事万物迭代都会出现两个极端：极致性能和极致可用两个方向。
首先明确：鱼和熊掌两只不可兼得。这里说的极致可用为高可扩展性和持续可用性。

对于极致性能（宏内核）

操作系统的内核架构也是如此，最早的一种内核架构为宏内核。顾名思义，各种功能全都高度耦合在一起，减少了调用过程。这种结构的特点就是快而不稳，若出现了蚁穴，这座千里之堤就容易毁于一旦。除此之外，如果有新的功能或者需求加入，整个内核不得不重新编译运行，久而久之启动成本也会呈指数级的增长。对于笔者来说，最开始接触的Javaweb项目也是这一种。

对于极致可用（微内核）

机制的可用我认为他是一种模块化、分层化的结构，每个模块高度聚合，实现自己单独的功能，相同性质的模块可继承同一抽象类等性质。在操作系统的迭代中微内核即所述架构，他提倡内核功能应尽可能少，仅仅存在如进程调度、处理中断、内存空间映射等核心功能，并将宏内核中一个一个的功能做成进程。 这些进程间的通信靠着——消息。非常类似一种消息的转发，和Netty的消息派发和rabbitMq的topic有着异曲同工之妙，但是我更认为后来的中间件都是学习操作系统的相关思路。
关于可用还有一个关键的概念是分层。“多一层封装，多一份灵活。”这是我在开始学习spring的时候听到的话。封装分层不仅能使得代码更加优美规范，还极大提升了代码的灵活度，降低了耦合性，屏蔽了诸多相关人员可以不知道的细节。当然分层的好处还有很多，多多使用更能切身体会。

讲究中庸（混合架构）

对于以上两种极端，无数的演变流程都会将极端中和，得出一个平衡的解决方案。
当下的混合架构就采取了调用的方式，避免的消息的不停流转，也采取了分层的策略，降低了耦合，屏蔽了无关细节。常见的混合架构大致分为三层：内核接口层（对外暴露），内核功能层（依赖硬件层），内核硬件层。减少内核实现的功能，去掉文件系统和网络组件等功能，这部分吸取了微内核的优势。若驱动被加载即成为内核的一部分，提升了性能，这部分吸取了宏内核优势。

总结

由此观之，可见操作系统架构设计思想的通用性，也是我认为他是所有中间件思想的源头，如同代码世界中的《易经》。当然中间件与内核的关系也是相互促进相互影响的。本文还有诸多漏洞，欢迎指导指正，笔者定会裨补缺漏，持续迭代。