SDN北向restAPI设计模式

RESTAPIDesignPatternsforSDNNorthboundAPI汇报人：郝世杰目录•摘要•1、引言•2、相关工作•3、基于RestAPI的设计原则•4、RestAPI模型和设计模式•5、评估•6、结论摘要•本文讨论了Restful网络协议设计的许多问题，并提出了一个框架使网络协议设计为一种真正的Restful风格。•作者介绍了HTTP内容协商机制，允许客户从同一资源的URI选择不同的表示格式。•最重要的是，作者提出了一个超文本驱动的方法，使超文本链接是Rest资源之间定义的网络协议，以指导客户识别正确的资源，而不是依靠固定资源的URI。并在SOX控制器上实现了这种方法。1、引言•采用Rest风格的好处：•1、动态资源的分散管理：不使用集中的资源注册而是依赖于资源之间的关系。•2、异构客户端：因为REST分离了资源的表示、识别和相互作用，它可以调节基于SDN客户性能和网络条件的资源表示和网络协议，以优化API的性能。•3、服务组合：目前的SDN趋势是使用编程来实现功能的灵活性，而Rest可以提供面向服务的组合物，可独立编程可跨平台。•4、局部迁移：RestAPI通过本地化的迁移来实现向后兼容的迁移服务。结合统一的接口和超文本驱动的服务发现，它可以缓解新的服务部署和向后兼容性之间的紧张关系。•5、可扩展性：实现可扩展性一是通过分层缓存来提高服务器的性能；二是保持服务器无状态。•为了实现以上优点在设计一个可扩展的和面向服务的RestfulAPI需要一组Rest约束。而分组原则之一是超文本作为应用程序状态的引擎。•本文提出了基于RestChart模型并来设计实现可扩展的Rest风格的网络协议的方法。该方法解决了网络协议设计的问题并提供了一个通用的框架可以设计真正的Restful风格。•本文的主要贡献：•1、提出了一个通用框架和一个理论模型；•2、提出了松耦合的、面向资源的RESTful网络协议的设计模式。•3、提出的HTTP内容协商机制，允许从同一个资源URI客户端请求不同的媒体类型。•4、提出了一个超文本驱动的方法，使用超文本链接定义来引导客户确定合适的资源，而不是依靠固定的资源的URI。2、相关工作•OpenFlow控制器NOX在C++和Python中提供了基于流的网络配置API。•DevoflowOnixMaestro这些控制器则关注于提高SDN控制器的性能和可扩展性。•POX可以公开配置API作为JSON-RPC的Web服务使其与messenger一起发送OpenFlow事件给应用程序。•Floodlight内部的Meridian为虚拟网络管理提供了RestAPI。3、基于RestAPI的设计原则•现在的RestAPI设计不满足Rest设计主要有俩方面：API在URI中暴露了媒体类型和固定资源。•1、暴露媒体类型•限制了客户端和服务器自主解决问题的能力；•如果服务器决定从JSON转为XML，那么JSON会失效客户端会寻找新的XMLURI；•如果一个客户通过JSONURI进入到另一个客户端只能解析XML，第二个客户端即使服务器提供了XML也不能访问资源。•一个松耦合的面向服务的方法是从URI中删除多媒体类型，并使用HTTP1.1内容协商机制从相同的URI请求不同的媒体类型。•2、暴露固定资源•这样的做法违反了RestAPI必须使用超文本驱动的原则。•为了解决这个问题，我们从我们的RESTAPIS除去任何固定的URI，除了API的入口URI。•在此超文本驱动的方法中，每个URI的含义是在其发生的超文本中定义，其值可以由控制器来改变，但不改变它的含义，这样就导致了松散耦合REST架构。•常用标记URI意义的方法是使用rel属性链接元素。基于REL的属性和超文本结构，客户机可以选择正确的资源URI跟随，并在同一时间使控制器改变资源的URI。4、RestAPI模型和设计模式•A.OpenStackQuantumOverview•B.RESTChartModel•C.APIMigrationPatterns•D.ImplementationDetailsA.OpenStackQuantumOverview•Quantum的核心数据模型包括三种类型的实体：网络、端口和子网。•Quantum的核心功能是管理数据模型里的实体。B.RESTChartModel•为了在不违反Rest约束的情况下设计基于Quantum架构的RestAPI作者提出了使用RestChart来描述RestAPI。•库所：媒体类型•变迁：模式之间的联系•Token：代表资源特定模式的表示B.RESTChartModelURIPattern•URI是RestAPI的一个重要组成部分，好的URI命名空间支持可读性和可扩展性。URI命名空间设计遵循type/variable或者collection/member，这样做提供了命名空间的灵活性和可扩展性。•例如：租户与网络URI标识租户所拥有的网络：•{entry}/tenants/{tid}/networks/{nid}NavigationPattern•RestAPI最基本的相互作用是从进入URI来导航到其期望的资源并获得它的当前表示。FilterandSearchPatterns•表1中，对于每个网络实体仅仅包含网络超链接。但是当客户想恢复网络名字的时候就需要恢复整个网络，很不方便。为了解决这个问题，RestAPI允许客户端请求额外的内容：•attributes={name1,…,nameN}URIquerystring•如果租户拥有的网络比较多，那么用导航效率比较低。RestAPI支持使用搜索。FactoryandUpdatePatterns•为了通过RestAPI寻找到信息，客户端可以创建和改变资源。提出了工厂和更新模式。C.APIMigrationPatterns•QuantumRESTAPI的俩个版本的比较•共同点：•所有的RESTCharts都包含了路径：initial→networks→ports→port；•俩版本的网络和端口嵌套表的内部结构是相似的。•不同点：•V1.0端口在底部•V2.0端口在顶部•如果rel属性不变，我们可以比较容易设计算法遍历俩个RestChart来寻路。•V1.0initial→networks→ports→port•V2.0initial→ports→port•V1.0附件——V2.0设备•此时需要设计映射来寻路。D.ImplementationDetails5、评价结果•评估SOX北向RestAPI有俩种方法：•1）根据RestAPI的变化可透明更新OpenStackQuantum•2)在固定的URI场景下性能和成本的比较A.LiveTransparentUpgrade•这个实验为了表明SOXRestAPI可以在不中断Quantum执行的情况下而迁移到不同的URI命名空间。•SOX-A：RestAPIV1•SOX-B:RestAPIV2•先启动A然后切换到B，但Quantum却没意识到转换。B.PerformanceEvaluation•使用模拟器模拟一个中型租户，执行RestAPI覆盖测试几轮。•结果表明，以松散耦合实现的基于REST协议的性能成本比使用固定资源的URI约40％以上的远程调用，而平均响应时间可保持在低于20毫秒。6、结论•作者提出了使用一种以超文本驱动的一组设计模式实现的框架的方法，使设计的SDN北向API为真正的Restful风格。•这种方法已经成功的在RestChart上实现并应用于SDN北向API的设计。•作者证明RestAPI可以通过URI命名空间的透明迁移来实现自由修改。