???? “Python貓” ，一個值得加星標的公衆號
前不久，我寫了一篇《Fabric教程》，簡單來說，它是一個用 Python 開發的輕量級的遠程系統管理工具，在遠程登錄服務器、執行 Shell 命令、批量管理服務器、遠程部署等場景中，十分好用。
Fabric 2 是其最新的大版本，跟早前的 Fabric 1 有挺大的不同，更加好用了，但是沒填上的坑也挺多的……
本文繼續來聊聊 Fabric，不過我不想再面面俱到了，而是專注於這一個話題：它是如何實現對批量服務器的串行/併發管理的？
（友情提示：爲了有更好的閱讀體驗，如果你還不瞭解 Fabric 的基礎用法，建議先閱讀前面的教程。）
Fabric 通過 Group 來組合多臺服務器。區別在於由 fabric.group.Group 基類（父類）派生出的兩個子類：
SerialGroup(*hosts, **kwargs)：按串行方式執行操作
ThreadingGroup(*hosts, **kwargs)：按併發方式執行操作
下面先看看這個基類：
我把一些沒用的信息摺疊了，比較值得注意的內容有：
Group 繼承了 list，所以能夠 extend() ，對傳入的服務器分別建立 connection
核心的 run() 方法沒有寫實現，用意是留給子類再實現
最後的 __enter__() 和 __exit__() 實現了上下文管理器
有了這個基類，接下來就要看 SerialGroup 和 ThreadingGroup 的具體實現了。
SerialGroup 類很簡單，只實現了一個 run() 方法。因爲類在初始化時爲所有 host 建立了連接而且存了起來，所以這裏只需用 for 循環依次取出，再執行 Connection 的 run() 方法。
這裏可以看到一種非常實用的開發技巧：創建類時，讓它繼承內置的數據結構（如 list、dict）， 這樣可以直接使用 self.append()、self.extend()、self.update() 等方法把關鍵的信息存到“自身”，再到取出時則“for xxx in self”，這樣就免了創建臨時的 list 或 dict，也免得要在參數中傳來傳去。
GroupResult 和 GroupException 是對執行結果和異常的處理，不是我們關注的重點，這裏略過。
接下來看看 ThreadingGroup，它也只有一個 run() 方法：
ExceptionHandlingThread 是一個繼承了 threading.Thread 的類，這是一種創建多線程的方式。每個線程執行的方法主要做兩件事：執行 connection 的 run() 方法，以及將執行成功的結果存入隊列中。
接下來再分別把執行成功的結果與出異常的結果都存入到 results 中。
所以，Fabric 是使用了 threading 多線程的方式來實現併發。網絡請求是 IO 密集型的，使用多線程是不錯的方式。
至此，對於我們在開頭提的問題，就有了一個初步的答案：Fabric 封裝了兩種 Group 來批量管理服務器，其中串行方式就是用了簡單的 for 循環，而併發方式使用了 threading 多線程方式。
但是，通過分析這兩種 Group 的實現代碼（以及使用的實踐），我們也可以發現 Fabric 的缺陷：
Group 只實現了 run() 方法，但是 Connection 的 put()、get()、sudo() 等方法都沒有，這意味着用這種方式管理服務器集羣時，只能在上面執行 shell 命令……
每次調用 run() 方法時，它要等所有主機都執行完，纔會返回結果，這意味着先執行完的主機會被阻塞。更爲致命的是，如果其中一臺主機執行時出了異常，整個 run() 方法就拋異常，這意味着每次使用 run() 方法時，都需要作異常捕獲
run() 方法支持執行單條 shell 命令，但是命令的狀態不會傳遞。假設先在一個 run() 方法中運行 cd 命令切到 A 目錄（非根目錄），再在下一個 run() 方法創建一個文件，最終結果是該文件並不在 A 目錄，而是在默認目錄。解決辦法是用“&&”連接起多條命令，略顯麻煩
這幾個問題在 Fabric 的 Github issue 中，被不同的人反覆提出，但是還沒有得到很好的迴應……
言歸正傳，本文主要分析了 Fabric 在批量管理服務器時的實現方案，閱讀其源碼，可以瞭解到串行/併發典型場景的用法，以及類定義、類繼承、多線程、異常處理等內容，最後，我們還揭示出了它的幾個特性缺陷。
感謝閱讀。最後，附上 Fabric 教程：如何高效地遠程部署？自動化運維利器 Fabric 教程
後臺回覆“交流羣”，邀請加入學習交流羣
優質文章，推薦閱讀：
