什么是微内核架构
相信你们都据说过微内核架构，也或多或少作过一些相似于微内核架构的设计，为了能够更好的设计出微内核的架构，咱们了解下什么是微内核架构。redis
说到微内核架构，你们首先会想到的是Eclips、IDEA、OSGI、Spring Plugin、SPI等，这些都是咱们熟知的微内核架构。有了微内核架构，咱们能够更好的定制和控制流程，因此微内核架构的设计思想常常在作配置化中台项目的方案中出现的。api
微内核架构实现主要是插件化思想（Plug-in），是一套插件体系，最先的插件化方法是应用在操做系统之上，长此以往就有了微内核设计这一思想。性能优化
了解微内核，须要先了解这个“内核”。网络
在操做系统中，内核围绕于操做系统的核心功能，好比时钟中断、进程建立与销毁、进程调度、进程间通讯等内核态的动做。而文件系统、内存管理、设备驱动等都被视为非内核能力，这部分会被放在用户态空间。架构
微内核是相对于宏内核而言，宏内核包含了不少的底层程序功能，作的事情很是多，并且不是可拔插的，修改任意一个功能点，都须要整个程序联动，并且有可能引入一个bug，致使整个内核不可用，相似于一个功能复杂的单体系统，每次变动和交付成本都很是高，风险也很是大。分布式
而微内核只围绕于核心功能设计，他的功能实现都是相互独立的，其余非核心功能是经过用户态的独立进程以插件的方式加入进来的，微内核引擎复杂管理进程、调度进程、进程之间通讯。某一个功能出现问题时，因为其是独立的进程，不会对其余进程产生影响，也不会致使内核不可用。函数
微内核中，多个进程协调通讯，须要进行系统调用，系统调用须要切换堆栈及保护进程现场，过程比较耗时。 宏内核（也就是用户态）中，是经过函数调用完成各个模块之间合做，因此宏内核较微内核效率更高。微服务
经过操做系统微内核概念，能够类比到业务系统。一个系统，特别是通过微服务拆分以后的系统，都会服务于某个“内核”，多个核心功能经过微服务的方式拆分，服务之间经过通讯交换数据。经过微内核解决了快速交付问题，实现了代码隔离，控制风险点的目的。性能
而考虑到扩展性，咱们须要定义出内核的骨架，并开放出plugin，以实现个性化扩展。这样的微内核架构，咱们能够便于定制，改动小，进而实现热更新，这也是微内核架构的主要价值。优化
微内核架构设计
在微内核架构中有两个核心组件：系统内核、插件化组件。
系统内核：主要解决的是内核的核心功能，好比插件的注册与管理、插件生命周期管理、插件之间通讯、插件的热加载与替换。
结构以下：
基于微内核的插件化设计，咱们能够实现组件隔离，每一个插件能够以独立jar包或独立进程运行，这些插件组件进程能够独立部署在分布式网络上，实现水平扩展，某种程度就像咱们的微服务治理体系，有独立部署的微服务进程，也有中心治理的注册中心与配置中心。
在操做系统中，微内核与宏内核通讯方式上有以下区别：
微内核架构下，组件之间的通讯也是基于消息的，好比每一个组件对于消息处理有两个能力：收（receive）、发（send）。
那两个进程之间通讯，是否须要一个三方中介呢？好比这样：
在操做系统中，消息的通讯是基于内核转发的，也就是咱们常常据说的消息总线架构，内核复杂协调各个进程的通讯，好比进程A想要发送消息给进程B，须要知道B对应的内存地址。进程向内核发送消息，内核再将消息发送给对应的接收进程，这样是一个总线通讯过程。
在不少微内核架构设计实现上，组件之间均可以经过EventBus实现Plug-in之间的解耦，也就是借鉴了总线的设计。
在微服务架构的通讯实现上，在SOA时代，有相似于消息总线的概念。但大部分是进程之间的直接调用，没有了这个所谓的总线。
可是若是引入了一个中心化的服务注册与发现中心，他可能也会有个所谓的内核中转：
在插件化系统中，组件之间不直接通讯，而是借助于一个中心化的内核系统进行转发。这种设计思想很是相似于操做系统的内核转发实现，插件之间隔离、透明。某个组件下线或替换，其余组件不须要感知。
这样的架构会存在于一些其余的问题。首先，这个中心化的转发中介变成了单点，其可用性严重影响了整个系统的可用性。当中心化系统变成单点转发，就存在对应的性能问题。
对于远程进程调用的性能优化，咱们能够想到这几点：
- 采用高性能的二进制协议代替http1.x协议，由于http1.1的文本协议性能较差；
- 采用相似于零拷贝机制，实现快速网络包转发，而不须要作内核态与用户态的转换；
- 引入好的网络硬件，好比RDMA；好的协议，如UDP、QUIC等；
- 选择不一样的通讯方式，好比RPC的、Pub/Sub的、无序ACK的、单工/双工通讯的等；
为了处理这么多协议的转发，内核系统须要具有Adapter以实现对于众多协议的解析与转发，好比引入多个filter来支持不一样的协议，可是他将变得愈来愈复杂。
还有一种思路是，内核服务只支持一种协议，各个插件之间也基于这个协议通讯，协议的适配与转换是各个组件本身作就能够。
其实不少人会想到，这个中心化的内核组件的消息转发不就是相似于一个MQ系统的Broker吗？而那种独立处理通讯协议的组件不就相似于Mesh设计吗？
没错，前一种相似于相似于broker，后一种相似于service mesh或agent思想。功能上是同样的，只是处理逻辑上有些差别。
broker是集中式的，全部组件经过broker进行消息的收发，设计到注册与发现机制。 mesh是基于服务的注册与发现，消息发送须要找到对方的agent，再实现两个agent之间的通讯。
broker方案设计核心在于，broker须要管理注册的服务、路由的管理、数据的采集等这些核心功能，相似于微内核的内核自己理念同样。若是要扩展整个微内核架构能力，须要编写独立的service，以后和broker对接，在broker接收消息，处理完毕后发送消息。
那中心的broker负载过高如何扩容呢？由于broker自己具备服务调用的数据采集能力，因此能够从这里采集，做为扩缩容的参考，通过分析后，能够调用k8s的api实现pod的扩缩容了。
咱们能够发现，这套围绕于内核的核心设计以及扩展service的思想很是的云原生，好比上层业务系统想要调用存储服务，微内核系统能够对外提供一个消息存储的api，而这套api能够按需扩展是基于redis、仍是tair或是其余kv，为服务标准化和可替代性提供了很好的基础，对上云操做很是友好，也就体现了云原生的灵活性。
中心化转发和点对点发送，两个方案各有优缺点，架构就是一个取舍的过程，咱们须要结合本身系统的特色和体量决定选择合适的方案。
总结
微内核架构对于咱们作微服务设计，或是偏中台、平台系统设计提供了很是好的参考建议，好比对于微服务边界的划分，咱们彻底能够参考操做系统的设计，通过几十年的发展，其设计之精妙已经被验证了，很是稳定，功能划分也很是合理。