1 MD-SAL
1.1 为何采用MD-SAL
我们曾尝试过对可编程系统整个系统进行抽象(AD-SAL),然而,对于事先已知的系统,这样做未尝不可, 对于API需要频繁改动以适应各种场景,这种抽象最终会成为系统演进的一个主要的障碍,或者会导致需要不断整合这些API的分支. 无论上述哪种情况,维护抽象API的团队都会成为一个生产能力上的限制,因为这个团队需要具有技术领域专家, 确保我们的抽象和交互是紧密结合的,需要在技术和API风格的前瞻性上都不能有差错.
MD-SAL 源于我们认为可扩展性不应该成为一个问题,任何人都应该能定义他们的API原型,SAL层对于任何人定义的API都是可以工作的,即便这些原型API是整个大的系统的一个一个的孤岛.
详见https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Explained
1.2 MD-SAL介绍(消息驱动的状态机【消息驱动、状态存储】)
MD-SAL基于用户定义的数据和接口模型,提供消息和存储服务的基础设施组件(The Model-Driven SAL (MD-SAL) is an infrastructure component that provides messaging and data storage functionality based on user-defined data and interface models.)
MD-SAL 当前提供的基础服务:
Data Store(状态存储)
RPC / Service routing(消息驱动)
Notification subscription and publish services(消息驱动)
1.3 MD-SAL目标
MD-SAL 有两个主要目标:
- 提出一个构建模块和设计模式的概念和数据模型的通用层,为构建应用提供基础服务(Provide a common-layer, concepts, data model building blocks and patterns which serves as building blocks applications)
- 支持多种传输和负载格式,对其进行序列化/适配(Support of multiple transport and payload formats, serialization/adaptation them.)
通过使用YANG语言对接口和数据建模,并提供一个YANG模型的运行时支持的一系列服务,我们就能达成这两个目标(This objectives are achieved by using YANG as modeling language for interface and data definition and providing runtime for services using YANG modeling.)
1.4 MD-SAL示意图
2 Yang语言
- YANG 是随着 NETCONF 协议而产生的数据建模语言,由RFC 6020定义,YANG可读性好、简单、直接、可扩展。YANG在OpenDaylight中用来做为建模语言
- module是YANG的基本单元,一个YANG module定义了一个具有树状层级结构的节点集。
- YANG建模得到的数据具备树形结构。其中每一个节点都有一个名字,都有一个值或者一些子节点。YANG为这些节点,以及节点之间的交互提供明确清晰的描述。
2.1 Yang数据类型
2.2 Yang派生类型
YANG采用typedef语句来定义派生类型
typedef percent {
type uint8 {
range "0 .. 100";
}
}
2.3 Yang节点类型
Leaf
Leaf-List
List
Container
Choice
Grouping
Augment
2.4 Yang RPC定义
2.5 Yang消息通知Notification定义
3 RPC
3.1 RPC分类
- Global RPC – 在一个控制器节点上,只会有一个RPC的实例被调用到(可以注册多个RPC实现的实例,最先注册的生效)
- Routed RPC – 在一个控制器节点上,通过不同的RoutedID信息可以调用不同的RPC实现实例
3.2 MD-SAL:Explained:Messaging Patterns
- RPC
即消费者与提供者之间的单播关系,消费者发送请求消息给提供者,提供者封装响应消息异步返回给消费者(unicast between consumer and provider, where consumer sends request message to provider, which asynchronously responds with replymessage) - 异步的请求-响应模式,消费者发送请求消息给提供者,提供者以future方式给请求者返回响应消息(asynchronous request-reply message pair, when request is triggered by consumer, send to the provider, which in future replies with reply message.)
3.3 MD-SAL RPC实现原理
在get一个rpc服务时候,OpenDaylight会对rpc服务封装一个动态代理,我们调用的时候只通过动态代理来调用这个rpc服务,调用rpc的时候会从注册表(Map)中去查,查到相应实现再去调用相应的方法。
3.4 RPC注册
RPC的注册是注册到Map中的
3.5 RPC获取
3.6 blueprint扩展
实际使用中rpc的注册和获取是通过blueprint实现的
4 RPC实战
4.1 获取下发OpenFlow流表的RPC,调用该RPC进行LLDP报文上送控制器流表下发
获取OpenFlowPlugin的AddFlowRPC,通过RestConf下发流表
- 获取RPC,通过配置blueprint获取rpc的服务
通过java的方式调用rpc服务,resultFuture.get()。
4.2 完成执行并收集ping一组主机的结果的任务,请自定义一个rpc
restconf调用rpc看是否成功