上個月剛入職一家公司從事區塊鏈研發工作，選型采用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來執行調試，相信一定會節約不少寶貴的時間從而提高工作效率~