前言
软件技术中的“云边端”是什么？“云边端”指的是云平台+边缘计算+终端，是现在比较流行的一种架构设计方法，主要用来表达业务部署层面的架构方案，“云边端”是一种架构风格。
不同公司不同行业的业务是不同的，即使相同公司相同行业对于相同业务的认知也是不同的；在“云边端”的架构设计方案中，有没有一种通用的架构设计方法？答案是有的，本次通过架构风格和模式的方法，总结一种在“端”上通用的设计方法。
正文
架构风格和模式是一种比较好的架构设计定义方法，风格和模式的详细说明见架构风格和模式。
“MPM”端架构设计方法描述如下：
架构风格：微（M）核心 + 插件（P）化 + 消息（M）总线，微核心定位容器负责加载多个插件并管理插件生命周期。插件内部通过方法调用实现高内聚，插件间采用消息订阅发布方式通讯实现低耦合。
架构模式：Android终端使用Context和Activity方式实现微核心对插件生命周期的管理，使用Interface/Abstract Class方式实现插件抽象定义并使用Event Bus Framework实现插件间消息通讯。
微核心
微核心有一个类似的概念“微内核”，微内核有一个对应的概念“宏内核”，微内核和宏内核是操作系统OS层面的两种设计方法，Linux当年也有微内核VS宏内核的争论，那么有个问题HarmonyOS是什么内核？
微内核VS宏内核对比，内核是建立计算机软件与硬件之间通讯的平台。
| 对比 | 微内核 | 宏内核 |
|---|---|---|
| 定义 | 系统服务从内核中分离出来 | 内核直接包含相关系统服务 |
| 扩展性 | 良好扩展性，系统服务可以单独进行升级替换，不需要改变整个操作系统 | 一般扩展性，系统服务调整需要修改内核 |
| 效率 | 一般效率，内核和系统服务无法直接通信导致效率变低 | 良好效率，内核和系统服务直接通讯减少调用层级 |
| 代表系统 | Windows | Linux |
微服务架构也算是微内核在服务器Server领域的一种应用方法
微核心的优缺点和微内核类似，在MPM设计方法中微内核的主要职责是负责终端软件生命周期管理，一个终端软件的生命周期类似如下：
应用初始化阶段负责“插件”的发现/注册，应用停止阶段负责“插件”的卸载/注销。
插件化
软件研发中有两个重要的演化概念 - “插件化”和“组件化”，插件和组件的区别是什么？
插件的生命周期需要通过微核心进行管理。
消息总线
消息总线（Message Queue，MQ）是一种跨进程的通信机制，用于在不同上下文Context之间传递消息，优点是实现不同模块间的解耦，缺点是增加调用层次复杂度变高。消息总线是一种常见的“逻辑+物理”解耦的消息通信服务，消息发送上游只需要依赖消息总线，逻辑上和物理上都不用依赖其它业务服务。
案例
背景：MPM架构设计风格理论上可以应用在“终端”，也可以应用在“服务器端”，下面以Android终端为例总结。
| MPM设计 | Android |
|---|---|
| 微核心 | 采用Application作为微核心加载入口，并通过ApplicationContext作为基础设置Context传递进核心 |
| 插件化 | 采用Java Interface定义插件Plugin接口，并且各个插件需要实现Plugin接口并实现生命周期回调 |
| 消息总线 | 采用Android Green Event Bus作为消息总线服务，在Plugin接口中通过回调实现不同插件间的消息订阅发布 |
Android 终端的分层架构设计图
分层架构设计映射到代码层面
package
.kernel
Container
Plugin
Message
.system
Crash
EventBus
Log
.common
MCU
NFC
OTA
APM
...
总结
为什么这种架构设计是“端”通用的设计方法？软件设计的六字真言如下
高内聚低耦合
MPM设计方法有如下优势
- 通过插件Plugin实现功能内聚
- 通过消息队列Message实现插件间的低耦合
- 通过微核心MicroContainer实现系统层和上层的模块的依赖倒置
基于上面这些点这种架构设计方法拥有良好的扩展性和内聚性，在“云边端”设计方法中，云和边也都有一定程度通用的设计方法。
