post wordpress apiseo中心

▎RPC & DDS-RPC

RPC：Remote Procedure Call，远程过程调用。

远程过程调用是一种进程间通信，它允许计算机程序在另一个地址空间中执行子程序，就好像用别人的东西像用自己的一样，常用于分布式系统。

远程过程调用常用的通信方式为Request/Reply，即请求方发送Request向另一个地方请求执行某程序，被请求方执行相关操作后，返回Reply给请求方。

DDS广泛应用于分布式系统中是以数据为中心的发布/订阅，消息是单向从Publisher发送到Subscriber的，但是大型分布式系统通常不止是一种通信方式，例如Request/Reply这种远程调用的通信方式，使用多种中间件框架通常会带来更加复杂，高成本等问题。因此，为了实现可移植性和互操作性，需要在DDS基础上开发Request/Reply通信的标准机制——DDS-RPC。

DDS-RPC是OMG组织在2017年4月推出的DDS扩展协议，目前仅有v1.0版本。

▎DDS-RPC架构

如何利用DDS的基础模块实现RPC中Request/Reply通信模式呢？

简单来说，由于DDS是单向传输Topic的，满足双向的Request/Reply通信只需要将单向的两个Topic关联起来，标记发送Reply的消息是回复哪个Request的。

在DDS-RPC架构中（如下图），Client端和Server端都具备一个Data Writer和Data Reader。Client端利用Data Writer写Call Topic（Request），Server的Data Reader可以读取Call Topic并做处理，之后调用Server的Data Writer写Return Topic（Reply），并由Client的Data Reader读取。Call Topic在总线上发送时会携带GUID+SN，当Return Topic发送时，也会携带相对应的Call Topic的GUID+SN，表明此条报文回复的是哪条请求。

▎服务映射

根据上面的DDS-RPC架构描述，DDS可以把Request和Reply对应的Call Topic和Return Topic联系起来实现RPC，那么RPC的服务如何映射到这两个Topic上呢？

DDS-RPC中定义了两种映射方式：Basic Service Mapping和Enhanced Service Mapping，这两种映射方式都需要对Topic名称和Topic Types进行映射。

Topic名称

三种指定Topic名称方式：

• 默认Topic名称：<topic_name>::=<interface_name>““<service_name>””[“Request”|“Reply”]|<user_def_alpha_num>
• 注释的方式指定Request Topic和Reply Topic
• 调用相关函数指定Topic名称

Topic Types

- Basic Service Mapping

• Enhanced Service Mapping

▎服务发现

在DDSI-RTPS中，Reader和Writer需要先完成服务发现，才能进一步发送定义的Topic数据，DDS-RPC中的Call Topic和Return Topic对应的Reader和Writer也需要先完成服务实现，这个过程依赖RTPS对服务发现互操作性的要求。

Basic Service Mapping

依赖DDSI-RTPS内置Topic进行服务发现，可能会导致丢失Reply。

Enhanced Service Mapping

依赖DDSI-RTPS内置Topic进行服务发现，但是对Topic数据进行了扩展，能保证Client发送Request之前，Client的Reader能够与Server的Writer完成服务发现。

▎小结

DDS-RPC定义了在DDS基础上实现RPC通信的标准机制：用两个Topic分别对应RPC机制中的Request和Reply，并进行标记使得Reply与Request绑定，对于这两个Topic与RPC服务的映射也给出了要求。DDS-RPC结合了DDS的数据分发功能和RPC的远程调用功能，支持QoS设置，也满足了互操作性，丰富了DDS的使用场景。