什么是微内核架构设计？( 二 ) _微内核架构

总体下来，内核设计有三个形式，如下：

文章插图

二、插件化(Plug-in)架构设计上面聊了微内核在操作系统内核设计中的作用，接下来我们就开始讨论更通用的插件化架构设计，毕竟这个词大家都明白。
插件化架构非常简单，就两个核心组件：系统核心(Core System)和插件化组件(Plug-in component) 。Core System负责管理各种插件，当然Core System也会包含一些重要功能，如插件注册管理、插件生命周期管理、插件之间的通讯、插件动态替换等。整体结构如下：

文章插图

插件化架构对微服务架构设计帮助非常大，考虑到隔离性，插件可能是以独立进程方式运行的，那么这些进程如果扩展到网络上，分布在众多的服务器上，这个就是微服务架构的原型，所以了解微内核的同学都不屑于和你讨论微服务架构，相信你也明白了，除了IT传统的鄙视链因素，原理上确实就是这么回事。
回到微服务架构设计场景，我们将Plug-in component重新命名为服务(Service) ，这个和微内核设计中的服务也差不多，这个时候微服务和微内核就差不多了，都涉及到服务注册、管理和服务之间的通讯等。那我们看一下微内核是如何解决服务之间的通讯问题的？以下摘自维基百科：

因为所有服务行程都各自在不同地址空间运行，因此在微核心架构下，不能像宏内核一样直接进行函数调用。在微核心架构下，要创建一个进程间通信机制，通过消息传递的机制来让服务进程间相互交换消息，调用彼此的服务，以及完成同步。采用主从式架构，使得它在分布式系统中有特别的优势，因为远程系统与本地进程间，可以采用同一套进程间通信机制。

也就是说，采取的是基于消息的进程间通讯机制。消息最简单，就两个接口：send和receive ，消息发送出去，然后等着收消息，处理后再发消息就可以了，这里大家应该也知道了，这个是异步的。回到插件化架构设计中， Plug-in组件设计包含交互规范，也就是和外界相互通讯的接口，如果是基于消息通讯的话，就是send和receive接口，可以说是非常简单的。
但是这里还有一个问题，那就是进程间通讯。你可能会问，这个有什么好疑问的，就是两个进程之间相互发消息呗。但是这里有一个最大的疑问，那就是进程间通讯是否有第三者介入？如下图：

文章插图

当然在操作系统的内核设计中，一定是通过内核进行转发的，就是我们理解的总线架构，内核负责协调各个进程间的通讯。这个大家也能理解，如果进程A直接发给另外一个进程B ，必然要了解对应的内存地址，微内核中的服务是可以被随时替换的，如果服务不可用或者被替换，这个时候要通知和其通讯的其他进程，是不是太复杂？刚才已经提到，只有send和receive接口，没有其他通知下线、服务不可用的接口。在微内核的设计中，一定是通过总线结构，进程向Kernel发送消息，然后kernel再发送给对应的进程，这样的一个总线设计。实际上很多应用内部在做Plug-in组件解耦时，都会使用EventBus的结构，其实就是总线的设计机制。
为何婆婆妈妈说这些？因为非常关键。分布式的进程通讯是微服务的核心，我们理解的服务到服务的通讯，就是服务A启动监听端口，服务B会和服务A建立连接，然后两者通讯即可。这个方式和微内核设计中内核负责消息接收和转发的总线架构设计是不一样的。如采用HTTP ， HSF等通讯协议时，相当于kernel告知通讯的双方各自的地址，然后它们之间就可以通讯了。然后就没有Kernel什么事情了，也不会用到什么总线的结构设计，这个就是传统的服务发现机制。