作者｜李運華

如何對待開源？

得益於開源運動的蓬勃發展，眾多技術頂尖的公司、團隊或者個人通過開源的方式向技術社區貢獻了許多優秀的開源項目，一方面大大促進了整體技術的發展，另一方面大大減輕了中小公司和團隊在技術方面的投入壓力，讓團隊能夠更加聚焦於業務。

開源項目對團隊和業務有很大好處，但對於技術人員來說，如果只是簡單的採取“拿來主義”，那就變成一個陷阱：看似很快的用開源項目實現了需求，但自己的技術水平並沒有什麼提升；甚至可能出現看起來用了很多開源項目，知道很多項目名稱，但技術水平止步不前的窘境。

因此，對於開源項目，不能簡單的採取“拿來主義”，而要比較深入的去學習開源項目，做到“知其然，知其所以然”，一方面是為了更好地應用這些開源項目，另一方面也是為了通過學習優秀的開源項目來提升自己的能力。

很多技術同學確實也想深入學習一些業界成熟和優秀的開源項目，例如 Nginx、Redis、Netty 等，但是在具體實踐的時候，常常因為一些不正確的觀點而誤入歧途，例如：

• 只有開發這些開源項目的人才能真正理解，我沒法參與這個項目開發，因此我很難深入理解。
• 我的項目沒有用 Redis，不用的話很難深入理解。
• 數據結構和算法很重要，所以我只要研究其數據結構和算法就夠了，例如 Nginx 用的紅黑樹。
• “Talk is cheap, show me the code”，一頭扎進源碼逐行閱讀。

這些觀點要麼讓自己望而生畏從而輕易放棄，要麼讓自己浪費大量時間而沒有多大收穫。那究竟要怎樣做才是正確的呢？下面我結合自己的經驗談談我對如何學習開源項目的看法。

首先，需要樹立正確的觀念：不管你是什麼身份，都可以從開源項目中學到很多東西。

例如，要理解 Redis 的網絡模型，我們不需要成為 Redis 的開發者，也不需要一定要用到 Redis，只要具備一定的網絡編程基礎，再通過閱讀 Redis 的源碼，都可以學習 Redis 這種單進程的 Reactor 模型。

例如，Nginx 使用紅黑樹來管理定時器，對於絕大部分人來說，只要知道這點就夠了，並不需要去研究 Nginx 實現紅黑樹的源碼是如何寫的，除非你需要修改這部分，但我認為極少人會有這個需求。

第三，採取自頂向下的學習方法，源碼不是第一步，而是最後一步。

不要一上來就去看源碼，而是要基本掌握了功能、原理、關鍵設計之後再去看源碼，看源碼的主要目的是為了學習其代碼的寫作方式，以及關鍵技術的實現。

例如，Redis 的 RDB 持久化模式“會將當前內存中的數據庫快照保存到磁盤文件中”，那這裡所謂的“數據庫快照”到底是怎麼做的呢？在 Linux 平臺上其實就是 fork 一個子進程來保存就可以了；那為何 fork 子進程就生成了數據庫快照了呢？這又和 Linux 的父子進程機制以及 copy-on-write 技術相關了。

通過這種方式，既能夠快速掌握系統設計的關鍵點（Redis 的 RDB 模式），又能夠掌握具體的編程技巧（內存快照）。

接下來我詳細談談“自頂向下”的學習方法和步驟。

第一步：安裝

很多人看到“安裝”這個步驟都可能會覺得有點不以為然：“不就是對照手冊執行一下命令麼，沒什麼技術含量，用的時候裝一下就可以了”。事實上，安裝步驟遠遠不止這麼簡單，通過具體的安裝過程，你可以獲取到如下一些關鍵信息：

這個系統的依賴組件，而依賴的組件是系統設計和實現的基礎

以 Nginx 為例，源碼安裝 Nginx 依賴的庫有 pcre、pcre-devel、openssl、openssl-devel、zlib，光從名字上看都能夠了解一些信息，例如 openssl 可能和 https 有關，zlib 可能和壓縮有關。

再以 Memcache 為例，最大的依賴就是 libevent，而根據 libevent 是一個高性能的網絡庫，我們就能大概推測 Memcache 的網絡實現應該是 Reactor 模型的。

安裝目錄也能夠提供一些使用和運行的基本信息

例如，Nginx 安裝完成後，目錄如下：

這個目錄提供的信息有：conf 是存放配置文件的，logs 是存放日誌的，sbin 是運行程序，但是 html 是什麼呢？這個疑問會促使你繼續去研究和學習。

再來看看 Redis，安裝完成後，目錄下只有一個 bin 目錄，具體如下：

我相信大部分人看到這目錄都會感到有點驚訝：這也太簡單了吧，尤其是與 Nginx 相比！因此也會自然而然的有一些疑問，例如 Redis 如何配置？Redis 日誌保存在哪裡？這些疑問同樣會促使你繼續去研究和學習，帶著問題去學習效率是最高的。

系統提供了哪些工具方便我們使用

同樣以 Redis 為例，你可以看到 redis-benchmark、redis-check-aof 等程序，從名字能夠大概猜出這些工具的基本使用場景，而這些工具在後面故障定位和處理、性能測試等場景可能非常方便。

第二步：運行

安裝完成後，我們需要真正將系統運行起來，運行系統的時候有兩個地方要特別關注：命令行和配置文件，它們主要提供了兩個非常關鍵的信息：系統具備哪些能力和系統將會如何運行。這些信息是我們窺視系統內部運行機制和原理的一扇窗口。

例如，下面是 Memcache 的啟動參數一部分：

通過這幾個啟動參數，你可以獲取如下一些信息：

• Memcache 支持 UNIX socket 通信和 TCP 通信。
• Memcache 可以指定內存大小。
• lock memory 看起來和內存有關，但具體是什麼意思？配置和不配置有什麼區別麼？

通常情況下，如果我們將每個命令行參數和配置項的作用和原理都全部掌握清楚了的話，基本上對系統已經很熟悉了。我的一個習慣是不管三七二十一，先把所有的配置項全部研究一遍，包括配置項的原理、作用、影響，並且嘗試去修改配置項然後看看系統會有什麼變化。例如，將 Memcache 的“--conn-limit”改為 1 後，查看多個連接請求時 Memecache 會返回什麼錯誤、記錄什麼日誌等。

第三步：原理研究

完成前兩個步驟後，我們對系統已經有了初步的感覺和理解，此時可以更進一步去研究其原理。其實在研究命令行和配置項的時候已經涉及一部分原理了，但是還不繫統，因此我們要專門針對原理進行系統性的研究。這裡的關鍵就是“

關鍵特性的基本實現原理

每個流行的開源項目之所以能夠受到大眾的歡迎，肯定是有一些賣點的，常見的有高性能、高可用、可擴展等特性，那到底這些項目是如何做到其所宣稱的那麼牛的呢？這些牛 X 的技術實現就是我們要學習的地方。

例如，Memcache 的高性能具體是怎麼做到的呢？首先是基於 libevent 實現了高性能的網絡模型，其次是內存管理 Slab Allocator 機制。為了徹底理解 Memcache 的高性能網絡模型，我們需要掌握很多知識：多路複用、Linux epoll、Reactor 模型、多線程等，通過研究 Memcache 的高性能網絡模型，我們能夠學習一個具體的項目中如何將這些東西全部串起來實現了高性能。

再以 React 為例，Virtual DOM 的實現原理是什麼、為何要實現 Virtual DOM、React 是如何構建 Virtual DOM 樹、Virtual DOM 與 DOM 什麼關係等，通過研究學習 Virtual DOM，即使不使用 React，我們也能夠學習如何寫出高性能的前端的代碼。

優缺點對比分析

這是我想特別強調的一點，只有清楚掌握技術方案的優缺點後才算真正的掌握這門技術，也只有掌握了技術方案的優缺點後才能在架構設計的時候做出合理的選擇。

優缺點主要通過對比來分析，即：我們將兩個類似的系統進行對比，看看它們的實現差異，以及不同的實現優缺點都是什麼。典型的對比有 Memcache 和 Redis，例如（僅舉例說明，實際上對比的點很多），Memcache 用多線程，Redis 用單進程，各有什麼優缺點？Memcache 和 Redis 的集群方式，各有什麼優缺點？即使是 Redis 自身，我們也可以對比 RDB 和 AOF 兩種模式的優缺點。

在你瞭解了什麼是“系統性”後，我來介紹一下原理研究的手段，主要有三種：

• 通讀項目的設計文檔：例如 Kafka 的設計文檔，基本涵蓋了消息隊列設計的關鍵決策部分；Disruptor 的設計白皮書，詳細的闡述了 Java 單機高性能的設計技巧。
• 閱讀網上已有的分析文檔：通常情況下比較熱門的開源項目，都已經有非常多的分析文檔了，我們可以站在前人的基礎上，避免大量的重複投入。但需要注意的是，由於經驗、水平、關注點等差異，不同的人分析的結論可能有差異，甚至有的是錯誤的，因此不能完全參照。一個比較好的方式就是多方對照，也就是說看很多篇分析文檔，比較它們的內容共同點和差異點。
• Demo 驗證：如果有些技術點難以查到資料，自己又不確定，則可以真正去寫 Demo 進行驗證，通過打印一些日誌或者調試，能清晰的理解具體的細節。例如，寫一個簡單的分配內存程序，然後通過日誌和命令行（jmap、jstat、jstack 等）來查看 Java 虛擬機垃圾回收時的具體表現。

第四步：測試

通常情況下，如果你真的準備在實際項目中使用某個開源項目的話，必須進行測試。有的同學可能會說，網上的分析和測試文檔很多，直接找一篇看就可以了？如果只是自己學習和研究，這樣做是可以的，因為構建完整的測試用例既需要耗費較多時間，又需要較多機器資源，如果每個項目都這麼做的話，投入成本有點大；但如果是要在實踐項目中使用，必須自己進行測試，因為網上搜的測試結果，不一定與自己的業務場景很契合，如果簡單參考別人的測試結果，很可能會得出錯誤的結論。例如，開源系統的版本不同，測試結果可能差異較大。同樣是 K-V 存儲，別人測試的 value 是 128 字節，而你的場景 value 都達到了 128K 字節，兩者的測試結果也差異很大，不能簡單照搬。

測試階段需要特別強調的一點就是：

第五步：源碼研究

源碼研究的主要目的是學習原理背後的具體編碼如何實現，通過學習這些技巧來提升我們自己的技術能力。例如 Redis 的 RDB 快照、Nginx 的多 Reactor 模型、Disruptor 如何使用 volatile 以及 CAS 來做無鎖設計、Netty 的 Zero-Copy 等，這些技巧都很精巧，掌握後能夠大大提升自己的編碼能力。

通常情況下，不建議通讀所有源碼，因為想掌握每行代碼的含義和作用還是非常耗費時間的，尤其是 MySQL、Nginx 這種規模的項目，即使是他們的開發人員，都不一定每個人都掌握了所有代碼。帶著明確目的去研究源碼，做到有的放矢，才能事半功倍，這也是源碼研究要放在最後的原因。

對於一些基礎庫，除了閱讀源碼外，還可以自己寫個 Demo 調用基礎庫完成一些簡單的功能，然後通過調試來看具體的調用棧，通過調用棧來理解基礎庫的處理邏輯和過程，這比單純看代碼去理解邏輯要高效一些。例如，下面是 Netty 4.1 版本的 telnet 服務器樣例調試的堆棧，通過堆棧我們可以看到完整的調用棧：

時間分配

前面介紹的“自頂向下”5 個步驟，完整執行下來需要花費較長時間，而時間又是大部分技術人員比較稀缺的資源。很多人在學習技術的時候都會反饋說時間不夠，版本進度很緊，很難有大量的時間進行學習，但如果不學習感覺自己又很難提升？面對這種兩難問題，具體該如何做呢？

通常情況下，以上 5 個步驟的前 3 個步驟，不管是已經成為架構師的技術人員，還是立志成為架構師的技術人員，在研究開源項目的時候都必不可少；第四步可以在準備採用開源項目的時候才實施，第五步可以根據你的時間來進行靈活安排。這裡的“靈活安排”不是說省略不去做，而是在自己有一定時間和精力的時候做，因為只有這樣才能真正理解和學到具體的技術。

如果感覺自己時間和精力不夠，與其蜻蜓點水每個開源項目都去簡單瞭解一下，還不如集中精力將一個開源項目研究通透，就算是每個季度只學習一個開源項目，積累幾年後這個數量也是很客觀的；而且一旦你將一個項目研究透以後，再去研究其他類似項目，你會發現自己學習的非常快，因為共性的部分你已經都掌握了，只需要掌握新項目差異的部分即可。

閱讀更多 InfoQ 的文章

關鍵字: 項目 Linux 去學