【架构设计】领悟微内核+插件化的代码设计之美

在阅读内部名字服务的源码时，看到了微内核+插件化的设计实现，非常有利于功能的横向扩展。本文以开源的 tcb-admin-node.js 库的扩展功能为例，记录下插件化的思想以及在 tcb 中的实现。

认识微服务架构

定义：微内核架构（Microkernel Architecture），也被称为插件化架构（Plug-in Architecture），是一种面向功能进行拆分的可扩展性架构，通常用于实现基于产品的应用。

微服务架构内部包括核心系统和插件模块：

• 核心系统：负责与业务功能无关的通用功能，例如插件通信、插件管理等
• 插件系统：负责某个具体业务功能，例如图像检测、短信登录等

核心系统比较稳定，改动低；插件系统改动频繁，能够快速扩展。

核心系统设计关键

在《微内核架构》中提到，核心系统的设计关键主要体现在“处理插件”上：

• 插件管理：注册插件的 api、加载插件的时机等
• 插件连接：插件接入核心系统的方式，能够调用核心系统的一些 api
• 插件通信：插件间相互调用

实战：tcb-admin-node

上面说了这么多，还是配合代码才能更好理解这种设计的好处。以 tcb-admin-node.js 为例，它不完全是基于微内核的思路进行设计的，但是在扩展能力这块的设计，和微内核思想有着异曲同工之妙。

打开项目根目录下的index.js文件，可以看到挂在 Tcb 原型链上的 registerExtension 和 invokeExtension 方法，如下图所示：

registerExtension 负责注册插件。invokeExtension 负责按照名称调用插件，并且传入 Tcb 对象。

根据tcb 扩展能力文档，可以看到，插件的注册是在init之后：

const extCi = require("@cloudbase/extension-ci");

tcb.init({
    env: "您的环境ID"
});

tcb.registerExtension(extCi);

对于扩展@cloudbase/extension-ci 来说，它需要暴露 name 属性，以及 invoke 方法。从 npm 下载的源码中可以看到：

function invoke(opts, tcb) {
    // ... 具体的业务逻辑
}

exports.name = "CloudInfinite";

exports.invoke = invoke;

name 属性作为拓展的标识，在核心系统调用时需要用到；invoke 函数封装具体的业务逻辑，tcb 参数由核心系统注入，可以调用其上方法，例如云函数、云数据库读写、云存储等等。

看到这里，应该可以体会到微内核+插件化的设计的优点了。在 js 中，配合 es6 module，还能起到“源码瘦身、按需加载”的作用。