不同的物理设备、使用场景以及客户需求造就了不同类型的操作系统，而软件开发、部署和运维架构与技术更新迭代、世界范围内开源软件蓬勃发展、以及商业市场激烈竞争等因素促进了操作系统多样化的趋势。但操作系统的多样性仿佛是一片绚丽缤纷的花园，虽然丰盛多彩，却也暗藏荆棘。不同操作系统之间存在着生态割裂、社区离散、商业壁垒等诸多问题，本文仅从技术角度分析操作系统多样性给用户和开发者带来的主要消极影响与有益探索：
基于混合部署架构实现管理域+HMI域+实时域
IPC
|
Pipe
|
只能以半双工的形式在进程间进行通信
|
Signal
|
侧重更具信号触发控制进程的行为
|
|
Message Queue
|
传输信息量载体较少
|
|
Signal
|
主要用于信号量值的变化来控制多进程互斥的访问共享资源
|
|
Sharing Memory
|
支持大量数据且速度快，但多个进程对共享内存块的访问必须以互斥形式进行，需要信号量机制配合
|
|
RPC&xBus
|
Socket
|
网络操作系统必不可少的基础技术
|
Desktop COmmunication Protoco
|
主要利用其控制KDE应用程序
|
|
D-Bus
|
设计被用来作为用户交互接口与系统服务之间的解耦和通信，以及系统服务之间的通信。
|
|
U-Bus：
|
类似于Linux桌面系统的D-Bus，KD-Bus：在内核里实现的D-Bus
|
|
FD-Bus
|
提供了分布式的进程间通信机制，支持跨主机的C/S通信; 不提供自发现、组网、跨协议等高阶特性
|
当前，我们需要的不仅仅是IPC机制，更需要提供跨平台的且功能丰富的中间件开发框架，比如支持复杂数据类型、使用服务名的自主寻址方式、安全策略等。分布式软总线被设计作为多设备终端的统一基座，为设备间的无缝互联提供了统一的分布式通信能力，实现了设备间无感发现和高效传输，为端边领域的互通和协同提供了可靠信道。
分布式软总线的核心功能可总结为发现、组网、连接和传输四个基本模块，此外，全量的分布式软总线还涉及启动与服务管理、安全子系统、分布式硬件等等，具体可参见下图，其中淡蓝色标记模块已完成从OpenHarmony往openEuler移植适配，深蓝色标记部分涉及分布式化改造，灰色标记部分当前状态为未完成移植适配工作。
分布式软总线起源于面向强交互的移动终端设备的OpenHarmony社区，其功能设计与内部实现并不能完全满足面向高可靠、高性能等需求的openEuler。因此，润和软件积极对其进行了功能强化、安全增强以及生态兼容等方面的优化改造，主要内容请参考下图。
此处用2个案例加以说明：
在移动或者家庭场景下，所有设备组网均在局域网同网段内，因此，OpenHarmony原生支持的分布式软总线不支持设备的跨网段联通。但是openEuler适用的场景往往基于业务或者安全需要而做了逻辑网段隔离，为了解决此类问题，必须支持跨子网段间发现、组网和通信。
在移动或者家庭场景下，无论体积大小或者算力强弱，设备一般均为有屏幕显示，因此OpenHarmony原生支持的分布式软总线基于PIN码验证组网的方式很好地契合了其强交互特征。但是openEuler适用的设备往往没有屏幕显示，因此，必须开发其它安全认证机制。
4）案例展示
案例1 分布式硬件（摄像头）跨平台算力协同
案例2 分布式屏幕（计算器）跨平台显示协同
案例3 分布式应用（计算器）跨平台计算协同
本文分享自微信公众号 - OpenAtom openEuler（openEulercommunity）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
