打算跟着大神慢慢學習，再把自己所學的東西一起記錄起來。
我最早是2014年接觸OpenStack了，當時安裝成功了DevStack，因為沒有項目再用，後來就沒有後來了。
今年接觸了雲計算的項目，又重新拾了起來，但是目前也隻止步于安裝，想進一步分析每個子產品，沒有一個很好的大綱，剛好看到大神CloudMan在寫這個，是個很好的思路。慢慢學習，堅持下。
關于學習思路，之前看到一篇很好的文章，記錄下來。
http://www.csdn.net/article/2014-04-10/2819247-how-to-learn-opensouce-project-&-ceph
華為章宇：如何學習開源項目及Ceph的淺析
摘要：開源技術的學習和采用确實存在着一定門檻，然而學習各種開源項目已經成為許多開發者不可回避的工作内容。那麼，對于類似OpenStack的大型開源項目，開發者該如何着手，這裡我們看章宇的分享。
【編者按】在 上一屆OpenStackSummit報道中，我們有提過，OpenStack已得到IBM、HP、RedHat等公司的鼎力支援，而截至2013年底， 在短短不到4年的時間，其社群已遍及全球132個國家，13504人參與，開發者人數更接近6000人，298家的支援場上和機構，擁有8個白金會員、19個黃金會員、54個贊助公司、217個支援機構，北京更成為OpenStack開發者最多的城市。
毫無疑問，在得到了廣泛的支援後，OpenStack在飛快的成熟。然而，作為1個内容豐富、涉及衆多技術的開源IaaS平台，就像【CSDN線上教育訓練】第三期中張小斌的分享：
開源并不意味着免費，豐富的插件并不一定最優。
OpenStack看似給我們提供了非常多的選項，但是如此多的選項往往讓企業眼花缭亂。
人人DIY固然可以集思廣益，但卻無法避免踩入陷阱。不深入了解，總會有意想不到的驚喜，如網絡不通，系統崩潰，性能低下，需求如何滿足等。
開源技術的學習和采用确實存在着一定門檻，然而坐擁寶山絕無空手而歸的道理，這裡我們為大家分享 章宇的技術Blog，從開源項目學習到Ceph淺析。（ps：部落格類型屬于個人部落格，僅代表個人技術觀點，不代表任何公司或者實體）
部落客資料：章宇于2002年及2007年分别于清華大學電子工程系獲得學士及博士學位，其後一直從事計算機系統領域的研究與開發工作，目前供職于華為技術有限公司雲作業系統部門，從事OpenStack相關工作。出于工作原因和個人興趣，作者陸續關注了一些開源項目，主要包括：KVM/QEMU，libvirt，virt-mamager，OpenStack，OpenvSwitch，Ceph，Zabbix等。
開源項目學習方法
學習各種開源項目，已經成為很多朋友不可回避的工作内容了。筆者本人也是如此。在接觸并學習了若幹個開源項目之後，筆者試圖對自己工作過程中的若幹體會加以總結，以期對一些希望借鑒的朋友有所裨益。
需要說明的是，筆者本人接觸的開源項目大多屬于計算機系統領域，例如Linux kernel，KVM，QEMU，OpenStack等。是以，此處介紹的經驗必定也有些局限。請讀者們自行分辨，差別對待。
1. 學習分層和目标管理
對于一個開源項目，可以将與之相關的各種知識和技能的學習大緻劃分為如下五個層次：
第一層次：了解項目的基本概念、基本用途、邏輯結構、基本原理、産生背景、應用場景等基本知識。
這個層次的基本定位其實就是“科普”。如果對于一個項目隻需要有些基本了解，且短期内并不需要上手進行實際技術工作，則學習到這個層次也就可以先應付一下了。
第二層次：掌握項目的基本安裝流程和使用方法。
這個層次的基本定位是“入門”，以便對這個項目獲得直覺認識，對其安裝和使用獲得親身體驗。如果隻是需要以as-is方式使用這個項目，則初步學習到這個層次即可。
第三層次：了解代碼的組織，找到各個主要邏輯/功能子產品與代碼檔案之間的對應關系，通過代碼分析走通幾個關鍵的、有代表性的執行流程。
這個層次的基本定位是“深入”，開始了解這個項目的實際實作，能夠真正将項目的功能、工作原理和代碼實作對應起來，獲得對這個項目工作過程的直覺認識。這個層次是學習開源項目代碼的真正開始。如果希望基于這一項目進行應用開發，或者針對與這一項目密切相關的其他項目進行工作時，則對項目本身的代碼進行這一層次的了解，會很有幫助。
第四層次：了解該項目所有代碼子產品、程式檔案的作用，走通所有主要執行流程。
這個層次的基本定位是“掌握”，能夠比較全面、系統地了解這個項目的設計和實作，并且熟悉項目各個部分的代碼。如果希望對項目進行深度定制修改，或者對社群有所貢獻，則應當以達到這個層次作為目标。
第五層次：鑽研、領悟該項目的各種設計思想與代碼實作細節。
這個層次的基本定位是“精通”，精益求精，學無止境。這是大神們追求的境界。如果希望成為項目社群的重要貢獻者乃至核心貢獻者，則應當以這個層次作為努力的目标。
綜上，對于一個開源項目的學習過程可以大緻分為五個層次。至于到底要學習到什麼階段，投入多少相關精力，則完全取決于學習的目的。
2. 知識基礎
學習一個開源項目需要的知識基礎主要包括：
1）該項目涉及的技術領域的背景知識
舉例而言，分析Linux Kenrel，則應該了解作業系統原理；學習OpenStack，則應該知道什麼是雲計算。如果沒有這些背景知識作為基礎，上來就死磕源代碼，隻能是事倍功半。
2）該項目開發使用的語言及其各種開發調試工具
這個就無需多言了。
3）英語
很遺憾，目前為止真正流行的開源項目大部分不是起源于國内。是以，除了學習個别極其流行、文檔完備的項目之外，大家還是需要自行搜集閱讀英文資料參考。學好英語很重要。
當然，到底需要準備多少知識基礎，完全取決于學習的目的和層次。如果隻是想科普一下，也就不必太過麻煩了。
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，則對于這一部分知識還是應該有所涉獵，至少應該有概念上的了解。
在達到上述階段之後，則可以根據自身的需求決定後續計劃了。
轉載于:https://blog.51cto.com/xiaoqinglang/1879792
![作業系統（python）多程序學習[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)