一、架構
fabric可以從邏輯架構和系統架構兩種層面上來解析，先看一下二者的結構圖：
1、邏輯架構圖：
從邏輯架構構圖上來理解Fabric的整體的邏輯，聯盟鏈和公鏈的不同之處在於，其邏輯結構有着完全的不同。比如看上面的邏輯結構，就會發現，較之於常見的公鏈體系，它要複雜的多。在普通的公鏈邏輯體系中，可以認爲只有一個節點，既當爹又當媽，反正該操心的事兒他一個人都幹了。可是在聯盟鏈，特別是Fabric中，由於許可的存在，導致鏈本身的節點功能發生了本質的改變。
在聯盟鏈上，節點仍然是那個節點（Peer），但是根據其實現的功能不同，可以分爲CA節點，TLS節點，背書結點，提交節點，存儲節點（記帳節點），排序節點，Leader節點，錨節點。這些節點，在一起共同組成了基礎的邏輯節點。在向上走，又抽象出組織，排序，CA集羣和存儲這些概念。
這些邏輯節點，和普通的Peer節點有的是完全一致的，有的是多重兼有的，比如Leader節點，它也是提交節點。他本身也是存儲節點，如果設置爲錨節點的話它又是錨節點。下面說明一下這些概念：
CA節點：這個好理解，可以簡單理解成證書管理的節點。
TLS節點：這個和上面相似，控制TLS訪問的相關證書節點。
背書結點：首先得明白背書和背書策略，背書可以簡單理解成對執行某種操作前的一個驗和籤的過程。而背書策略指如何對操作進行背書即達到成功的規則。
這樣就明白了背書節點，它就是執行背書過程能實現背書策略的節點。
提交節點：組織中每一個對等節點都是提交結點。
存儲節點：存儲數據的節點，包括存儲帳本或者相關的狀態數據的節點。
排序節點：負責對交易排序出塊的節點。
Leader節點：爲了減少對等節點傳播的複雜性，排序節點只把交易出塊後的信息發給指定的Leader節點，由他來向同組織的其它對等節點發送。可以動態選舉或者靜態指定。
錨節點：在跨組織的過程中，可以在配置文件中指定某個節點跨組織通信，這個是可選的。
邏輯上，Fabric通過組織來劃分不同的邏輯域，那麼有沒有具體的規則來劃分組織呢？目前沒有，組織的劃分更傾向於實際的應用和設計者的個人傾向。一般來說可以參考以下幾點：是否爲區塊鏈數據應用的主要部分；規模大小（原則上要有一定的規模性，太大和太小都無法呼應組織本身的劃分邏輯）。是否控制區塊鏈業務的核心部分。
組織的管理可以是集中式的，由單一某個邏輯節點來完成，也可以是聯盟式的，即通過選舉來實現。組織的外面表現可以是一個公司，一個團體或者政府機構。當然，從業務管理的角度也可以劃分成，鏈的運營管理方和鏈的業務應用方。
通道（Channel），主要用於實現鏈上的業務的隔離；一業務一通道，一通道一帳本，在同一個通道中，每個Peer都是一個對等體（這個概念在Fabric中出現比較多），這也和其它公鏈類似，即每個對等體內存儲着相同的數據。顯然，這會造成一定的數據浪費，所以在Fabric中提供了Couchdb來實現分佈式的數據存儲，減少數據存儲的成本。
組織和通道有什麼關係呢？組織更傾向於在上層的邏輯上的劃分，強調的是寬泛的宏觀的管理。通道則是具體的業務的把控者，到底誰可以加入通道（業務），由它來確定。組織是原則，通道是手段。通道通過MSP來確定參與方的合法性。
一個Fabric網絡包含一個或多個組織且含有不少於一臺排序服務集，一個組織包含一個或多個節點服務，一個節點服務可以加入一個或多個通道，一個通道可以安裝一個或多個智能合約。
在設計時，要根據實際情況和運維的安全性簡便性進行仔細劃分。
2、系統架構圖：
在Fabric中，由上圖可以看到，從宏觀角度，其劃分的主要的模塊和層次。而在實際的工程中，其也分爲五大模塊，邏輯上和此圖相應，即：
cryptogen:生成組織結構和帳號相關，對應着密碼部分。
configtxgen:創世塊等初始文件和通道初始文件，對應容器、共識等。
configtxlator:二進制文件和JSON的轉換，對應着帳本、交易等。
orderer:排序服務，對應着圖中的共識、區塊等。
peer:一個整體上的邏輯概念，對應着帳本數據、鏈碼、容器、MSP、接口等。
也就是說，邏輯上的概念和具體的模塊的對應，還是應該清晰的瞭解，這樣才能在後面的代碼分析中，不亂了自己的陣腳。其實在代碼分析中，重點還是傾向於對流程中產生的代碼進行分析，也就是說對Orderer和Peer的內容進行了重點分析，而對其它幾個，遇到相關部分則分析一下。
二、流程
整體的流程圖如下：
在Fabric中，一個基本的交易流程，其實就代表了整體的流程的大部分。所以從一個交易入手來分析區塊鏈（不管是公鏈還是聯盟鏈），其實是最好的一種辦法。從這個角度看整個鏈，會有一個相當清晰的脈絡把握。
在上面的圖中，一個交易，基本上從客戶端（SDK或APP）發起，然後根據背書策略發送交易提案到相關的背書節點，背書節點拿到提案後，驗證簽名，模擬執行，創建讀寫集，簽名然後返回結果給客戶端，客戶端依次收集背書策略中要求發送至節點的返回結果，如果符合背書策略後，利用SDK打包交易（驗證策略，打包提案、提案反饋和背書籤名），然後發送到排序節點。排序服務器根據不同的通道按時間順序排序，生成區塊（RAFT共識就在此處），注意，此處不進行區塊交易合法性驗證。廣播區塊到各個組織的Leader節點，其它驗證區塊後廣播給相關組織的通道成員，並且每個成員都要進行相同的校驗處理。
所有合法的區塊交易都會將寫入狀態寫入數據庫（狀態數據庫和帳本數據庫）並更新世界狀態。
三、總結
架構和流程分析完成，下來就正式開始分析整個源碼的流程和相關模塊的具體的應用。一如既往，從整體的流程代碼走通後，會重點分析用到的相關的模塊和接口。在分析完成這些模塊後，會對重點部分如共識、密碼學等再分別進行分析。由上而下，提綱挈領，漸漸深入。