date
comments
categories
br#title
2020/4/18
true
軟體架構
架構
開源專案
5.42
如何高效學習開源專案
工作當中會經常使用到開源專案，例如nginx,redis,netty等。對於開源專案，不能只知其然，還要知道其所以然。 這樣做的目的，一方面是為了能夠更好的運用開源專案，另一方面學習開源專案也是很好的提高自己能力的方法。
很多人其實都是想要學習開源專案的，但是在真正實踐的過程中往往會誤入各種各樣的歧途，例如：
建議使用下面的方法來學習開源專案
例如，要理解 redis 的網路模型，我們不需要成為 redis 的開發者，也不需要一定要用到 redis，只要具備一定的網路程式設計基礎，再通過閱讀 redis 的原始碼，都可以學習 redis 這種單程序的 reactor 模型。
例如，nginx 使用紅黑樹來管理定時器，對於絕大部分人來說，只要知道這點就夠了，並不需要去研究 nginx 實現紅黑樹的原始碼是如何寫的，除非你需要修改這部分，但我認為極少人會有這個需求。
不要一上來就去看原始碼，而是要基本掌握了功能、原理、關鍵設計之後再去看原始碼，看原始碼的主要目的是為了學習其**的寫作方式，以及關鍵技術的實現。例如，redis 的 rdb 持久化模式「會將當前記憶體中的資料庫快照儲存到磁碟檔案中」，那這裡所謂的「資料庫快照」到底是怎麼做的呢？在 linux 平台上其實就是 fork 乙個子程序來儲存就可以了；那為何 fork 子程序就生成了資料庫快照了呢？這又和 linux 的父子程序機制以及 copy-on-write 技術相關了。
通過這種方式，既能夠快速掌握系統設計的關鍵點（redis 的 rdb 模式），又能夠掌握具體的程式設計技巧（記憶體快照）。
第一步 安裝
很多人看到「安裝」這個步驟都可能會覺得有點不以為然：「不就是對照手冊執行一下命令麼，沒什麼技術含量，用的時候裝一下就可以了」。事實上，安裝步驟遠遠不止這麼簡單，通過具體的安裝過程，你可以獲取到如下一些關鍵資訊：
nginx安裝目錄
這個目錄提供的資訊有：conf 是存放配置檔案的，logs 是存放日誌的，sbin 是執行程式，但是 html 是什麼呢？這個疑問會促使你繼續去研究和學習。
再來看看 redis，安裝完成後，目錄下只有乙個 bin 目錄，具體如下：
redis bin目錄
我相信大部分人看到這目錄都會感到有點驚訝：這也太簡單了吧，尤其是與 nginx 相比！因此也會自然而然的有一些疑問，例如 redis 如何配置？redis 日誌儲存在**？這些疑問同樣會促使你繼續去研究和學習，帶著問題去學習效率是最高的。
第二步 執行
安裝完成後，我們需要真正將系統執行起來，執行系統的時候有兩個地方要特別關注：命令列和配置檔案，它們主要提供了兩個非常關鍵的資訊：系統具備哪些能力和系統將會如何執行。這些資訊是我們窺視系統內部執行機制和原理的一扇視窗。例如，下面是 memcache 的啟動引數一部分：
memcache引數
通常情況下，如果我們將每個命令列引數和配置項的作用和原理都全部掌握清楚了的話，基本上對系統已經很熟悉了。我的乙個習慣是不管三七二十一，先把所有的配置項全部研究一遍，包括配置項的原理、作用、影響，並且嘗試去修改配置項然後看看系統會有什麼變化。例如，將 memcache 的「–conn-limit」改為 1 後，檢視多個連線請求時 memecache 會返回什麼錯誤、記錄什麼日誌等。
第三步 研究原理
完成前兩個步驟後，我們對系統已經有了初步的感覺和理解，此時可以更進一步去研究其原理。其實在研究命令列和配置項的時候已經涉及一部分原理了，但是還不系統，因此我們要專門針對原理進行系統性的研究。這裡的關鍵就是「系統性」三個字，怎麼才算系統性呢？主要體現在如下幾個方面：
這是我想特別強調的一點，只有清楚掌握技術方案的優缺點後才算真正的掌握這門技術，也只有掌握了技術方案的優缺點後才能在架構設計的時候做出合理的選擇。
優缺點主要通過對比來分析，即：我們將兩個類似的系統進行對比，看看它們的實現差異，以及不同的實現優缺點都是什麼。
典型的對比有 memcache 和 redis，例如（僅舉例說明，實際上對比的點很多），memcache 用多執行緒，redis 用單程序，各有什麼優缺點？memcache 和 redis 的集群方式，各有什麼優缺點？
即使是 redis 自身，我們也可以對比 rdb 和 aof 兩種模式的優缺點。
在你了解了什麼是「系統性」後，我來介紹一下原理研究的手段，主要有三種：
第四部 測試
通常情況下，如果你真的準備在實際專案中使用某個開源專案的話，必須進行測試。有的同學可能會說，網上的分析和測試文件很多，直接找一篇看就可以了？如果只是自己學習和研究，這樣做是可以的，因為構建完整的測試用例既需要耗費較多時間，又需要較多機器資源，如果每個專案都這麼做的話，投入成本有點大；但如果是要在實踐專案中使用，必須自己進行測試，因為網上搜的測試結果，不一定與自己的業務場景很契合，如果簡單參考別人的測試結果，很可能會得出錯誤的結論。例如，開源系統的版本不同，測試結果可能差異較大。同樣是 k-v 儲存，別人測試的 value 是 128 位元組，而你的場景 value 都達到了 128k 位元組，兩者的測試結果也差異很大，不能簡單照搬。
測試階段需要特別強調的一點就是：測試一定要在原理研究之後做，不能安裝完成立馬就測試！原因在於如果對系統不熟悉，很可能出現命令列、配置引數沒用對，或者執行模式選擇不對，導致沒有根據業務的特點搭建正確的環境、沒有設計合理的測試用例，從而使得最終的測試結果得出了錯誤結論，誤導了設計決策。曾經有團隊安裝完成 mysql 5.1 後就進行效能測試，測試結果出來讓人大跌眼鏡，經過定位才發現 innodb_buffer_pool_size 使用的是預設值 8m。
第五步 原始碼研究
原始碼研究的主要目的是學習原理背後的具體編碼如何實現，通過學習這些技巧來提公升我們自己的技術能力。例如 redis 的 rdb 快照、nginx 的多 reactor 模型、disruptor 如何使用 volatile 以及 cas 來做無鎖設計、netty 的 zero-copy 等，這些技巧都很精巧，掌握後能夠大大提公升自己的編碼能力。
通常情況下，不建議通讀所有原始碼，因為想掌握每行**的含義和作用還是非常耗費時間的，尤其是 mysql、nginx 這種規模的專案，即使是他們的開發人員，都不一定每個人都掌握了所有**。帶著明確目的去研究原始碼，做到有的放矢，才能事半功倍，這也是原始碼研究要放在最後的原因。
對於一些基礎庫，除了閱讀原始碼外，還可以自己寫個 demo 呼叫基礎庫完成一些簡單的功能，然後通過除錯來看具體的呼叫棧，通過呼叫棧來理解基礎庫的處理邏輯和過程，這比單純看**去理解邏輯要高效一些。例如，下面是 netty 4.1 版本的 telnet 伺服器樣例除錯的堆疊，通過堆疊我們可以看到完整的呼叫棧：
呼叫堆疊
時間分配
前面介紹的「自頂向下」5 個步驟，完整執行下來需要花費較長時間，而時間又是大部分技術人員比較稀缺的資源。很多人在學習技術的時候都會反饋說時間不夠，版本進度很緊，很難有大量的時間進行學習，但如果不學習感覺自己又很難提公升？面對這種兩難問題，具體該如何做呢？
通常情況下，以上 5 個步驟的前 3 個步驟，不管是已經成為架構師的技術人員，還是立志成為架構師的技術人員，在研究開源專案的時候都必不可少；第四步可以在準備採用開源專案的時候才實施，第五步可以根據你的時間來進行靈活安排。這裡的「靈活安排」不是說省略不去做，而是在自己有一定時間和精力的時候做，因為只有這樣才能真正理解和學到具體的技術。
如果感覺自己時間和精力不夠，與其蜻蜓點水每個開源專案都去簡單了解一下，還不如集中精力將乙個開源專案研究通透，就算是每個季度只學習乙個開源專案，積累幾年後這個數量也是很可觀的；而且一旦你將乙個專案研究透以後，再去研究其他類似專案，你會發現自己學習的非常快，因為共性的部分你已經都掌握了，只需要掌握新專案差異的部分即可。
談談如何高效學習開源專案
作者 陳彩華 隨著蓬勃發展的開源時代的到來，為了減少開發成本，提高開發效率，越來越多的公司使用各種開源專案，作為開發者，如果能充分利用好開源專案中的資源，不僅能提高實踐能力，專業知識水平，還能從中其中學到的優秀的架構思想。總結起來，學習開源專案的價值主要包括以下幾點 這些專業知識之間是可以聯絡起來的...
高效地學習開源專案
現狀 開源專案對團隊和業務有很大好處，但對於技術人員來說，如果只是簡單的採取 拿來主義 那就變成乙個陷阱 看似很快的使用開源專案實現了需求，但自己的技術水平並沒有什麼提公升 甚至可能出現看起來用了很多開源專案，知道很多專案名稱，但是技術水平止步不前。ps 雖然使用了開源專案，實現了需求，知道了很多開...
如何更加安全 高效地選擇開源專案
在平時的開發過程中，難免會遇到這樣那樣的難題，或者一些繁瑣且不想純手工完成的功能，對於這些問題，解決的姿勢有很多種，可以通過同事間的交流 上網查資料 去官網找文件等，隨著開源的推動和完善，尋找合適的開源專案支援，絕對是乙個很好的方法。如今市面上的開源專案魚龍混在，並且有一些專案早已停止更新維護，跑d...