管理手机网站,荆门网络推广,商标注册查询平台,广州做网站的简介#xff1a; 作为一名Java程序员#xff0c;相信同学们都听说过微内核架构设计#xff0c;也有自己的理解。那么微内核是如何被提出来的#xff1f;微内核在操作系统内核的设计中又有什么作用#xff1f;本文从插件化(Plug-in)架构的角度来诠释微内核架构设计#xf… 简介 作为一名Java程序员相信同学们都听说过微内核架构设计也有自己的理解。那么微内核是如何被提出来的微内核在操作系统内核的设计中又有什么作用本文从插件化(Plug-in)架构的角度来诠释微内核架构设计通过微内核架构和微服务架构的对比分享其对微服务设计的参考意义。 关于微内核架构设计现在比较热听起来好像是操作系统内核相关的作为Java程序员操作系统内核那么遥远的事情好像和我们没有什么关系。但是如果我说微内核其实就是插件化(Plug-in)架构你一定会一脸疑惑“你居然向Java程序员解释什么是插件化架构我每天都在用啊Eclipse、IntelliJ IDEA、OSGi、Spring Plugin、SPI等哪个不是插件化架构。我的一些项目也是采用插件化设计的如使用插件实现流程控制定制等等”。但是别着急即便是我们每天都在使用的技术而且大多数人也都知道如果我们能将其阐述得更清楚并且能从中发现一些问题做出一些优化有助于以后的架构设计那么大多数人在日常的设计和开发中都能受益岂不是更好。现在我们就来聊一聊微内核架构设计。
一 微内核设计之操作系统内核
微内核设计其实就是插件体系。我们都知道操作系统内核诞生得比较早所以插件化最早被用在内核设计上于是就有了微内核设计这一称呼。
微内核是这样一种内核它只完成内核不得不完成的功能包括时钟中断、进程创建与销毁、进程调度、进程间通信而其他的诸如文件系统、内存管理、设备驱动等都被作为系统进程放到了用户态空间。说白了微内核是相对于宏内核而言的像Linux就是典型的宏内核它除了时钟中断、进程创建与销毁、进程调度、进程间通信外其他的文件系统、内存管理、输入输出、设备驱动管理都需要内核完成。
也就是说微内核是相对宏内核而言的宏内核是一个包含非常多功能的底层程序也就是我们现在讲的Monolith。它干的事情非常多而且不是可插拔的修改一些小的功能都会涉及到整个程序的重新编译等比如一个功能出现了一个小bug可能导致整个内核都出问题。这也是很多人将Linux称为monolithic OS的原因。而微内核只负责最核心的功能其他功能都是通过用户态独立进程以插件方式加入进来然后微内核负责进程的管理、调度和进程之间通讯从而完成整个内核需要的功能。基本一个功能出现问题但是该功能是以独立进程方式存在的不会对其他进程有什么影响从而导致内核不可用最多就是内核某一功能现在不可用而已。
微内核就是一个运行在最高级别的程序片段它能完成用户态程序不能完成的一些功能。微内核通过进程间通信来协调各个系统进程间的合作这就需要系统调用而系统调用需要切换堆栈以及保护进程现场比较耗费时间而宏内核则是通过简单的函数调用来完成各个模块之间的合作所以理论上宏内核效率要比微内核高。这个和微服务的架构设计一样我们将Monolith应用划分为多个小应用后系统的设计就变得比较复杂了之前都是应用内部函数调用现在要涉及网络通讯、超时等问题同时响应时间会被拉长。
聊到这里相信大家对微内核和宏内核已经有了一个大致的了解看起来各有千秋。但是宏内核有一个最大的问题就是定制和维护陈本。现在的移动设备和IoT设备越来越多如果要把一个庞大复杂的内核适配到某一设备上是一件非常复杂的事情如果很简单的话那么把Linux内核适配到Android内核甚至到Tesla等车载系统基本上人人都可以做了。
因此我们更需要一个微内核的架构设计方便定制而且非常小可以实现功能的热替换或者在线更新等这就是微内核被提出来的核心需求。但是微内核有一个运行的效率问题所以在微内核和宏内核之间又有了Hybrid内核主要是想拥有微内核的灵活性同时在关键点上有宏内核的性能。微内核设计在理论上确实有效率问题但是随着芯片设计、硬件性能提升等这方面或许已经有了非常大的提升已经不再是最关键的问题。
总体下来内核设计有三个形式如下 二 插件化(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建立连接然后两者通讯即可。这个方式和微内核设计中内核负责消息接收和转发的总线架构设计是不一样的。如采用HTTPHSF等通讯协议时相当于kernel告知通讯的双方各自的地址然后它们之间就可以通讯了。然后就没有Kernel什么事情了也不会用到什么总线的结构设计这个就是传统的服务发现机制。
但是还有一种模式就是完全透明的插件化通讯机制如下图 Plug-in组件也就是微服务架构中的服务是不能直接通讯的而是需要Core System进行转发。这样做的好处和微内核架构一样插件相互之间无直接联系彼此之间非常透明例如服务A下线后完全不需要通知其他服务服务A被替换也不需要通知其他服务服务A从数据中心1到数据中心2也不用通知其他服务即便服务N和服务A之间网络不互通两者之间也能通讯。
这里有个问题性能问题。我们都知道两点之间直线段最短。为何要多绕一下到Core System呢这就是微内核和宏内核之间的争论之处使用函数调用非常快而进程间的消息通讯则是非常慢的但是这种通过中介进行通讯机制的好处也是非常明显的。那么如何提升这种基于总线的通讯性能呢当然有比如选择高性能的二进制协议HTTP 1.1这种文本协议就不需要了采用Zero Copy机制可以快速进行网络包转发好的网络硬件如RDMA好的协议如基于UDP的QUIC等。总结下来和微内核一样这种微服务通讯的性能是可以提升的。当然如果实在受不了这种性能在关键场景你可以采用Hybrid模式混入一些服务之间直接通讯的设计但只能在性能极致的场景中使用。
此外插件化架构中的插件组件是各种各样的通讯的机制也各不一样一些是RPC的一些是Pub/Sub的一些是无需ACK的如Beacon接口还有一些是双向通讯的等等。当然你可以选择不同的通讯协议但是这里有一个问题就是Core System需要理解这个协议然后才能进行消息路由。这个时候Core System需要编写大量的Adapter来解析这些协议例如Envoy包含各种filter来支持不同的协议如HTTP、MySQL、ZooKeeper等但是因此Core System就会变得非常复杂且不稳定。
另外可以选一种通用的协议Core System只支持这一种协议各个插件之间都基于该协议通讯至于服务和其他外部系统如何通讯如数据库、github集成等这些Core System并不关心那只是Service内部的事情。目前比较通用的协议是gRPC如K8s内部都会采用该协议另外Dapr也采用gRPC协议做服务集成因为gRPC提供的通讯模型基本可以满足大多数的通讯场景。当然另外一个就是RSocket提供更丰富的通讯模型也适用于Core System这种服务间通讯场景。对比gRPCRSocket可以运行在各种传输层上如TCP、UDP、WebSocket、RDMA等相反的gRPC目前只能运行在HTTP 2之上。
三 服务通讯的延伸
前面说到最好由插件化架构设计的Core System作为服务之间消息通讯的路由如果是这样的话就会产生一种Broker模式当然也有可能是Agent。这里大家一定会想到Service Mesh没错。当然你可以选择Agent Sidecar模式也可以选择中心化的Broker模式这两者的功能都是一样的只是处理的方式不一样而已。Agent基于服务注册和发现机制然后找到对方服务的Agent再进行两个Agent之间的通讯只是省掉服务之间的调用的开销。但是Broker是集中式的大家都向Broker发送和接收消息不涉及服务注册发现机制不涉及服务元信息推送就是总线结构。
我现在做的就是基于这种Broker的总线的架构设计在RSocket Broker中也是采用微内核架构设计当然未必做得最好 。RSocket Broker核心就是管理注册的服务、路由管理、数据采集等而不会添加过多的功能和Core System的设计理念一样只添加必须的功能。如果你要扩展整个系统更多的功能如发短信、发邮件、对接云存储服务等需要编写一个Service 然后和Broker对接一下再从broker那里收消息receive处理完毕后再发送send给Broker就可以了。总体结构如下 有不少同学会问当服务实例的负载太高的时候Broker如何实现动态扩容呢Broker会给你提供数据如一个服务实例QPS至于是否扩展你只需要写一个服务从Broker上采集数据分析后调用K8s API进行扩容即可Broker并不负载这些业务功能它只会添加非常必要的功能这个和Core System设计是一样的。
回到插件化架构的灵活性上如果系统中有一个KV存储的插件你只要遵循消息格式或者通讯接口就可以保存KV数据。但是你并不太关心是Redis存储的还是Tair存储的或者是云端的KV服务这就为服务标准化和可替换性提供了很好的基础这对应用上云或云原生化帮助非常大整个系统有非常大的灵活性。
四 总结
其实有非常多的书有关于微内核的介绍操作系统的图书就不用说了另外两本书也非常不错对通用架构设计帮助也非常大尤其是微服务的场景我也是参考这两本书写这篇文章的。 微内核架构设计对微服务设计有非常好的参考意义但是微服务有一个非常大的问题就是服务边界的划分对比操作系统已经发展几十年而且非常稳定功能划分非常容易。而微服务架构是为业务服务的虽然面对的业务可能已经存在上百年但是软件化、数字化和流程化并没有多少年加上现实业务的复杂性还有各种妥协个人认为微服务架构会更复杂一些。
作者开发者小助手_LS
原文链接
本文为阿里云原创内容未经允许不得转载
