3. 学习思路
学习一个项目的过程，其实就是由表及里了解分析它的过程。上述提及的五个学习层次便组成了这样一个逐渐深入的过程。在此基础之上，学习、分析代码的过程，也可以尝试做到由表及里、逐渐深入。
在刚开始接触一个项目的时候，我们看到的其实就是一个黑盒子。根据文档，我们一定会发现盒子上具有若干对外接口。通常而言，这些接口可以被分为三类：
因此，在分析一个开源项目的代码时，可以围绕重要的配置、控制、数据接口展开分析工作，特别应该注意理解一个关键的接口背后隐藏的操作流程。例如，
针对数据接口，至少应当走通一条完整的数据输入输出流程，也即在代码中找到数据从输入接口进入盒子后，经过各种处理、转发步骤，最终从输出接口被传输出去
的整个执行过程。一旦走通了这样一条流程，则可以将与数据处理相关的各个主要模块、主要步骤贯穿起来，并将逻辑模块图上和文档中的抽象概念对应到代码实现
之中，可以有效推进对于项目的深入理解。
在实践这一思路的过程中，笔者建议可以优先从控制接口和数据接口中各自选择一二重要者进行背后的执行流程详细分析，力争找到其中每一步的函数调用及
数据传递关系（对于一些系统、应用库提供的底层函数可以先行跳过以节省时间）。这一工作完成之后，则第1节中第三层次的学习目标即可初步达成。
配置接口在不同的项目中的重要程度不同。对于一些架构极为灵活、配置空间甚大的项目（如OpenStack的Ceilometer），则可以适当多花些时间加以研究，否则简单了解即可。
对于这个学习思路，下文中还将结合实例进行进一步的说明。
4. 若干小建议
以下是笔者的一些零散建议，供大家参考。
1）做好记录
在刚刚入手开始学习某个项目的源代码时，其实很有点破译密码的感觉。大量的数据结构和函数方法散落在代码的各个角落里，等待着学习者将它们贯穿到一个个重要的执行流程中。因此，在分析学习的过程中，无论有什么零散收获，都值得认真记录下来。珍珠自然会串成项链的。
2）不要过分纠缠于细节
立志搞懂一个项目的每行源代码是值得尊敬的，但至少在刚刚入手的时候是没有必要的。如果过于纠缠于代码的实现细节，则可能很快就被搞得头晕眼花不胜
其烦了（看英文资料的时候，每遇到一个不认识的词都要立刻查词典么？）。不妨避免细节上的过度纠缠，还是先尽快走通关键的执行流程，将项目的骨干框架搭起
来，然后再以此为参照，就可以清晰判断什么代码值得深入分析，什么地方可以简单略过了。
3）想像和联想很重要
如前所述，从零开始搞懂一个项目的代码，就像破译密码。因此，不妨展开合理的想象和联想，将各个零散的发现和理解联系起来，并加以分析印证。在这个
过程中，对项目所在领域的背景知识、对项目本身的逻辑框架和工作原理等方面的理解，都是想像和联想的参照与指导。此外，一些关键的函数名、变量名等等都是
联想的hint。本质上，编程语言也是语言，而程序代码就是说明文。在分析代码时，一定要超越语言和代码的细节去理解被说明的事物本身。
4）该搜就搜
分析代码的时候，很容易出现的情况就是，一个执行流程走到半截找不到下一步了。。。在这种情况下，当然首先还是推荐采用各种调试工具的单步执行功能
加以跟踪。如果暂时不会，或者种种原因只能进行静态代码分析，那么该搜就搜吧。各种IDE工具的文本搜索都能用，哪怕是grep也行。至于到底以什么为搜
索关键词，就需要琢磨琢磨了。
5）外事不决问google，内事不决问百度
如题，不解释。
5. 一个例子：OpenStack Cinder分析
此处将以OpenStack Cinder为例，并结合KVM/Qemu和Ceph，说明如何参考上述思路对一个开源项目进行分析。
可能有朋友奇怪为什么选这么个东东做例子。这个吧。。。写文章时忽发起想，举例子是随手抓来。木有原因。。。
首先，想对Cinder进行分析，一定要了解若干相关的基础知识。什么是云计算？什么是块存储？什么是OpenStack？Cinder在OpenStack里的作用？等等等等。如果对这些东西没有概念，则后续学习是很难开展下去的。
在此基础上，如果有条件，则最好能够亲自部署和实际操作一下Cinder（包括必要的其他OpenStack组件），以便对Cinder获得一个直
观的认识和体验，为后续分析提供一些参考。此处假定Cinder使用的后端是Ceph，而OpenStack上运行的虚拟机是KVM。
然后，应该从概念上对我们要分析的系统的逻辑框架有个理解。从总体的范畴上讲，应该了解Horizon和Nova各自的逻辑模块结
构，以及它们和Cinder的协同工作方式、关系。这部分与Cinder的控制接口及执行路径分析密切相关。此外，还应该了解Cinder和
KVM/QEMU、Ceph之间的相互关系。这对于真正理解Cinder很有帮助。从Cinder自身而言，应该了解其内部逻辑模块构成、各自的功能、相
互间的控制、数据连接关系等。
在完成上述准备之后，则可以开始对Cinder的代码进行分析了。如前所述，应该考虑在控制接口和数据接口中各自选择一两个关键的、有代表性的加以分析。至于配置接口，假定其实现了某一配置即可，暂时不需要过多花费时间。
Cinder的核心功能其实是OpenStack上的volume管理。至少在Cinder+Ceph方案中，Cinder自身并不在数据传输关键
路径上。因此，控制接口的分析就是Cinder源代码分析的重中之重。就入手阶段而言，则有两个接口及其对应执行流程可以作为Cinder分析的起点，即
volume的create和attach操作。如果能够彻底打通这两个操作的执行流程（至少要看到Cinder与Ceph通过librbd交互的层
面），则对于真正理解Cinder的功能与实现大有帮助。
虽然基于KVM的虚拟机在通过QEMU访问Cinder创建的、Ceph提供的volume时并不通过Cinder，也即，这一部分的源代码其实已
经超出了Cinder源代码学习的范畴，但是，如果希望真正彻底地理解Cinder，则对于这一部分知识还是应该有所涉猎，至少应该有概念上的了解。
在达到上述阶段之后，则可以根据自身的需求决定后续计划了。 作为OpenStack的人气存储技术之一，Ceph与Swift和GlusterFS一样有着各自的优势：GlusterFS更适合Hadoop类型的服务；Swift适合更多人访问；Ceph的未来更被看好，并已得到许多知名机构的支持，比如CERN和天河2。 在之前，我们已经分享过章宇Ceph系列博文的前两部分“ Ceph浅析（上）：概况与设计思想”与“ Ceph浅析（中）：结构、工作原理及流程”，这里我们将分享该系列博文的最后一部分： |
