本篇作为MD-SAL核心内容的第三篇,我们将介绍RPC和Notification,并从进程内外的通信开始,着重介绍远程过程调用和发布-订阅机制,然后分析MD-SAL的通信交互过程。
图片来自网络
一、通信基础
我们在编写单体程序的代码时,通常关注的是类和类之间关系的设计、类内的方法以及方法间的调用关系。在跨系统调用时,我们通常需要关注系统调用的接口,并根据接口文档进行编程,此时,涉及到跨系统、跨进程的调用。有关进程内外的通信分类大致如下:
单体程序代码通常是进程内通信,也就是本地过程调用,在同一CPU、同一内存空间进行。进程间通信最原始的莫过于Socket通信,但写起来相对于比较麻烦,人们希望能够“简单地”编程,后来基于“如何实现分布式计算的编程?”这一课题,在论文《Implementing Remote Procedure Calls》中给出了方案,即“调用远程机器上的程序就像在本地机器的地址空间中一样。隐藏分布式环境重要的部分:对参数和结果的编解码、消息传递以及保留过程调用的语义”,提出了RPC的解决方案。
间接通信的本质是“中介者”通信,是一种“间接”通信。它使得发送者和接收者不需要知道彼此的身份,并且不需要两者同时在线,一方不在线的情况下也可以通信,实现了空间上和时间上的解耦。间接通信比较流行的技术有:
l发布-订阅系统:“中介者”;
l消息队列系统:发送者发送消息到队列中,接收者从队列中提取消息。
1.远程过程调用RPC
1.1基础
RPC系统由User、User-stub、RPCRuntime、Server-stub和Server等5部分组成。其中,User、User-stub和RPCRuntime的实例在Caller machine上执行;Server、Server-stub和RPCRuntime实例在Callee machine上执行。简单调用的交互过程:
①User发起一个远程调用,则调用user-stub;
②user-stub负责封装方法和参数放置,并放置到一个或多个包中,然后请求RPCRuntime;
③RPCRuntime将这些包可靠地传输给被调用者机器,同时,调用进程被挂起并等待结果包的返回;
④Server的RPCRuntime将包传送给Server-stub;
⑤Server-stub解包,并本地调用会调用Server中相对应的程序逻辑;
⑥Server的逻辑执行完成,则将结果返回给Server-stub打包;
⑦Server-stub将结果传给RPCRuntime;
⑧Server的RPCRuntime将包将被传送回给User machine;
⑨User machine进行解包,User得到返回结果。
1.2 RPC框架
2.发布-订阅(publish-subscribe)
我们通过发布订阅的一个开源实现Kafka来讲述发布-订阅机制。Kafka是一种高吞吐量的分布式发布订阅消息系统。如下图所示,producer发布消息,consumer从消息队列中获取消息,broker用来接收发送的消息并将这些消息路由至队列中。生产者将数据发布到他们选择的主题。 生产者负责选择分配给主题中哪个分区的记录。
而消息是由Topic(主题)的形式组织起来的,一个Topic可以有0、1或多个consumer订阅。对于每个Topic,又可分为多个Partition(分区)。每个分区都是一个有序的,不可变的序列。 如下所示:
Partition中的每个记录都分配了一个称为偏移的顺序ID号,它唯一地标识每个记录。如下所示:
二、 MD-SAL ** RPC**
2.1.RPC定义
RPC采用YANG语言建模,使用“rpc”语句建模。我们以OpenDaylight示例-Toaster为例介绍:rpc make-toast定义RPC操作的方法名、input用于定义RPC操作的输入参数、output用于定义RPC操作的输出参数。如下图所示:
2.2.代码编写
1.生成代码
YANG文件定义好之后,我们执行命令:mvn clean install,可自动生成:
l ToasterService:接口文件,定义与yang数据模型定义的RPC方法;
l MakeToastInput:提供make-toast调用的输入参数。
l MakeToastInputBuilder:用于创建MakeToastInput实例的具体类。
2.实现接口
编写OpenDaylightToaster实现ToasterService接口,添加makeToast函数代码。
3. 注册RPC服务
使用blueprint注册RPC服务。
- 调用makeToast服务
我们可以使用POSTMAN测试工具,或者编写应用APP调用makeToast函数,调用的请求为:
请求方法:POST
URL地址:http://localhost:8080/restconf/operations/toaster:make-toast
请求Body体:
2.3 小结
从RPC的定义和代码编写不难看出,RPC的定义通过YANG语言来建模,RPC的访问可以通过RESTCONF协议进行,RPC的提供者通过blueprint来注册RPC服务。
三、MD-SAL Notification
3.1.Notification定义
在支持NETCONF协议的网络中,网络设备使用Notification消息向网络监控发送通知事件以说明网络设备的某种状态。OpenDaylight也采用了Notification消息通知,它被设计为一种发布/订阅模式。同样,我们以OpenDaylight示例Toaster来说明该机制。
在示例Toaster中,烤面包机不仅能烤面包,还能在没有面包的情况下,发送一个toasterOutOfBread通知,告知消费者现已无面包可烤。我们在YANG文件中定义这个通知,如下图所示:
3.2.代码编写
1.生成代码
YANG文件定义好之后,我们执行命令:mvn clean install,可自动生成:
l ToasterOutOfBread:为toasterOutOfBread通知定义DTO接口。
l ToasterOutOfBreadBuild:用于创建ToasterOutOfBread实例的具体类。
l ToasterListener:实现烤面包机通知消费者的接口,定义每种通知类型的接收方法。
2.生产者实现通知
3.生产者实现配置
OpenDaylightToaster需要访问MD-SAL的NotificationPublishService才能发送通知。 我们需要在blueprint文件中注入OpenDaylightToaster:
4.消息者实现
我们来看下如何从控制器中以编程方式访问ToasterService,实现消费者KitchenService。示例中采用了“硬编码”的方式。如下所示:
接下来,我们修改KitchenServiceImpl以实现ToasterListener接口和通知方法。
KitchenServiceImpl需要在MD-SAL的NotificationPublishService中注册才能接收通知。 我们需要配置blueprint文件:
这样就可以OpenDaylightToaster在发生OutOfBread事件时发送通知。
3.3 小结
Notification采用的是发布订阅机制,本例中生产者为OpenDaylightToaster,消费者为KitchenServiceImpl,中间代理为MD-SAL,具体为YANG和NotificationPublishService。如下图所示:
ToasterService接口通过YANG模型构建自动生成,OpenDaylightToaster是该接口的一个具体实现,通过blueprint实现关系的绑定。KitchenService理应采用YANG模型构建,但示例中采用的是硬编码的形式,在KitchenServiceImpl中直接声明ToasterService对象,如图中的①和①ɑ所示。无论是生产者还是消费者,都需要NotificationPublishService来进行消息的发布和订阅。
四、总结
文章写到这里,就将YANG、DataStore、RPC和Notification这3个在MD-SAL中非常重要的点讲述完了,在支持NETCONF协议配置的网络,还涉及到需要将网络设备的Yang文件mount到控制器以实现基于NETCONF的控制。下一篇我们将MD-SAL的各个点串联起来,形成一条线。
-
通信
+关注
关注
18文章
6030浏览量
135975 -
RPC
+关注
关注
0文章
111浏览量
11533 -
sal
+关注
关注
0文章
2浏览量
2489
发布评论请先 登录
相关推荐
评论