Fast Distributed Bus - FDBus：高速分布式总线以及中间件开发框架

摘要

本文描述了一种新型IPC机制：Fast Distributed Bus(FDBus)。从IPC（Inter-Process Communication）角度，FDBus和广泛使用的D-Bus(Desktop Bus)有类似之处，但是FDBus具有自身优势，功能更齐全，性能更高，使用便利，除了支持主机内的IPC，还能在多个主机之间组网，同时可以定制安全策略，支持不同的安全等级。FDBus构筑于socket（Unix domain和TCP）之上，采用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开发的自动化测试设备

FDBus已开源，采用Apache License授权。下载地址：

https://github.com/jeremyczhen/fdbus.git

背景介绍

不像其它内核，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 MiddlewarE over IP）。SOME/IP同样是一套比较完善的IPC规范，甚至是专门为车载领域开发的。但是就如名字里暗示的，它是基于IP层的，在单机上性能并不好。且SOME/IP开源的实现也很少，GENIVI组织贡献了vsomeip，但活跃度非常低，GENIVI本身就是个松散的组织，参与者多，开发者少。与DBus不同，SOME/IP是为车载打造，应用范围很窄，不可能指望形成一个活跃的社区聚集一群专业的程序员来维护开放的源码（这大概也是GENIVI不成气候的原因）。最后很可能的情况是，不得不花钱购买闭源软件。

FDBus就是为解决以上各种问题而开发的，具有如下特点：

• 分布式：基于TCP socket和Unix Domain socket（UDS），既可用于本地IPC，也支持网络主机之间的IPC
• 跨平台：目前已在Windows，Linux和QNX上验证
• 高性能：点对点直接通信，不通过中央Hub或Broker转发
• 安全性：能够为server的方法调用也事件广播配置不同等级的访问权限，只有权限足够高的client才能特点方法和接收特定事件
• 服务名解析：server地址用名字标识，通过name server注册服务和解析名字，从而server可以在全网络任意部署
• 支持跨平台的中间件开发框架，包括如下组件：
  1. Thread模型
  2. Event Loop
  3. 基于Job-Worker的线程间通信
  4. 基于Event Loop的Timer
  5. 基于Event Loop的watch
  6. Mutex
  7. Semaphore
  8. Socket
  9. Notification
• IPC采用Client-Server模式，支持如下通信模式：
  1. 带超时的同步请求-答复
  2. 带超时的异步请求-答复
  3. 无答复的命令请求
  4. 注册-发布模式，实现多点广播
• IPC消息采用Protocol buffer序列化和反序列化，支持IDL代码生成，高效简便；也支持raw data格式，便于大量数据传输
• 可靠的心跳和重连机制，确保无论网络状况如何，无论哪个服务重新上线或重启，通信各方都能保持连接
• C++实现，易于开发和维护

主流IPC框架对比

底层

性能

同步请求

异步请求