Fabric v0.6版本與v1.x版本 架構差異很大，故分兩個版本講
Fabric v0.6版本
在Fabric v0.6中采用的共識算法是PBFT算法（Practical Byzantine Fault Tolerance）,可以在信任程度較低的場景下避免拜占庭問題。但是由于算法本身特性限制，n>=3f+1，才能容忍一個拜占庭節點，是以在v0.6版本下，vp節點數量至少是4個。在v0.6版本中，節點角色分為VP(Validating Peer)、NVP(None validating Peer)以及用于簽發證書的Membership節點3種。當然Fabric從第一個版本v0.6.0-preview開始就采用基于docker的運作時環境，為部署減少了許多麻煩，屏蔽了作業系統的差異。當然最主要的一點也許是由于Chaincode的設計機制導緻的，整套生産環境的鍊碼的部署和運作都是基于docker的，也許是出于docker穩定以及相對安全的運作環境的考量。Fabric的智能合約設計理論上可以支援任何開發語言(目前支援 Go, Node.js, Java)，隻要實作了相應的接口。因為它是基于Peer節點和鍊碼容器的一個雙向通信完成相應的互動的。
Fabric v0.6版本，相對于1.0版本的架構來說，這種設計來說，區塊鍊角色相對對稱，相對于1.0-1.4版本來說，不存在中心化的Kafka的存在，在實際場景中擁有更合理對等的節點設計。
Fabric v1.x
Fabric在1.0版本的時候，架構進行了重構，相比于v0.6版本來說，有了颠覆性的變革，功能子產品進行了結偶，具有了更好的可伸縮性、性能，進行了channel級别的安全隔離，共識算法可插拔，具備了更高的可操作性，具備了更豐富的功能，給開發者更好的體驗，v0.6版本中的Membership也更新為了一個獨立的Fabric CA項目。
這種設計的優勢在于可以将前後無關聯的交易以及不同Channel中的交易進行并行執行，提高交易的執行速度。在v0.6版本中是無法做到并行執行的，0.6中是統一進行排序打包，然後按序執行交易，即使交易前後是無關的。
Kafka共識
在v1.0-v1.4版本中，生産環境隻有基于分布式消息隊列Kafka的排序打包方式，Orderer作為生産者将交易統一發送至每個通道Channel對應的Topic的Partition當中進行全局統一地排序，同時每個排序節點基于同樣的切塊規則從Kafka中将區塊切下推送Deliver至與之連接配接的Leader Peer（在網絡環境良好的情況下，每個組織隻有一個leader），Leader Peer收到區塊後，會将區塊通過Gossip協定廣播至組織内其餘節點。
多通道技術（Muti-channel）
一個Fabric網絡中能夠運作多個賬本，每個通道間的邏輯互相隔離不受影響，如下圖所示，每種顔色的線條代表一個邏輯上的通道，每個Peer節點可以加入不同的通道，每個通道都擁有獨立的賬本、世界狀态、鍊碼以及Kafka中的Topic，通道間消息是隔離的，互不影響的。
每個Peer節點可以配置加入到多個不同的通道,不同業務的交易存儲在不同的通道對應的節點中
系統鍊碼
- ESCC：用于為鍊碼執行結果進行背書。
- VSCC：用于對接收到的區塊中的交易進行校驗。
存儲
- File System 即傳統的檔案系統: 區塊存儲部分
- Level DB : 記錄 Block的索引, 世界狀态的存儲
配置檔案
Fabric網絡在啟動之前，需要提前生成一些用于啟動的配置檔案，主要包括MSP相關檔案（msp/）、TLS相關檔案（tls/）、系統通道初始區塊（orderer.genesis.block）、建立應用通道交易檔案（businesschannel.tx）、錨節點配置更新交易檔案Org1MSPanchors.tx和Org2MSPanchors.tx）等。