opendds初入门之考虑为什么要用opendds

受限于场景和历史因素，在考虑业务方案时直接以opendds为中心进行了探索，但是考虑到它的本质也就是基于基本的tcp/ip的一套通信框架，我们的业务使用也仅仅是它的通信能力。

如果只是使用opendds的通信能力，只需要它的发布订阅逻辑，我为什么要用这么复杂的opendds呢？（本质就是通信能力，基于tcp或者udp）

1. 为什么opendds最适合

首先考虑opendds的能力：

支持基于corba的面向对象的rpc交互，支持udp/tcp/共享内存/rtps自动发现/广播等传输方式，支持qos服务质量控制，底层支持线程池和reactor处理，内置主题提供了对上层能力的支持，支持idl格式提供面向数据的业务交互（有数据模型的概念）。

拆分说明：

====》支持udp，低延迟，强实时 （可通过qos进行配置传输质量）。
====》rtps自动发现（传统的发布订阅一般都有个注册中心）。
====》reactor处理网络（高效处理网络，但是其他组件一般也都支持）。
==》面向数据的业务交互（这里主要说的是提供了idl定义数据的方式，以及有topic概念，底层处理）=》对比其他框架的使用，topic的含义是不一样的，除此之外，面向数据可以用上层协议适配替换(如proto),但是需要上层适配处理。

opendds中可以发布多个topic，谁订阅谁才能收到，按订阅topic分开数据模型处理。

====》支持qos服务质量配置 （这个就挺好了，淡化了qps的概念，满足一定业务需要）。
====》内置主题 （自带的分布式“注册中心 + 元信息广播“，同时，提供了一些能力，让上层可扩展）

这里又抛开一个话题，opendds对topic的发布和订阅，第一：如何设计基于topic的业务模型。 第二：关于多个topic的发布，如何进行处理（每个topic都有对应的监听回调处理，还是线程单独循环read）第三：基于topic的发布订阅上，设计业务层的交