FDBus框架架构分析

DBus (Fast Distributed Bus) 是一种 IPC 机制, 用于进程间通信或进程.
与 DBus 类似, 但是其功能更齐全, 新能更高, 使用便利, 除了支持主机内的 IPC, 还能再多个主机之间组网, 同时可以制定安全策略, 支持不同的安全等级.
tips: IPC 机制还有 fifo管道, share memory, semaphore, message queue, socket …
介绍
FDbus 基于 Socket (TCP 和 Unix domain) 之上, 采用 Google protobuf 做序列化和反序列化. FDBus 支持字符串形式的名字作为server地址. 通过 name server 自动为 server 分配Unix domain 地址和 TCP 端口号, 实现 client 和server 之间用服务名字寻址.

FDBus旨在为client-server之间提供面向连接，伸缩性强，安全可靠的IPC机制，进而发展成一套中间件开发框架，用于开发跨平台（Windows，QNX，Linux），多线程/多进程协同工作的中间件层。FDBus开发框架适用于在定制系统上开发交互复杂的分布式项目，包括：
基于Linux的车载ECU，包括仪表，娱乐主机，TBox，通过以太网连接的域控制器
Hypervisors上多个Guest OS之间的通信
为Android系统提供跨主机的IPC机制 （目前不支持Java API）
基于Linux的小型通信设备，例如家用路由器
其它基于Linux的工控设备，智能设备
基于Windows开发的自动化测试设备

背景
不像其它内核，Linux一直没有自己独特且好用的IPC机制。Windows，Mac OS，QNX都有这样的机制，即便是基于Linux的Android也开发了用于IPC的binder。Linux内核只提供一些最基础的组件-socket，pipe，message queue，shared memory等等。这也符合Linux的理念：每个工具只做一件事，把它做好。但是现实往往非常复杂，只做一件事远不能解决现实中遇到的问题，更不要说产品开发和大型商用项目。举个例子，订阅-广播是一个最基本的通信需求，但没有一个基础组件能够满足。

Linux实际上也有一个功能强大的IPC：D-Bus。它有完善的方法调用机制和事件广播机制；它还包含一些诸如安全策略和服务按需启动之类的高级功能。但对它最大的争议是性能：它的性能非常低，由于要经daemon中转，一个请求-回复需要来回复制十次消息，四次消息验证，以及四次上下文切换。因此它只能用于处理实时要求较低，数据量较小的控制命令和消息传递，否则还是得求助于基础IPC框架。为此有人将D-Bus写进内核，产生了KDBus，虽然性能上得到提升，但缺点也很明显，只能在单机上运行，不支持跨主机。在这种情况下Android的Binder也够用，况且Binder已经被内核接受了，KDBus至今还没“转正”。另外，无论是DBus还是KDBus，提供还是基础API，离“中间件开发框架”还有较大差距。但各行业包括车载领域对此都有越来越强烈需求，从而各种各样的DBus封装随之产生：Qt DBus，gDBus，commonAPI，DBus-C++… 但这些封装或者从属于大框架，或者缺少维护，总之使用起来并不友好。

在Linux以及以太网使用越来越广泛的车载领域，缺乏合适的IPC逐渐成为突出问题：公司原来自创的IPC机制由于技术落后，定制痕迹明显，已经无法满足分布式，高性能，安全性要求，却又无法为新平台找到合适的IPC机制，更别说基于IPC机制衍生出的中间件开发框架。以太网在车载的应用催生了SOME/IP（Scalable service-Oriented