什么是微内核架构

什么是微内核架构

相信大家都听说过微内核架构,也或多或少做过一些类似于微内核架构的设计,为了可以更好的设计出微内核的架构,我们了解下什么是微内核架构。

说到微内核架构,大家首先会想到的是Eclips、IDEA、OSGI、Spring Plugin、SPI等,这些都是我们熟知的微内核架构。有了微内核架构,我们可以更好的定制和控制流程,所以微内核架构的设计思想经常在做配置化中台项目的方案中出现的。

微内核架构实现主要是插件化思想(Plug-in),是一套插件体系,最早的插件化方法是应用在操作系统之上,久而久之就有了微内核设计这一思想。

了解微内核,需要先了解这个“内核”。

在操作系统中,内核围绕于操作系统的核心功能,比如时钟中断、进程创建与销毁、进程调度、进程间通信等内核态的动作。而文件系统、内存管理、设备驱动等都被视为非内核能力,这部分会被放在用户态空间。

微内核是相对于宏内核而言,宏内核包含了很多的底层程序功能,做的事情非常多,而且不是可拔插的,修改任意一个功能点,都需要整个程序联动,而且有可能引入一个bug,导致整个内核不可用,类似于一个功能复杂的单体系统,每次变更和交付成本都非常高,风险也非常大。

而微内核只围绕于核心功能设计,他的功能实现都是相互独立的,其他非核心功能是通过用户态的独立进程以插件的方式加入进来的,微内核引擎负责管理进程、调度进程、进程之间通信。某一个功能出现问题时,由于其是独立的进程,不会对其他进程产生影响,也不会导致内核不可用。

微内核中,多个进程协调通信,需要进行系统调用,系统调用需要切换堆栈及保护进程现场,过程比较耗时。宏内核(也就是用户态)中,是通过函数调用完成各个模块之间合作,所以宏内核较微内核效率更高。

通过操作系统微内核概念,可以类比到业务系统。一个系统,特别是经过微服务拆分之后的系统,都会服务于某个“内核”,多个核心功能通过微服务的方式拆分,服务之间通过通信交换数据。通过微内核解决了快速交付问题,实现了代码隔离,控制风险点的目的。

而考虑到扩展性,我们需要定义出内核的骨架,并开放出plugin,以实现个性化扩展。这样的微内核架构,我们可以便于定制,改动小,进而实现热更新,这也是微内核架构的主要价值。

微内核架构设计

在微内核架构中有两个核心组件:系统内核、插件化组件。

系统内核:主要解决的是内核的核心功能,比如插件的注册与管理、插件生命周期管理、插件之间通信、插件的热加载与替换。

结构如下:

基于微内核的插件化设计,我们可以实现组件隔离,每个插件可以以独立jar包或独立进程运行,这些插件组件进程可以独立部署在分布式网络上,实现水平扩展,某种程度就像我们的微服务治理体系,有独立部署的微服务进程,也有中心治理的注册中心与配置中心。

在操作系统中,微内核与宏内核通信方式上有如下区别:

微内核架构下,组件之间的通信也是基于消息的,比如每个组件对于消息处理有两个能力:收(receive)、发(send)。

那两个进程之间通信,是否需要一个三方中介呢?比如这样:

在操作系统中,消息的通信是基于内核转发的,也就是我们经常听说的消息总线架构,内核负责协调各个进程的通信,比如进程A想要发送消息给进程B,需要知道B对应的内存地址。进程向内核发送消息,内核再将消息发送给对应的接收进程,这就是一个总线通信过程。

在很多微内核架构设计实现上,组件之间都可以通过EventBus实现Plug-in之间的解耦,也就是借鉴了总线的设计。

在微服务架构的通信实现上,在SOA时代,有类似于消息总线的概念。但微服务是进程之间的直接调用,没有了这个所谓的总线。

但是如果引入了一个中心化的服务注册与发现中心,就可能也会有个所谓的内核中转:

在插件化系统中,组件之间不直接通信,而是借助于一个中心化的内核系统进行转发。这种设计思想非常类似于操作系统的内核转发实现,插件之间隔离、透明。某个组件下线或替换,其他组件不需要感知。

这样的架构会存在于一些其他的问题。首先,这个中心化的转发中介变成了单点,其可用性严重影响了整个系统的可用性。当中心化系统变成单点转发,就存在对应的性能问题。

对于远程进程调用的性能优化,我们可以想到这几点:

  1. 采用高性能的二进制协议代替http1.x协议,因为http1.1的文本协议性能较差;

  2. 采用类似于零拷贝机制,实现快速网络包转发,而不需要做内核态与用户态的转换;

  3. 引入好的网络硬件,比如RDMA;好的协议,如UDP、QUIC等;

  4. 选择不同的通信方式,比如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,为服务标准化和可替代性提供了很好的基础,对上云操作非常友好,也就体现了云原生的灵活性。

中心化转发和点对点发送,两个方案各有优缺点,架构就是一个取舍的过程,我们需要结合自己系统的特点和体量决定选择合适的方案。

总结

微内核架构对于我们做微服务设计,或是偏中台、平台系统设计提供了非常好的参考建议,比如对于微服务边界的划分,我们完全可以参考操作系统的设计,经过几十年的发展,其设计之精妙已经被验证了,非常稳定,功能划分也非常合理。

### 分析不同系统架构的脆弱性 #### 分层架构 分层架构通常分为表示层、业务逻辑层和数据访问层。这种架构的优点在于清晰的责任划分,便于维护和扩展[^1]。然而,它的脆弱性体现在以下几个方面: - **性能瓶颈**:每一层之间的交互可能增加延迟,尤其是在高并发情况下。 - **复杂性提升**:随着层数增多,跨层调用可能导致调试困难。 - **安全性不足**:如果没有严格控制各层间的数据流动,可能会引入安全隐患。 ```python # 示例代码展示分层架构中可能出现的问题 def process_request(request_data): validated_data = validate_layer(request_data) # 表示层验证 processed_data = business_logic(validated_data) # 业务逻辑处理 result = data_access(processed_data) # 数据库操作 return result # 返回结果 ``` #### C/S 架构 (客户端/服务器架构) C/S 架构的特点是将应用程序的功能分布在客户端和服务端之间[^3]。其优点包括高性能和良好的用户体验,但也存在以下脆弱性: - **单点故障风险**:服务器作为集中式节点,一旦出现问题会影响整个系统。 - **升级难度大**:每次更新都需要同步修改客户端和服务端。 - **网络安全威胁**:由于客户端直接连接到服务端,容易遭受攻击。 #### B/S 架构 (浏览器/服务器架构) B/S 架构简化了客户端的要求,只需支持标准浏览器即可工作。尽管如此,它也面临一些挑战: - **依赖网络质量**:任何断网都会影响用户的正常使用。 - **负载均衡压力**:大量用户同时请求会加重服务器负担。 - **敏感信息泄露**:HTTP 请求过程中可能存在未加密传输的风险。 #### 事件驱动架构 事件驱动架构通过异步消息传递来协调组件行为[^2]。虽然提高了灵活性和解耦程度,但仍需注意以下问题: - **调试困难**:复杂的事件链条使得定位错误变得棘手。 - **资源竞争**:多个消费者争夺同一事件源时可能发生冲突。 - **潜在死锁**:不当的设计可能导致循环等待状态。 #### MVC 架构 (模型-视图-控制器) MVC 是一种经典的 Web 应用开发模式,强调分离关注点。不过,在实际运用中有如下局限: - **过度抽象**:对于小型项目来说可能是多余的开销。 - **学习曲线陡峭**:初学者难以理解其中的关系及其最佳实践。 - **实时性差强人意**:当面对频繁变化的状态显示需求时表现不佳。 #### 微内核架构 微内核架构的核心思想是最小化内核功能并将其余部分外包给插件或扩展模块。这带来了极大的适应性和可配置性,同时也伴随着这些隐患: - **启动时间较长**:加载必要的外设需要额外的时间成本。 - **兼容性考验**:确保所有附加组件能够协同运作是一项艰巨的任务。 - **权限管理难题**:如何合理分配内外部单元的操作许可成为焦点之一。 #### 微服务架构 微服务提倡独立部署的小型服务集合共同完成整体目标[^2]。这样的设计理念固然有诸多好处,比如快速迭代能力和高度自治性,但同样隐藏着不少缺陷: - **分布式事务复杂度上升**:保持一致性变得更加具有挑战性。 - **监控与追踪不易**:海量的服务实例让日志收集和异常捕捉更加繁琐。 - **团队协作障碍**:每个小组负责各自的片段,沟通成本显著提高。 --- ### 总结比较优缺点、安全性及稳定性 | 架构名称 | 主要优势 | 可能存在的劣势 | |----------------|---------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------| | 分层架构 | 结构分明易于理解和维护 | 层次过多导致效率下降 | | C/S 架构 | 高效稳定适合桌面应用 | 升级麻烦且易受黑客侵袭 | | B/S 架构 | 减少客户端安装负担 | 对互联网环境要求较高 | | 事件驱动架构 | 提升响应速度促进松散耦合 | 错误排查难于传统顺序执行 | | MVC 架构 | 清晰区分界面逻辑与后台算法 | 不适用于简单任务 | | 微内核架构 | 增加系统的弹性和可伸缩性 | 初始设置耗时长 | | 微服务架构 | 加速创新周期降低失败影响范围 | 维护全局视角下的连贯体验较为艰难 | ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值