【我的區塊鏈之路】- Hyperledger fabric的簡單入門（三）fabric主要配置檔案細講
阿新 • • 發佈：2019-01-18
fabric的各個配置檔案做講解
-
Peer 配置剖析
本例子是拿fabric-samples 來說的，【如果是 fabric 的話，在 fabric/的根目錄下有一個 core.yaml 】在 fabric-samples/config 目錄下有一個 core.yaml 檔案 該檔案就是 peer 節點的各項配置，其中主要包含了：logging （日誌）、 peer （節點）、 vm （鏈碼執行環境）、chaincode （鏈碼相關）、ledger （賬本） 等 5 大部分
檔案內容及各項說明如下所示：
logging: ## 日誌級別有： critical、 error、 warning、 notice、 info、 debug 級別由大到小， 級別越小輸出越詳細 level: info ## 全域性的預設日誌級別 ## 各個模組日誌級別， 覆蓋全域性配置 cauthdsl: warning ## gossip: warning grpc: error ledger: info msp: warning policies: warning peer: gossip: warning # 日誌的輸出格式 format: '%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}' ############################################################################### # # Peer section peer部分 # ############################################################################### peer: id: jdoe ## Peer節點ID networkId: dev ## 網路ID listenAddress: 0.0.0.0:7051 ## 節點監聽的本地網路介面地址 chaincodeAddress: 0.0.0.0:7052 ## 鏈碼容器連線時的監聽地址 如未指定, 則使用listenAddress的IP地址和7052埠 address: 0.0.0.0:7051 ## 節點對外的服務地址 （對外的地址）【還有人說是 與同組織內其他peer通訊的地址; 配置在cli節點上表示peer與其通訊的地址 ？？】 addressAutoDetect: false ## 是否自動探測服務地址 (預設 關閉， 如果啟用TLS時，最好關閉) gomaxprocs: -1 ## Go的程序限制數 runtime.GOMAXPROCS(n) 預設 -1 keepalive: ## 客戶端和peer間的網路心跳連線配置 minInterval: 60s ## 最小的心跳間隔時間 client: ## 該節點和客戶端 的互動配置 interval: 60s ## 和客戶端 的心跳間隔 必須 interval >= minInterval timeout: 20s ## 和客戶端 間的網路連線超時時間 deliveryClient: ## 交付客戶端用於與訂購節點通訊的心跳 interval: 60s timeout: 20s gossip: ## 節點間通訊的gossip 協議的P2P通訊 【主要包含了 啟動 及 連線】 bootstrap: 127.0.0.1:7051 ## 啟動節點後 向哪些節點發起gossip連線，以加入網路，且節點相互間都是同一個組織的 useLeaderElection: true ## 是否啟動動態選舉 組織的Leader 節點 與 orgLeader 互斥 orgLeader: false ## 是否指定本節點為 組織Leader 節點 與 useLeaderElection 互斥 endpoint: ## 本節點在組織內的gossip id maxBlockCountToStore: 100 ## 儲存到記憶體的區塊個數上限 maxPropagationBurstLatency: 10ms ## 儲存訊息的最大時間，超過則觸發轉發給其他節點 maxPropagationBurstSize: 10 ## 儲存的最大訊息個數，超過則觸發轉發給其他節點 propagateIterations: 1 ## 訊息轉發的次數 propagatePeerNum: 3 ## 推送訊息給指定個數的節點 pullInterval: 4s ## 拉取訊息的時間間隔 (unit: second) 必須大於 digestWaitTime + responseWaitTime pullPeerNum: 3 ## 從指定個數的節點拉取訊息 requestStateInfoInterval: 4s ## 從節點拉取狀態資訊(StateInfo) 訊息間隔 (unit: second) publishStateInfoInterval: 4s ## 向其他節點推動狀態資訊訊息的間隔 (unit: second) stateInfoRetentionInterval: ## 狀態資訊訊息的超時時間 (unit: second) publishCertPeriod: 10s ## 啟動後在心跳訊息中包括證書的等待時間 skipBlockVerification: false ## 是否不對區塊訊息進行校驗，預設為false dialTimeout: 3s ## gRPC 連線撥號的超時 (unit: second) connTimeout: 2s ## 建立連線的超時 (unit: second) recvBuffSize: 20 ## 收取訊息的緩衝大小 sendBuffSize: 200 ## 傳送訊息的緩衝大小 digestWaitTime: 1s ## 處理摘要資料的等待時間 (unit: second) 可以大於 requestWaitTime requestWaitTime: 1500ms ## 處理nonce 資料的等待時間 (unit: milliseconds) 可以大於 digestWaitTime responseWaitTime: 2s ## 終止拉取資料處理的等待時間 (unit: second) aliveTimeInterval: 5s ## 定期傳送Alive 心跳訊息的時間間隔 (unit: second) aliveExpirationTimeout: 25s ## Alive 心跳訊息的超時時間 (unit: second) reconnectInterval: 25s ## 斷線後重連的時間間隔 (unit: second) externalEndpoint: ## 節點被組織外節點感知時的地址，公佈給其他組織的地址和埠, 如果不指定, 其他組織將無法知道本peer的存在 election: ## Leader 節點的選舉配置 startupGracePeriod: 15s ## leader節點選舉等待的時間 (unit: second) membershipSampleInterval: 1s ## 測試peer穩定性的時間間隔 (unit: second) leaderAliveThreshold: 10s ## pear 嘗試進行選舉的等待超時 (unit: second) leaderElectionDuration: 5s ## pear 宣佈自己為Leader節點的等待時間 (unit: second) pvtData: ## 這個我還真不知道幹嘛的？誰知道告訴我 pullRetryThreshold: 60s transientstoreMaxBlockRetention: 1000 pushAckTimeout: 3s btlPullMargin: 10 events: ## 事件配置 address: 0.0.0.0:7053 ## 本地服務監聽地址 (預設在所有網路介面上進心監聽，埠 7053) buffersize: 100 ## 最大緩衝訊息數，超過則向緩衝中傳送事件訊息會被阻塞 timeout: 10ms ## 事件傳送超時時間, 如果事件快取已滿, timeout < 0, 事件被丟棄; timeout > 0, 阻塞直到超時丟棄, timeout = 0, 阻塞直到傳送出去 timewindow: 15m ## 允許peer和 客戶端 時間不一致的最大時間差 keepalive: ## 客戶端到peer間的事件心跳 minInterval: 60s sendTimeout: 60s ## 在GRPC流上向客戶端傳送事件的超時時間 tls: ## tls配置 enabled: false ## 是否開啟 TLS，預設不開啟TLS clientAuthRequired: false ## 客戶端連線到peer是否需要使用加密 cert: ## 證書金鑰的位置, 各peer應該填寫各自相應的路徑 file: tls/server.crt ## 本服務的身份驗證證書，公開可見，訪問者通過該證書進行驗證 key: file: tls/server.key ## 本服務的簽名私鑰 rootcert: file: tls/ca.crt ## 信任的根CA整數位置 clientRootCAs: ## 用於驗證客戶端證書的根證書頒發機構的集合 files: - tls/ca.crt clientKey: ## 當TLS金鑰用於製作客戶端連線。如果不設定，將使用而不是peer.tls.key.file file: clientCert: ## 在進行客戶端連線時用於TLS的X.509證書。 如果未設定，將使用peer.tls.cert.file file: serverhostoverride: ## 是否制定進行TLS握手時的主機名稱 authentication: ## 身份驗證包含與驗證客戶端訊息相關的配置引數 timewindow: 15m ## 客戶端請求訊息中指定的當前伺服器時間與客戶端時間之間的可接受差異 fileSystemPath: /var/hyperledger/production ## peer資料儲存位置(包括賬本,狀態資料庫等) BCCSP: ## 加密庫配置 與Orderer 配置一樣 Default: SW ## 使用軟體加密方式 (預設 SW) SW: Hash: SHA2 ## Hash 演算法型別，目前僅支援SHA2 Security: 256 FileKeyStore: ## 本地私鑰檔案路徑，預設指向 <mapConfigPath>/keystore KeyStore: # Settings for the PKCS#11 crypto provider (i.e. when DEFAULT: PKCS11) PKCS11: ## 設定 PKCS#11 加密演算法 (預設PKCS11) Library: ## 本地PKCS11依賴庫 Label: ## token的標識 Pin: ## 使用Pin Hash: Security: FileKeyStore: KeyStore: mspConfigPath: msp ## msp 的本地路徑 localMspId: SampleOrg ## Peer 所關聯的MSP 的ID client: ## cli 公共客戶端配置選項 connTimeout: 3s ## 連線超時時間 deliveryclient: ## 交付服務配置 reconnectTotalTimeThreshold: 3600s ## 交付服務交付失敗後嘗試重連的時間 connTimeout: 3s ## 交付服務和 orderer節點的連線超時時間 reConnectBackoffThreshold: 3600s ## 設定連續重試之間的最大延遲 localMspType: bccsp ## 本地MSP型別 （預設為 BCCSP） profile: ## 是否啟用Go自帶的profiling 支援進行除錯 enabled: false listenAddress: 0.0.0.0:6060 adminService: ## admin服務用於管理操作，例如控制日誌模組嚴重性等。只有對等管理員才能使用該服務 handlers: authFilters: - name: DefaultAuth - name: ExpirationCheck ## 此篩選器檢查身份x509證書過期 decorators: - name: DefaultDecorator endorsers: escc: name: DefaultEndorsement library: validators: vscc: name: DefaultValidation library: validatorPoolSize: ## 處理交易驗證的併發數, 預設是CPU的核數 discovery: ## 客戶端使用發現服務來查詢有關peers的資訊，例如 - 哪些peer已加入某個channel，最新的channel配置是什麼，最重要的是 - 給定chaincode和channel，哪些可能的peer滿足認可 policy enabled: true authCacheEnabled: true authCacheMaxSize: 1000 authCachePurgeRetentionRatio: 0.75 orgMembersAllowedAccess: false ############################################################################### # # VM section 鏈碼執行環境配置 目前主要支援 Docker容器 # ############################################################################### vm: endpoint: unix:///var/run/docker.sock ## Docker Daemon 地址，預設是本地 套接字 docker: tls: ## Docker Daemon 啟用TLS時的相關證書配置, 包括信任的根CA證書、服務身份證書、簽名私鑰等等 enabled: false ca: file: docker/ca.crt cert: file: docker/tls.crt key: file: docker/tls.key attachStdout: false ## 是否啟用繫結到標準輸出，啟用後 鏈碼容器 的輸出訊息會繫結到標準輸出，方便進行除錯 hostConfig: ## Docker 相關的主機配置，包括網路配置、日誌、記憶體等等，這些配置在啟動鏈碼容器時進行使用 NetworkMode: host Dns: # - 192.168.0.1 LogConfig: Type: json-file Config: max-size: "50m" max-file: "5" Memory: 2147483648 ############################################################################### # # Chaincode section 鏈碼相關配置 # ############################################################################### chaincode: id: ## 記錄鏈碼相關資訊，包括路徑、名稱、版本等等，該資訊會以標籤形式寫到鏈碼容器 path: name: builder: $(DOCKER_NS)/fabric-ccenv:latest ## 通用的本地編譯環境，是一個Docker 映象 pull: false ## golang: ## Go語言的鏈碼部署生成映象的基礎Docker映象 runtime: $(BASE_DOCKER_NS)/fabric-baseos:$(ARCH)-$(BASE_VERSION) dynamicLink: false car: ## car格式的鏈碼部署生成映象的基礎Docker 映象 runtime: $(BASE_DOCKER_NS)/fabric-baseos:$(ARCH)-$(BASE_VERSION) java: ## java語言的基礎映象 Dockerfile: | from $(DOCKER_NS)/fabric-javaenv:$(ARCH)-1.1.0 node: ## node.js的基礎映象 runtime: $(BASE_DOCKER_NS)/fabric-baseimage:$(ARCH)-$(BASE_VERSION) startuptimeout: 300s ## 啟動鏈碼容器超時，等待超時時間後還沒收到鏈碼段的註冊訊息，則認為啟動失敗 executetimeout: 30s ## invoke 和 initialize 命令執行超時時間 deploytimeout: ## 部署鏈碼的命令執行超時時間 mode: net ## 執行鏈碼的模式，dev: 允許本地直接執行鏈碼，方便除錯； net: 意味著在容器中執行鏈碼 keepalive: 0 ## Peer 和鏈碼之間的心跳超市時間， <= 0 意味著關閉 system: ## 系統鏈碼的相關配置 (系統鏈碼白名單 ??) cscc: enable lscc: enable escc: enable vscc: enable qscc: enable systemPlugins: ## 系統鏈碼外掛 logging: ## 鏈碼容器日誌相關配置 level: info shim: warning format: '%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}' ############################################################################### # # Ledger section - ledger configuration encompases both the blockchain # and the state 賬本相關配置 # ############################################################################### ledger: blockchain: ## 設定系統區塊鏈的整體配置，【後面會被丟棄】 state: ## 狀態DB的相關配置(包括 golevelDB、couchDB)、DN連線、查詢最大返回記錄數等 stateDatabase: goleveldb ## stateDB的底層DB配置 (預設golevelDB) couchDBConfig: ## 如果啟用couchdb，配置連線資訊 (goleveldb 不需要配置這些) couchDBAddress: 127.0.0.1:5984 username: o prevent unintended users from discovering the password. password: maxRetries: 3 ## 執行時出錯重試數 maxRetriesOnStartup: 10 ## 啟動時出錯的重試數 requestTimeout: 35s ## 請求超時時間 queryLimit: 10000 ## 每個查詢最大返回數 maxBatchUpdateSize: 1000 ## 批量更新最大記錄數 warmIndexesAfterNBlocks: 1 history: enableHistoryDatabase: true ## 是否啟用歷史資料庫，預設開啟 ############################################################################### # # Metrics section 服務度量監控配置 # # ############################################################################### metrics: enabled: false ## 是否開啟監控服務 reporter: statsd interval: 1s statsdReporter: address: 0.0.0.0:8125 flushInterval: 2s flushBytes: 1432 promReporter: ## prometheus 普羅米修斯服務監聽地址 listenAddress: 0.0.0.0:8080
-
Orderer 配置剖析
在 fabric-samples/config 目錄下有一個 orderer.yaml 檔案 該檔案就是 Orderer 節點的各項配置，其中主要包含了：General（日誌）、 FileLedger（節點）、 RAMLedger（鏈碼執行環境）、Kafka（鏈碼相關） 等 4 大部分
檔案內容及各項說明如下所示：
################################################################################ # # Orderer Configuration orderer的配置 # # - This controls the type and configuration of the orderer. # ################################################################################ General: LedgerType: file ## 賬本型別，支援ram、json、file 三種類型【建議用file】，其中ram儲存在記憶體中；json、file儲存在本地檔案中 (通常為 /var/hyperledger/production/orderer 下) ListenAddress: 127.0.0.1 ## 服務監聽地址，一般需要制定為服務的特定網路介面地址 或者全網(0.0.0.0) ListenPort: 7050 ## 服務監聽埠 預設7050 TLS: ## 啟用TLS 時的相關配置 (grpc 傳輸) Enabled: false PrivateKey: tls/server.key ## Orderer 簽名私鑰 Certificate: tls/server.crt ## Orderer 身份證書 RootCAs: - tls/ca.crt ## 根證書 ClientAuthRequired: false ## 是否對客戶端也進行認證 ClientRootCAs: Keepalive: ## 設定GRPC 服務心跳檢查 ServerMinInterval: 60s ## 客戶端和 orderer 的 最小心跳間隔 ServerInterval: 7200s ## 客戶端和 orderer 的心跳間隔時間 ServerTimeout: 20s ## 客戶端和 Orderer 的超時時間 LogLevel: info ## 日誌等級 ## 日誌輸出格式 LogFormat: '%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}' GenesisMethod: provisional ## 創世塊的提供方式 (系統通道初始區塊的提供方式，支援 provisional 或者 file；前者根據GenesisProfile 指定預設的 $FABRIC_CFG_PATH/config.yaml 檔案中的profile生成；後者使用GenesisFile 指定現成的初始區塊檔案) GenesisProfile: SampleInsecureSolo ## 創世塊使用的Profile；GenesisMethod: provisional 才有效 GenesisFile: genesisblock ## 使用現成創世塊檔案時，檔案的路徑 [創世塊的位置] GenesisMethod: file 才有效 LocalMSPDir: msp ## 本地MSP檔案的路徑 【orderer節點所需的安全認證檔案的位置】 LocalMSPID: SampleOrg ## Orderer所關聯的MSP的ID MSP管理器用於註冊安全認證檔案的ID, 此ID必須與配置系統通道和創世區塊時(configtx.yaml的OrdererGenesis部分)指定的組織中的某一個組織的ID一致 Profile: ## 為Go pprof效能優化工具啟用一個HTTP服務以便作效能分析(https://golang.org/pkg/net/http/pprof) Enabled: false ## 不啟用 Address: 0.0.0.0:6060 ## Go pprof的HTTP服務監聽的地址和埠 BCCSP: ## 加密庫配置 具體參照Peer 配置 Default: SW SW: Hash: SHA2 Security: 256 FileKeyStore: KeyStore: Authentication: TimeWindow: 15m ################################################################################ # # SECTION: File Ledger 基於檔案賬本 配置 (file和json兩種型別) # # - This section applies to the configuration of the file or json ledgers. # ################################################################################ FileLedger: Location: /var/hyperledger/production/orderer ## 指定存放檔案的位置，一般為 /var/hyperledger/production/orderer, 該目錄下的 chains目錄存放各個chain的區塊，index目錄存放 索引檔案 (如果這項不指定, 每次節點重啟都將使用一個新的臨時位置) Prefix: hyperledger-fabric-ordererledger ## 如果不指定Location，則在臨時目錄下建立賬本時目錄的名稱 ################################################################################ # # SECTION: RAM Ledger 基於記憶體賬本 配置 # # - This section applies to the configuration of the RAM ledger. # ################################################################################ RAMLedger: HistorySize: 1000 ## 記憶體賬本所支援儲存的區塊的數量, 如果記憶體中儲存的區塊達到上限, 繼續追加區塊會導致最舊的區塊被丟棄 ################################################################################ # # SECTION: Kafka kafka 叢集配置 # # - This section applies to the configuration of the Kafka-based orderer, and # its interaction with the Kafka cluster. # ################################################################################ Kafka: # kafka是一種基於釋出/訂閱模式的分散式訊息系統 # fabric網路中, orderer節點叢集組成kafka叢集, 客戶端是kafka叢集的Producer(訊息生產者), peer是kafka叢集的Consumer(訊息消費者) # kafka叢集使用ZooKeeper(分散式應用協調服務)管理叢集節點, 選舉leader. Retry: ## 連線時的充實操作 kafka 會利用 sarama 客戶端為chennel建立一個producer 負責向kafka 寫資料，一個comsumer負責kafka讀資料 ShortInterval: 5s ## 操作失敗後的快速重試間隔時間 ShortTotal: 10m ## 快速重試階段最對重試多久 LongInterval: 5m ## 快速充實階段仍然失敗後進入 慢重試階段，慢重試的時間間隔 LongTotal: 12h ## 慢重試最多重試多久 # https://godoc.org/github.com/Shopify/sarama#Config NetworkTimeouts: ## Sarama 網路超時時間 DialTimeout: 10s ReadTimeout: 10s WriteTimeout: 10s Metadata: ## kafka叢集leader 選舉中的metadata 請求引數 RetryBackoff: 250ms ## leader選舉過程中元資料請求失敗的重試間隔 RetryMax: 3 ## 最大重試次數 Producer: ## 傳送訊息到kafka叢集時的超時 RetryBackoff: 100ms ## 向kafka叢集傳送訊息失敗後的重試間隔 RetryMax: 3 ## 最大重試次數 Consumer: ## 從kafka叢集接收訊息時的超時 RetryBackoff: 2s ## 從kafka叢集拉取訊息失敗後的重試間隔 Verbose: false ## 是否開啟kafka的客戶端的除錯日誌 (orderer與kafka叢集互動是否生成日) TLS: ## 與kafka叢集的連線啟用TLS時的相關配置 Enabled: false ## 是否開啟TLS，預設不開啟 PrivateKey: ## Orderer 身份簽名私鑰 # File: ## 私鑰檔案路徑 Certificate: ## kafka的身份證書 # File: ## 證書檔案路徑 RootCAs: ## 驗證kafka證書時的根證書 # File: ## 根證書檔案路徑 Version: ## kafka的版本，預設為 0.9.0.1 ################################################################################ # # Debug Configuration orderer節點的除錯引數 # # - This controls the debugging options for the orderer # ################################################################################ Debug: BroadcastTraceDir: ## 該orderer節點的廣播服務請求儲存的位置 DeliverTraceDir: ## 該orderer節點的傳遞服務請求儲存的位置
-
核心配置 crypto-config.yaml 配置剖析
我們在【我的區塊鏈之路】- Hyperledger fabric的簡單入門（二）中已經知道，在啟動網路前，我們需要做一些準備工作，例如： 先使用cryptogen工具及 crypto-config.yaml 配置檔案，生成整個fabric網路的組織架構及對應的身份證書；在crypto-config.yaml 檔案中我們定義了 整個fabric網路的組織結構，然後工具會根據定義的配置生成對應的組織結構及把對應的身份證書放置對應的目錄下以便區分使用；
具體的 crypto-config.yaml 檔案內容如下所示：
OrdererOrgs: ## 定義Orderer組織結構
- Name: Orderer ## Orderer的名稱
Domain: example.com ## 組織的命名域
# ---------------------------------------------------------------------------
# "Specs" - 有關完整說明，請參閱下面的PeerOrgs
# ---------------------------------------------------------------------------
Specs:
- Hostname: orderer
# ---------------------------------------------------------------------------
# "PeerOrgs" - 管理Peer節點的組織的定義
# ---------------------------------------------------------------------------
PeerOrgs:
- Name: Org1 ## 組織名稱 組織 1
Domain: org1.example.com ## 組織域
EnableNodeOUs: true ## 如果設定了EnableNodeOUs，就在msp下生成config.yaml檔案
Template: ## 允許定義從模板順序建立的1個或多個主機。 預設情況下，這看起來像是從0到Count-1的“peer”。 您可以覆蓋節點數（Count），起始索引（Start）或用於構造名稱的模板（Hostname）。
Count: 2 ## 表示生成幾個Peer
# Start: 5
# Hostname: {{.Prefix}}{{.Index}} # default
# ---------------------------------------------------------------------------
# "Users"
# ---------------------------------------------------------------------------
# Count: 除Admin之外的使用者帳戶數量
# ---------------------------------------------------------------------------
Users:
Count: 1 ## 表示生成幾個 普通User
# ---------------------------------------------------------------------------
# Org2: 參照 組織 1
# ---------------------------------------------------------------------------
- Name: Org2
Domain: org2.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1
緊接著我們就可以使用命令來生成我們的組織結構及對應目錄下的身份證書了：
cryptogen generate --config=./crypto-config.yaml上述命令預設會在當前目錄生成一個名叫 crypto-config 目錄，當然也可以在命令中新增 --output 選項來指定輸出的目錄；在這個目錄下就會根據Orderer 和Peer 各自生成兩個 資料夾： ordererOrganizations 和 peerOrganizations 分別代表著Orderer 和Peer的組織及對應目錄下的證書檔案；每個組織樹下都有ca、msp、orderers(或者Peers)、users 等4個目錄；下面我們來詳細的說明下這兩個組織下都是些什麼：
. ## Orderer 組織配置
├── ordererOrganizations
│ │
│ └── example.com
│ │
│ ├── ca ## 存放組織根證書 及 私鑰 (採用EC演算法) 證書為【自簽名】，組織內的實體將給予該根證書作為證書根
│ │
│ │ ├── 56d9c0c46acdda38a174a5ba3ffc44726a2c027e16bb22b460413acbcb9b3a90_sk
│ │ │
│ │ └── ca.example.com-cert.pem
│ │
│ ├── msp ## 存放該組織身份資訊
│ │ │
│ │ ├── admincerts ## 組織管理員 身份驗證證書，【被根證書籤名】
│ │ │ │
│ │ │ └── [email protected]
│ │ │
│ │ ├── cacerts ## 組織的根證書 【和CA目錄 裡面一致】
│ │ │ │
│ │ │ └── ca.example.com-cert.pem
│ │ │
│ │ └── tlscacerts ## 用於TLS的CA證書， 【自簽名】
│ │ │
│ │ └── tlsca.example.com-cert.pem
│ │
│ │
│ ├── orderers ## 存放所有 Orderer 的身份資訊
│ │ │
│ │ └── orderer.example.com ## 第一個 Orderer 的資訊 msp 及 tls
│ │ │
│ │ ├── msp
│ │ │ │
│ │ │ ├── admincerts ## 組織管理員的身份驗證證書。Peer將給予這些證書來確認交易簽名是否為管理員簽名 【和MSP.admincerts 一致】
│ │ │ │ │
│ │ │ │ └── [email protected]
│ │ │ │
│ │ │ ├── cacerts
│ │ │ │ │
│ │ │ │ └── ca.example.com-cert.pem ## 存放組織根證書，【和CA目錄 裡面一致】
│ │ │ │
│ │ │ ├── keystore ## 本節點的身份私鑰，用來簽名
│ │ │ │ │
│ │ │ │ └── 2ec1193fe048848eaa8e20666e26c527b791c4fb127d69cae65095bd31b6c80e_sk
│ │ │ │
│ │ │ ├── signcerts ## 驗證本節點簽名的證書，【被根證書籤名】
│ │ │ │ │
│ │ │ │ └── orderer.example.com-cert.pem
│ │ │ │
│ │ │ └── tlscacerts ## TLS連線用的身份證書， 【和msp.tlscacerts 一致】
│ │ │ │
│ │ │ └── tlsca.example.com-cert.pem
│ │ │
│ │ └── tls ## tls 的相關資訊
│ │ ├── ca.crt ## 【組織的根證書】
│ │ ├── server.crt ## 驗證本節點簽名的證書， 【被根證書籤名】
│ │ └── server.key ## 本節點的身份私鑰，用來簽名
│ │
│ ├── tlsca ## 存放tls相關的證書和私鑰
│ │ │
│ │ ├── 2d66be83c519da67bb36b0972256a3b24357fa7f5b3a61f11405bc8b1f4d7c53_sk
│ │ │
│ │ └── tlsca.example.com-cert.pem
│ │
│ └── users ## 存放屬於該組織的使用者的實體
│ │
│ └── [email protected] ## 管理員使用者的資訊，其中包括msp證書和tls證書兩類
│ │
│ ├── msp
│ │ │
│ │ ├── admincerts ## 組織根證書作為管理員身份驗證證書，【和MSP.admincerts 一致】
│ │ │ │
│ │ │ └── [email protected]
│ │ │
│ │ ├── cacerts ## 存放組織的根證書，【和CA目錄 裡面一致】
│ │ │ │
│ │ │ └── ca.example.com-cert.pem
│ │ │
│ │ ├── keystore ## 本使用者的身份私鑰，用來簽名
│ │ │ │
│ │ │ └── a3c1d7e1bc464faf2e3a205cb76ea231bd3ee7010655d3cd31dc6cb78726c4d0_sk
│ │ │
│ │ ├── signcerts ## 管理員使用者的身份驗證證書，被組織根證書籤名。要被某個Orderer認可，則必須放到該 Orderer 的msp/admincerts目錄下
│ │ │ │
│ │ │ └── [email protected]
│ │ │
│ │ └── tlscacerts ## TLS連線用的身份證書，即組織TLS證書，【和msp.tlscacerts 一致】
│ │ │
│ │ └── tlsca.example.com-cert.pem
│ │
│ │
│ └── tls ## tls 的相關資訊
│ ├── ca.crt
│ ├── client.crt ## 管理員的身份驗證證書，【被 組織根證書籤名】
│ └── client.key ## 管理員的身份私鑰，用來簽名
│
│
│
│ ## Peer 組織配置
└── peerOrganizations
│
├── org1.example.com ## 第一個組織的所有身份證書
│ │
│ ├── ca ## 存放組織根證書及私鑰 (採用EC演算法) 證書為【自簽名】，組織內的實體將給予該根證書作為證書根
│ │ │
│ │ ├── 496d6a41ae5f66bf120df3eab3a9d2dc4d268b2ab9a22af891d33d323bbdb5c8_sk
│ │ │
│ │ └── ca.org1.example.com-cert.pem
│ │
│ ├── msp ## 存放該組織身份資訊
│ │ │
│ │ ├── admincerts ## 組織管理員 身份驗證證書，【被根證書籤名】
│ │ │ │
│ │ │ └── [email protected]
│ │ │
│ │ ├── cacerts ## 組織的根證書 【和CA目錄 裡面一致】
│ │ │ │
│ │ │ └── ca.org1.example.com-cert.pem
│ │ │
│ │ ├── config.yaml ## 記錄 OrganizationalUnitIdentitifiers 資訊，包括 根證書位置 和 ID資訊 (主要是 crypto-config.yaml 的peer配置中配了 EnableNodeOUs: true ： 如果設定了EnableNodeOUs，就在msp下生成config.yaml檔案)
│ │ │
│ │ └── tlscacerts ## 用於TLS的CA證書， 【自簽名】
│ │ │
│ │ └── tlsca.org1.example.com-cert.pem
│ │
│ │
│ ├── peers ## 存放所有 Peer 的身份資訊
│ │ │
│ │ ├── peer0.org1.example.com ## 第一個Peer的資訊 msp 及 tls
│ │ │ │
│ │ │ ├── msp
│ │ │ │ │
│ │ │ │ ├── admincerts ## 組織管理員的身份驗證證書。Peer將給予這些證書來確認交易簽名是否為管理員簽名 【和MSP.admincerts 一致】
│ │ │ │ │ │
│ │ │ │ │ └── [email protected]
│ │ │ │ │
│ │ │ │ ├── cacerts ## 存放組織根證書，【和CA目錄 裡面一致】
│ │ │ │ │ │
│ │ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ │ │
│ │ │ │ ├── config.yaml
│ │ │ │ │
│ │ │ │ ├── keystore ## 本節點的身份私鑰，用來簽名
│ │ │ │ │ │
│ │ │ │ │ └── 0f0c2e1835086161f6a10c4bb38c2d89b2cee4e1128cee0fcda4433feb6eb6f8_sk
│ │ │ │ │
│ │ │ │ │
│ │ │ │ ├── signcerts ## 驗證本節點簽名的證書，【被根證書籤名】
│ │ │ │ │ │
│ │ │ │ │ └── peer0.org1.example.com-cert.pem
│ │ │ │ │
│ │ │ │ └── tlscacerts ## TLS連線用的身份證書， 【和msp.tlscacerts 一致】
│ │ │ │ │
│ │ │ │ └── tlsca.org1.example.com-cert.pem
│ │ │ │
│ │ │ │
│ │ │ └──tls ## tls 的相關資訊
│ │ │ ├── ca.crt ## 【組織的根證書】
│ │ │ ├── server.crt ## 驗證本節點簽名的證書， 【被根證書籤名】
│ │ │ └── server.key ## 本節點的身份私鑰，用來簽名
│ │ │
│ │ │
│ │ └── peer1.org1.example.com
│ │
│ │
│ │
│ │
│ ├── tlsca ## 存放tls相關的證書和私鑰
│ │ │
│ │ ├── 3d39ea82dd5343c261b0480bc13d645a3cee13b7e7aa8c54fd2b5162f709671f_sk
│ │ └── tlsca.org1.example.com-cert.pem
│ │
│ │
│ │
│ └── users ## 存放屬於該組織的使用者的實體
│ │
│ ├── [email protected] ## 管理員使用者的資訊，其中包括msp證書和tls證書兩類
│ │ │
│ │ ├── msp
│ │ │ │
│ │ │ ├── admincerts ## 組織根證書作為管理員身份驗證證書，【和MSP.admincerts 一致】
│ │ │ │ │
│ │ │ │ └── [email protected]
│ │ │ │
│ │ │ ├── cacerts ## 存放組織的根證書，【和CA目錄 裡面一致】
│ │ │ │ │
│ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ │
│ │ │ ├── keystore ## 本使用者的身份私鑰，用來簽名
│ │ │ │ │
│ │ │ │ └── 2b933c0740d857284be98ff218bf279261e55eff2b89d973e0a1f435f7c7d28b_sk
│ │ │ │
│ │ │ ├── signcerts ## 管理員使用者的身份驗證證書，被組織根證書籤名。要被某個Peer認可，則必須放到該Peer的msp/admincerts目錄下
│ │ │ │ │
│ │ │ │ └── [email protected]
│ │ │ │
│ │ │ └── tlscacerts ## TLS連線用的身份證書，即組織TLS證書，【和msp.tlscacerts 一致】
│ │ │ │
│ │ │ └── tlsca.org1.example.com-cert.pem
│ │ │
│ │ └── tls ## tls 的相關資訊
│ │ ├── ca.crt
│ │ ├── client.crt ## 管理員的身份驗證證書，【被 組織根證書籤名】
│ │ └── client.key ## 管理員的身份私鑰，用來簽名
│ │
│ │
│ └── [email protected]
│ ├── msp
│ │ ├── admincerts ## 組織根證書作為管理員身份驗證證書
│ │ │ └── [email protected]
│ │ ├── cacerts ## 存放組織的根證書，【和CA目錄 裡面一致】
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── keystore ## 【參考admin】
│ │ │ └── 11ebc5afac42348f84a8882f329d18beee079efd4fd5d9b30389dc82053fc0c9_sk
│ │ ├── signcerts ## 【參考admin】
│ │ │ └── [email protected]
│ │ └── tlscacerts ## 【參考admin】
│ │ └── tlsca.org1.example.com-cert.pem
│ └── tls ## 【參考admin】
│ ├── ca.crt
│ ├── client.crt
│ └── client.key
│
└── org2.example.com
我們可以知道 cryptogen 工具無非就是在各個資源下生成 組織 和 私鑰、證書等等，其中最關鍵的就是 各個資源下的MSP 目錄內容：
- admincerts： 管理員的身份證書檔案
- cacerts： 信任的根證書檔案
- keystore： 節點的簽名私鑰檔案
- signcerts： 節點的簽名身份證書檔案
- tlscacerts： TLS連線用的證書
等等 5 種檔案
-
通道及錨節點的配置 configtx.yaml 配置剖析
在上一篇文章中我們知道在啟動網路之前我們需要做一些準備工作，上面我們已經使用 cryptogen 工具生成了 組織的結構及對應的 身份證書等等。現在我們需要使用 configtxgen 這個工具並使用 在 fabric-samples/config 目錄下的 configtx.yaml 這個核心配置檔案用來做三件事：【1】生成啟動 Orderer 需要的創世塊；【2】建立應用通道的 配置交易檔案；【3】生成組織錨節點更新配置交易檔案 ；在 configtx.yaml 配置中主要包括：Profiles、Organizations、Orderer、Application 等等 4 部分；
具體的 configtx.yaml 內容如下所示：
## 一些列組織的定義，【被其他 部分引用】
##
## 【注意】：本檔案中 &KEY 均為 *KEY 所引用； xx：&KEY 均為 <<: *KEY 所引用
##
Organizations:
## 定義Orderer組織 【&OrdererOrg 這類語法類似 Go的中的指標及物件地址， 此處是被Profiles 中的 - *OrdererOrg 所引用，以下均為類似做法】
- &OrdererOrg
Name: OrdererOrg ## Orderer的組織的名稱
ID: OrdererMSP ## Orderer 組織的ID （ID是引用組織的關鍵）
MSPDir: crypto-config/ordererOrganizations/example.com/msp ## Orderer的 MSP 證書目錄路徑
AdminPrincipal: Role.ADMIN ## 【可選項】 組織管理員所需要的身份，可選項: Role.ADMIN 和 Role.MEMBER
## 定義Peer組織 1
- &Org1
Name: Org1MSP ## 組織名稱
ID: Org1MSP ## 組織ID
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp ## Peer的MSP 證書目錄路徑
AnchorPeers: ## 定義組織錨節點 用於跨組織 Gossip 通訊
- Host: peer0.org1.example.com ## 錨節點的主機名
Port: 7051 ## 錨節點的埠號
## 定義Peer組織 2
- &Org2
Name: Org2MSP
ID: Org2MSP
MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
AnchorPeers:
- Host: peer0.org2.example.com
Port: 7051
################################################################################
#
# SECTION: Capabilities 【注意】： 該部分是 V1.1.0 版本提出來的， 不可以在更早的版本中使用
#
# - 本節定義了 fabric 網路的功能. 這是v1.1.0中的一個新概念，不應在v1.0.x的peer和orderers中使用.
# Capabilities 定義了存在於結構二進位制檔案中的功能，以便該二進位制檔案安全地參與結構網路.
# 例如，如果添加了新的MSP型別，則較新的二進位制檔案可能會識別並驗證此型別的簽名，而沒有此支援的舊二進位制檔案將無法驗證這些事務.
# 這可能導致具有不同世界狀態的不同版本的結構二進位制檔案。 相反，為通道定義功能會通知那些沒有此功能的二進位制檔案，
# 它們必須在升級之前停止處理事務. 對於v1.0.x，如果定義了任何功能（包括關閉所有功能的配置），那麼v1.0.x的peer 會主動崩潰.
#
################################################################################
Capabilities:
## 通道功能適用於orderers and the peers，並且必須得到兩者的支援。 將功能的值設定為true.
Global: &ChannelCapabilities
## V1.1 的 Global是一個行為標記，已被確定為執行v1.0.x的所有orderers和peers的行為，但其修改會導致不相容。 使用者應將此標誌設定為true.
V1_1: true
## Orderer功能僅適用於orderers，可以安全地操縱，而無需擔心升級peers。 將功能的值設定為true
Orderer: &OrdererCapabilities
## Orderer 的V1.1是行為的一個標記，已經確定為執行v1.0.x的所有orderers 都需要，但其修改會導致不相容。 使用者應將此標誌設定為true
V1_1: true
## 應用程式功能僅適用於Peer 網路，可以安全地操作，而無需擔心升級或更新orderers。 將功能的值設定為true
Application: &ApplicationCapabilities
## V1.2 for Application是一個行為標記，已被確定為執行v1.0.x的所有peers所需的行為，但其修改會導致不相容。 使用者應將此標誌設定為true
V1_2: true
################################################################################
#
# SECTION: Application
#
# - 應用通道相關配置，主要包括 參與應用網路的可用組織資訊
#
################################################################################
Application: &ApplicationDefaults ## 自定義被引用的地址
Organizations: ## 加入通道的組織資訊
################################################################################
#
# SECTION: Orderer
#
# - Orderer 系統通道相關配置，包括 Orderer 服務配置和參與Orderer 服務的可用組織
#
# Orderer 預設是 solo 的 且不包含任何組織 【主要被 Profiles 部分引用】
################################################################################
Orderer: &OrdererDefaults ## 自定義被引用的地址
OrdererType: solo ## Orderer 型別，包含 solo 和 kafka 叢集
Addresses: ## 服務地址
- orderer.example.com:7050
BatchTimeout: 2s ## 區塊打包的最大超時時間 (到了該時間就打包區塊)
BatchSize: ## 區塊打包的最大包含交易數
MaxMessageCount: 10 ## 一個區塊裡最大的交易數
AbsoluteMaxBytes: 99 MB ## 一個區塊的最大位元組數， 任何時候都不能超過
PreferredMaxBytes: 512 KB ## 一個區塊的建議位元組數，如果一個交易訊息的大小超過了這個值, 就會被放入另外一個更大的區塊中
MaxChannels: 0 ## 【可選項】 表示Orderer 允許的最大通道數， 預設 0 表示沒有最大通道數
Kafka:
Brokers: ## kafka的 brokens 服務地址 允許有多個
- 127.0.0.1:9092
Organizations: ## 參與維護 Orderer 的組織，預設為空
################################################################################
#
# Profile
#
# - 一系列通道配置模板，包括Orderer 系統通道模板 和 應用通道型別模板
#
################################################################################
Profiles:
## Orderer的 系統通道模板 必須包括 Orderer、 Consortiums 兩部分
TwoOrgsOrdererGenesis: ## Orderer 系統的通道及創世塊配置。通道為預設配置，新增一個OrdererOrg 組織， 聯盟為預設的 SampleConsortium 聯盟，添加了兩個組織 【該名稱可以自定義 ？？】
Capabilities:
<<: *ChannelCapabilities
Orderer: ## 指定Orderer系統通道自身的配置資訊
<<: *OrdererDefaults ## 引用 Orderer 部分的配置 &OrdererDefaults
Organizations:
- *OrdererOrg ## 屬於Orderer 的通道組織 該處引用了 【 &OrdererOrg 】位置內容
Capabilities:
<<: *OrdererCapabilities
Consortiums: ## Orderer 所服務的聯盟列表
SampleConsortium: ## 建立更多應用通道時的聯盟 引用 TwoOrgsChannel 所示
Organizations:
- *Org1
- *Org2
## 應用通道模板 必須包括 Application、 Consortium 兩部分
TwoOrgsChannel: ## 應用通道配置。預設配置的應用通道，添加了兩個組織。聯盟為SampleConsortium
Consortium: SampleConsortium ## 通道所關聯的聯盟名稱
Application: ## 指定屬於某應用通道的資訊，主要包括 屬於通道的組織資訊
<<: *ApplicationDefaults
Organizations: ## 初始 加入應用通道的組織
- *Org1
- *Org2
Capabilities:
<<: *ApplicationCapabilities
寫的是真的累了；好了，到這裡我們大致上對Fabric網路的幾個主要配置做了講解，後續我們還會講解Fabric-CA及往正在執行的fabric網路動態新增新的組織及通道的操作哈~
相關推薦
【SSH進階之路】Hibernate基本映射（三）
tor res 主動 tran clas oid 支持包 lose 包括 【SSH進階之路】Hibernate基本原理（一） ，小編介紹了Hibernate的基本原理以及它的核心。採用對象化的思維操作關系型數據庫。 【SSH進階之路】Hibernate搭建開發環境+簡單
【我的區塊鏈之路】- Hyperledger fabric的簡單入門（三）fabric主要配置檔案細講
fabric的各個配置檔案做講解 Peer 配置剖析 本例子是拿fabric-samples 來說的，【如果是 fabric 的話，在 fabric/的根目錄下有一個 core.yaml 】在 fabric-samples/config 目錄下有
【我的區塊鏈之路】- 以太坊原始碼剖析之Geth節點啟動全量過程詳解
最近在整理前端時間學習的原始碼，由於原始碼的學習是片段的，那麼我們在這篇文章中把它關聯起來，這篇文章我們講P2P部分，我們會從Geth的入口一直到後面的節點發現，節點間廣播及同步TX和Block的講解。首先，我這裡先不說fetcher 及downloader的具體工作流程
【我的區塊鏈之路】- golang原始碼分析之select的實現
最近本人再找工作，恩，雖然本人使用go有2年左右了，但是其實還只是停留在語言使用的技巧位面，語言的很多底層實現機制還不是很清楚的，所以面試被問到很多底層，就很懵逼。這篇文章主要是自己對go學習的筆記。（本人還是一隻菜雞，各位海涵） 文章參考： 那麼se
【我的區塊鏈之路】- golang原始碼分析之協程排程器底層實現( G、M、P)
本人的原始碼是基於go 1.9.7 版本的哦！ 緊接著之前寫的 【我的區塊鏈之路】- golang原始碼分析之select的底層實現 和 【我的區塊鏈之路】- golang原始碼分析之channel的底層實現 我們這一次需要對go的排程器做一番剖析。
【我的區塊鏈之路】- 說一說go中的unsafe包
【轉載請標明出處】https://blog.csdn.net/qq_25870633/article/details/83422886 在golang的原生庫中有一個叫做unsafe的包，該包主要是做對記憶體位移的一些操作。 首先我們來看下unsafe包的成員： 三個函式： 可以
【我的區塊鏈之路】- golang原始碼分析之channel的底層實現
【轉載請標明出處】https://blog.csdn.net/qq_25870633/article/details/83388952 接上篇文章 【我的區塊鏈之路】- golang原始碼分析之select的底層實現 我這裡因為面試的時候也有被問到過 channel的底層實現
【我的區塊鏈之路】- golang原始碼分析之select的底層實現
【轉載請標明出處】https://blog.csdn.net/qq_25870633/article/details/83339538 最近本人再找工作，恩，雖然本人使用go有2年左右了，但是其實還只是停留在語言使用的技巧位面，語言的很多底層實現機制還不是很清楚的，所以面試被問到很多底層，就很懵
【我的區塊鏈之路】- SPV 的特點及使用場景
我們很多人都知道在比特幣中有一種節點叫做 spv (簡易支付驗證) 節點；我們這裡來討論下，為什麼需要 spv 節點，什麼場景下會用到它，以及spv 的一些特點。 為什麼會有SPV： 在比特幣整個生態圈裡，大部分都是普通使用者，即只有基本的比特幣投資及消費支付需要
【我的區塊鏈之路】- 談一談拜占庭問題的解及PBFT(拜占庭容錯)
首先，我們來說一說什麼是拜占庭問題。 【問題由來】 拜占庭的n個將軍圍攻敵人，n個將軍包圍著敵人，忠誠的將軍希望通過某種協議達成某個命令的一致（比如約定某個時間一起進攻）。但其中一些背叛的將軍會通過傳送錯誤的訊息阻撓忠誠的將軍達成命令上的一致。如果同時發起進攻的將軍數
【我的區塊鏈之路】- go實現區塊鏈中常見的各類演算法
咳咳，為什麼要出這一篇文章呢？首先，這段時間本人在找工作，然後被問到了各類演算法的底層細節，有些確實很懵逼。這裡做個總結，也順便給大家歸納歸納一下！ 上主題： 橢圓曲線加密： 我們先來說一說最常用的 ECC 吧，ECC 就是 Elliptic Curve Crypt
【我的區塊鏈之路】- 以太坊原始碼剖析之Geth 1.8.14版本挖礦邏輯調整
今天為什麼寫這個文章呢，首先，前段時間有朋友問過我，說現在geth的1.8.14版本的程式碼和網上各路大神們的分析不一樣了。我就趕緊看了下，確實，親的geth程式碼中的mine部分的邏輯有所改動，想必看過原始碼的都知道，之前的miner真正挖礦是由worker把所需挖礦的
【我的區塊鏈之路】- 理解傳統Kademlia和以太坊Kademlia網路
本文章參考自： 大家好，今天我們來說一說以太坊的Kad網路；在此之前我們先來聊一聊少部分P2P方面的知識，P2P 主要存在四種不同的網路模型，也代表著 P2P 技術的四個發展階段：集中式、純分散式、混合式和結構化模型。 集中式：即存在一箇中心節點儲存了其他
【Kaggle-MNIST之路】自定義程式結構（七）
簡述 這一篇跟這個系列的其他文章不一樣，這個是重新安排下程式結構 結構如下： 其中model這個模型專門放模型就好了 model/init.py中不用寫就好了。 model/CNN.py中的內容 模型是基於之前的【Kaggle-MNIS
創建自己的區塊鏈遊戲SLOT——以太坊代幣（三）
rdm con there ppi multipl als div play 數組 一個以太坊合約版本的輪盤遊戲，向合約轉賬ETH，有幾率獲得3,5,10,100倍獎勵 合約地址：0x53DA598E70a1505Ad95cBF17fc5DCA0d2c51174b 捐贈ET
【揚皓原創文章生成器 】原創文章簡單原理（文）
原文：http://bbs.bakii.cn/viewthread.php?tid=1186&extra=page%3D1比如原話：今天天氣不錯，我和朋友去北京玩了一天。* l2 K6 k" B; O* G- V( i4 Y bbs.bakii.cn- Q# I8 p
【Latex】Latex小白入門（2）——如何用.bib檔案自動生成論文Reference
寫在前面： 在研究生階段搞學術的童鞋們很有可能會接觸到Latex這種論文格式編輯工具，一般在論文投稿的時候，大多數期刊和會議會給一個Latex模板，要求將你的論文用Latex編輯成.p
【我的TensorFlow之路·3】迴歸度量與糖尿病預測
1 迴歸度量 繼房價預測後，匯入糖尿病資料集diabetes進行迴歸預測。這次觀察的超引數除了stddev和lr外還觀察了隱藏層神經元個數的影響，並應魏聰明的要求加入了公式化的評價指標，主要使用sklearn.metrics庫裡的迴歸度量函式。sklear
【我的TensorFlow之路·4】關於CNN的一些細節問題
看CNN相關的東西也有一段時間了，但總是感覺深入不進去，這次又讀《面向機器智慧的TensorFlow實踐》這本書，補充了一些知識漏洞，以前不太注意的，或者直接拿來用的一些東西，現在有了更深入的瞭解。 1.步長 設定步長是一種調整輸入張量維度
【SSH進階之路】Hibernate映射——一對一單向關聯映射（五）
技術 iyu 標識 tails for sso 3.0 sdn 例如 【SSH進階之路】Hibernate基本原理（一） ，小編介紹了Hibernate的基本原理以及它的核心，採用對象化的思維操作關系型數據庫。 【SSH進階之路】Hibernate搭建開發環境+簡單實例