Windows下fabric sdk串連Linux上fabric網路的調試過程

標籤：debug模式   src   替換   虛擬   run   led   grant   通過   模式   

        上個月剛入職一家公司從事區塊鏈研發工作，選型採用Hyperledger Fabric作為開發平台。團隊的小組成員全部採用的是在VirtualBox上面安裝案頭版的Ubuntu 16.04虛擬機器，開發工具JetBrains GoLand也就直接在案頭版的虛擬機器裡面安裝。而我因為之前比較習慣使用Vagrant + VirtualBox的方式快速載入我定製版的Ubuntu鏡像從而建立Linux開發環境，這樣一來的弊端就是我只能通過命令列來進行一切操作而沒有案頭可操作，所以我的整個開發IDE就在原生windows上進行。

 

        我們的Fabric網路是採用的Docker方式啟動，作為自己本地的測試環境自然就將網路搭建在Ubuntu虛擬機器裡面，前期由其它小組成員負責針對Go語言版本的SDK（Hyperledger子項目fabric-sdk-go）進行封裝調用並利用Beego作為伺服器將相應的API暴露出來，而我負責的便是將他們暴露出來的API進一步封裝為標準Go版的SDK，所謂的標準就是對調用者而言無感是調用的區塊鏈。這個時候問題就出現了，在我寫SDK的過程中用單元測試對他們的API發起Http請求調用時一臉懵逼，觀察Beego伺服器列印的日誌資訊少的可憐幾乎沒有，以前從來不習慣用斷點調試的我這個時候首先想到的便是希望能夠在他們的API服務中加入適當的斷點以便我這邊的SDK發起請求時能夠一步步跟蹤到底，然而他們的API服務Beego也是部署在Ubuntu虛擬機器中，對於他們自己開發來說反正開發工具IDE也在案頭版的Ubuntu中所以天然在IDE中啟動斷點調試沒有丁點兒問題，那我的IDE在本地windows上，所以我需要在我的IDE中Debug運行他們的API服務，這個時候麻煩來了，API服務因為封裝了對fabric-sdk-go的調用，也就意味著我需要做一些調整以便能夠讓他們的API服務能夠從我的本地windows串連到虛擬機器裡面的Fabric網路，只有這樣才可以完成從我的SDK發起Http請求到他們的API服務，再由API去通過fabric-sdk-go發起對Ubuntu虛擬機器上Fabric網路的操作這樣一個完整的流程。

 

        說下我是如何讓本地windows的API服務串連到Ubuntu虛擬機器裡面的Fabric網路的。其實串連Fabric網路是他們API所封裝的fabric-sdk-go，那麼最關鍵的配置無疑便是config_fabric.yaml設定檔。在那個設定檔中有一系列要訪問Fabric網路所需的crypto，msp，tls等實體路徑，所以自然需要將其中${GOPATH}全部替換為本地windows的GOPATH絕對路徑。本以為這樣就可以完事大吉，可沒想到這個時候無論我怎樣調用，他們的API始終在初始化fabric sdk的時候報錯，無奈只好在初始化的時候打斷點往進跟，跟的具體細節（坑也不少）就不展示了，關鍵區段如。

 

        終於明白原來它從fabric_config.yaml中讀取到systemCertPool屬性的值應該為true，以致於調用了x509.SystemCertPool()方法，最終由於runtime.GOOS == "windows"，自然就拋出"crypto/x509: system root pool is not available on Windows"這樣的異常資訊從而初始化SDK失敗。

 

查看fabric_config.yaml設定檔，果然systemCertPool為true，如：

 

        到這裡本以為就算搞定了，便從我的SDK發起了一個建立Channel的單元測試，結果雖然沒報錯但是Ubuntu虛擬機器上的Fabric網路後台一行日誌都沒列印，很顯然Fabric網路的建立通道命令並沒有被API端的fabric-sdk-go所觸發，可是初始化已經成功了，只能再次在建立通道部分進行斷點跟蹤，發現在建立通道時候需要傳遞的通道設定檔txFile檔案還是之前在Ubuntu虛擬機器下的絕對路徑，在SDK單元測試建立通道功能的時候將傳遞的txFile設為本地windows上的tx檔案絕對路徑，再次運行建立通道單元測試搞定！自此windows跟Ubuntu虛擬機器的Fabric網路正式打通，以後便可以在windows上利用IDE以Debug模式啟動他們的API服務，我的SDK發起調用時便可以輕鬆利用斷點調試來跟蹤底層執行邏輯。

 

        作為一名純軟體工程專業畢業的程式猿，以前總覺得自己的邏輯思維能力夠強，靠想象來感覺代碼的執行流程，靠感覺來判斷問題應該出在哪裡，通過這次的經曆深刻意識到斷點調試的重要性，從今往後遇到bug一定第一時間用debug來執行調試，相信一定會節約不少寶貴的時間從而提高工作效率~

 

Windows下fabric sdk串連Linux上fabric網路的調試過程