OpenDaylight自面世起，“坑”就一直伴随着它的成长而成长，无论是起初的“不稳定”门，还是长期“言简意不赅”的文档，似乎对于想一探究竟的小伙伴总是竖着若干道高耸的壁垒。很多前期的投入者们多数在挫折面前纷纷离场，留下的那些勇毅的斗士则继续战斗，共同推动着OpenDaylight朝着更好的方向发展。其实在诸多溃败者中，往往是重技巧而轻心法者，今天未来网络君就邀请了在OpenDaylight开发征战数年的耿兴元前辈为ODLer和准ODLer们提供心法方向的指导，以期通过十问十答为大家在学习OpenDaylight开发上遇到的问题指点迷津。
1 OpenDaylight项目庞大，子项目众多，如何入手比较合适？
OpenDaylight项目很庞大，但是它有一个核心的架构理念——模型驱动的架构。OpenDaylight有几十个子项目，所有的子项目都是围绕一个核心理念设计的，所以只要理解了OpenDaylight模型驱动的设计机制及其基础框架和服务接口，再多的子项目其实也都只是一套模式。
2 学习或开发基于ODL的网络应用，应该选择哪个版本呢？
学习依然要理清自己的目的。如果我们的开发只是为了学习，建议使用ODL最新的正式发布版本，马上氮版本的SR1也要发布，可以用来学习。
如果我们的开发是用于实际的环境，为了版本的稳定性、开发过程中少遇到一些BUG，建议使用正式发布的大版本的SR2及以后的版本（SR3、SR4），当前碳版本的SR2都已经发布，可以基于该版本进行开发。
因为大版本的第一个版本往往都有故障，等经过两轮的故障收敛之后会比较稳定。另外需要注意的是社区可能对SR4版本不再进行维护，后面社区可能会出一个LTS的版本长期维护，可以选用进行开发。
还有一个建议是尽量不要基于社区的SNAPSHOT的版本进基于该版本进行开发，避免一些不必要的麻烦。当然，如果你想为社区贡献，想在社区当前分支上合入代码，肯定是要在SNAPSHOP版本上进行编译、构建。
3 学习或者开发基于ODL的应用，需要了解很多背景知识，比如Maven, OSGi, Yang等，还有一大堆网络协议， 该如何学习呢？
Java的基础一定要有， ODL是利用Java开发的，依赖大量Java的库，没有Java的基础可能会比较困难，很多语法可能会读不懂，无法入手。有了Java基础后，第一步就是建议大家花一两个星期时间看一下《Maven实战》这本书，因为ODL的项目就是用Maven管理的，所以需要了解一下Maven是什么东西，了解一下核心的内容，比如说：约定优于配置的原则、对应的核心插件、构建的基本过程这些。
还有就是需要了解一下OSGi规范，网上可以找到中文的规范，推荐4.0以后的版本。同时了解一下Karaf，看看OSGi规范和karaf之间的关系，这个过程可能也会花费一两个星期。
我们要学习ODL的MD-SAL，一定要知道Yang的基础知识，所以还需要把RFC 6020了解一下，知道yang的简单语法，至少可以看懂别人写的yang文件是什么意思。
网络的二三层的转发原理是需要知道的，SDN本质上是为了网络而开发，所以了解传统网络的基本转发原理才会深入进行开发。另外，openflow作为SDN最初的南向协议也需要了解
以上的这些知识，至少都要大概浏览一下，再在实践中用到时进行深入研究。拥有这些背景知识，在做app开发的时候才能够思路清晰。
4 编译构建的问题
编译构建的问题的问题是开发app开始的过程中经常遇到的问题：比如编译构建报错的各种异常，或者在执行第一个命令的时候要根据项目模板生成项目骨架的时候，马上就碰到问题了。这些问题其实都可以在网上查到，这时候就可以合理利用一下度娘或者谷歌了。
编译构建的问题很多时候就是Maven配置的问题，所以上一个问题中说到的《Maven实战》这本书一定要读。
编译构建的问题碰到的一般都是checkstyle不过、单元测试不过这些问题，这些都可以通过命令跳过。当然不建议大家总是遇到问题就跳过。
另外新手经常碰到的编译问题就是依赖问题，依赖找不到的问题检查一下依赖的坐标，检查下配置的maven仓库里是否存在对应坐标的组件。Maven能帮助我们很好的管理项目依赖，但如果在开发自己的项目时，不仔细梳理依赖关系，随意拷贝其他项目的pom文件，也可能导致相互依赖等严重问题，一定要注意。通过命令mvn dependency:tree可以查看项目的依赖关系。
正式开发项目时对于以上这些问题一定要分析具体问题，想办法解决。执行mvn clean install时增加参数-e，打印详细异常堆栈，增加参数-X，打开Maven的调试标记运行，查看完整的依赖踪迹。
5 版本加载运行出错
OSGi规范看了吗？（或者看书《深入理解OSGi：Equinox原理、应用与最佳实践》）。
如果已经看过了，那要看bundle处于什么状态？在那个阶段出错的？在karaf控制台，通过查看bundle相关的命令输出相关信息。通过log分析详细的出错信息。
一般都是依赖找不到或者依赖冲突的问题，如何解决？我很想告诉大家秘诀，可惜没有，只能自己仔细分析模块间的依赖关系，Import-Package,Export-Package匹配吗？包路径冲突了吗？具体问题具体分析。
6 现在的OpenDaylight发布版本里，有两套Binding 的接口，分别定义在controller和mdsal子项目，我在开发应用时，该用那个接口呢？
OpenDaylight mdsal相关接口在Berryllium版本之前，是定义在controller子项目的md-sal目录下的，从Berryllium版本开始，社区单独成立了mdsal子项目，在该项目里又重新定义了mdsal的相关接口，功能及形式与controller子项目里的几乎一致，只是包路径不同。最终应该只会保留mdsal子项目里的接口定义，但社区考虑到之前版本的兼容性，大量的子项目还是用的原来的接口，而且mdsal里的实现也在不断优化完善过程中，这样就导致了同样功能的接口变成了两套。
这两个接口我们现在都可以用，因为社区对着两个接口的实现做了兼容适配，但建议大家使用org.opendaylight.mdsal.eos.binding.api.EntityOwnershipService，一步到位，以免社区废弃掉老的接口时，导致我们的代码必须修改。
另外一个就是同样的服务接口，有多个实现，比如
大家可以看到以上同样的服务接口有两个实现，其区别是type不同，我们在使用上述服务接口时，可以通过在blueprint配置文件里获取服务时（reference），指定不同的type来引用具体的服务接口实现。
7 对于存在DataStore里的数据，在开发应用时，是该用读事务获取数据还是直接监听数据变更?
ODL开发推荐的模式是消息驱动的开发模式。它认为网络是一个消息驱动的巨大的状态机，所有的状态变更是通过消息驱动来触发的，因此社区推荐是监听的方式，不推荐去大量的读数据库。
8 基于ODL开发应用，需要都用异步的实现吗？ 能用同步吗？在什么情况下可以用同步方式？
建议大家用异步的方式，异步的方式更符合现在编程的常规。但是不代表不可以试用同步的方式，比如说业务逻辑比较简单的应用，不需要开一个线程消耗，使用同步的方式就可以实现了，但是如果是一个耗时的或者耗CPU的操作就需要异步的方式了，这个可以灵活应用。
9 配置子系统是什么？最新的发布版本里还在用吗？Blueprint和配置子系统关系？
接触ODL比较早的话就知道，在社区的早期版本里，一开始写的yang模型就是配置子系统要用的yang模型，是比较复杂的，还要写一个xml文件来配置模块的初始化或者一些服务的依赖这些东西。最新发布的版本里，用Blueprint来替代配置子系统来进行模块的初始化、服务的依赖或者发布这些操作。后期的子系统里面Bluprint会完全取代配置子系统。当前版本考虑到向前兼容，适配保留了部分配置子系统的功能。
10 如何参与ODL社区，与ODL社区互动？
需要知道ODL的一些网站，像代码库、wiki这些
官网：www.opendaylight.org
代码库：git.opendaylght.org
wiki:wiki.opendaylight.org
jira:jira.opendaylight.org
FAQ:faq.opendaylight.org
参与社区的流程在wiki上有说明，可以从wiki开始。
免费观看问答视频或了解ODL课程详情
请点击【阅读原文】，记得下拉哦
