AI 时代，微内核是否是一个很棒的软件架构

[litchinn]

过去很多场景下微内核显得很多余，你不能指望用户自己开发功能 但现在 AI 加持，用户完全可以自定义插件，使软件完全符合自身需求而不显得臃肿

[vsomeone]

微内核？你说的是微服务吧，微内核是操作系统的概念

[lujiaxing]

微内核是啥意思

[tanxnative]

事件驱动?

[lujiaxing]

哦 懂你意思了. 你是想说你只做一个类似 USB 接口的软件. 功能只要作为插件插在这个软件上就能实现相关的功能? 这确实是个好想法.

这一直都是个好设计.

但是这东西后面的结果就是:


你想的很好, 开一个你以为足够开放有足够强兼容性的接口实现某些你能想到的任何需求. 只需要接在上就行了. 你是业务的核心, 一切数据从你这里来, 一切数据从你这里走.

然后过几天新来了一个需求, 里面提到了一些新鲜的概念, 你开放出来的接口并不能兼容这个. 所以你升级了一个版本.
然后过几天新来了一个需求, 为了实现这个需求, 你的接口可能某些字段会与其他既有系统冲突. 你选择加个 if 判断如果是某个特定的插件就怎样怎样. 看似完美的解决了, 但是屎山化却已经从这里就开始了.

然后过几天新来了一个需求, 涉及到了更多更多的数据字段, 为了实现这个需求, 原来的接口已经不够用了. 然后你为了这个需求, 就只能公布了一些原来 internal 的东西. 你的微内核边界开始消解.

然后过几天新来了一个需求, 涉及到跟另外几个模块存在紧耦合的情况, 你原本设计的接口已经不足以支撑这么多特化的数据字段, 因此那几个模块之间开始绕过你这个微内核直接通信.

乱七八糟的通信开始越来越多, 逐渐的 你这个微内核的逻辑越来越复杂, 由原来的微内核变成了巨内核. 巨内核变成了整套系统里一座不起眼儿的屎山.

[lujiaxing]

然后一个新来的年轻架构师站在这座屎山之海的岸边, 望着这一群青藏高原一般的屎山, 突然有了一个想法:

诶, 如果从这些系统里抽出一个最核心的业务, 使其作为一个微内核, 让其他系统围绕这个微内核运行, 是不是就能解决这些屎山了呢?

[dododada]

@lujiaxing 你说的这个工业上很常见，其实就是个逻辑节点的自定义脚本，支持 js, python ，java ，c#之类的，但是这玩意儿也只有在系统开发的时候一次性调试完，后续再想改动可难了，没有文档，没有参数定义，没有逻辑说明

[litchinn]

https://www.geeksforgeeks.org/system-design/microkernel-architecture-pattern-system-design/

或者简单理解就是插件化系统
只要不是核心的就是可插拔的，好比 vscode

屎山问题：任何架构都很难避免

我最近自己用 AI 写了不少东西，也看了不少

过去软件开发，对于用户无法决定开发者路线的情况，如果你想使用这个软件你只能自适应，当然对于面向开发者的软件其实就存在一些插件化系统，只是插件化程度高低
但是 AI 现在完全可以解决这个问题，用户完全有能力修改部分系统的功能、

当然任何架构的流行还取决于很多因素，例如如何创收，安全性等等，这里仅仅讨论下微内核或者插件化能否进入更广泛的软件市场

[lujiaxing]

@dododada 工业系统可以这么搞的原因是工业系统每个模块都是固定的. 机械臂是不能跳极乐净土的, 传感器是感受不到人在前面反复横跳的, 机床是不能拿来画画的, 锻造机是不能跑马拉松的. 工业系统最大的好处就是硬件系统限制了产品经理的脑洞. 他不会有那么多奇奇怪怪的需求. 所以工业系统相对来说代码逻辑简单, 没有什么业务逻辑, 基本都是算法. 算法那玩意从来都是固定的那些玩意, 一百年前就存在的线性代数公式跟物理公式, 只要是同样的系统, 代码几乎都不变.

[Rorysky]

我觉得不存在这个场景需求

[pangdundun996]

微内核+插件化架构更适合一些确定的业务场景,比如工业软件. 不是所有业务都适用的

[maichael]

不如连插件也砍掉，用户通过 AI 直接完成他要的需求。

[cyrivlclth]

哦，那内核应该是 AI 大模型吧，你们全都是插件，包括你所说的软件，都是调模型。。。