Hyperledger Fabric週週記:Composer

NO IMAGE

上週週記的結尾,我曾經說過本週要介紹Fabric的開發和應用。按照最開始的寫作計劃,我打算講講兩種開發模式:直接使用Fabric API和利用Composer框架。可在通讀完Composer的文件之後,我立即取消了原定計劃,直接介紹Composer。

選擇工具A而不是B一般情況下理由都很直接:簡單易上手。以我個人為例,在翻完Fabric的文件之後,雖然對於Fabric的架構和元件瞭然於胸,但對於如何開發,其實還是很模糊的。

為什麼會這樣?

有兩個原因:

文件本身給出的開發範例(fabric-samples)缺乏一個系統性的介紹。所謂系統性,說白了就是教科書性質的介紹,由一個簡單的例子開始,層層遞進,最終讓讀者全盤掌握。就當前的文件來說,這一任務顯然沒有達到。
缺乏聚焦,正如這篇Composer幻燈片(第四頁)介紹的,有太多東西要操心了,對於真正需要關心的東西(業務邏輯)反而沒有突出。

Composer恰好非常好的彌補了Fabric文件中這兩個缺陷,從其文件構成可以很明顯的看出來:

給出Composer的整體性介紹
手把手教會大家如何完成安裝
給出一個Hello World級別的例子
如何進行單元測試
如何部署到真實的Fabric環境

這種方式是我最喜歡的,對於開發者來講,他能很快建立起整體印象,並且樹立起信心。

當然,文件好並不足以吸引開發者成為粉絲。讓其成為開發首選的理由只有一個:對開發者友好。

Composer的開發者友好性表現在以下幾個方面。

1. 良好的抽象

Chaincode是Fabric開發的核心,但看過了例子之後,說真的,很容易讓開發者打退堂鼓。因為太底層了!讓人有一種回到用Servlet開發Java Web應用的感覺。

Composer在這一點上做得很好,它的Runtime內建了通用的Chaincode。使用它開發根本不會感到Chaincode的存在。而且整個過程幾乎跟你開發一個普通的CRUD Web應用無異!在開發者看來,他就是在寫普通的JavaScript函式。

這篇文章給出了兩種方式(Chaincode和Composer)的開發範例,在結尾處提到兩者的程式碼行差異:

This ±10x reduction in the number of lines of code when Go and Composer solutions are compared is fairly consistent across several samples.

2. 統一的工程化體驗

實際的開發不是書上的簡單例子,而且涉及多人,如果沒有良好的開發規範,很難產生好的結果。從Fabric文件中,你無法看出一個區塊鏈應用的專案工程應該是什麼樣子,只能看到一個個零散的程式碼檔案。顯然無法滿足工程上的要求。

就一個Fabric區塊鏈專案來講,它包含:

儲存於賬本上的Asset
操作Asset的Chaincode
訪問Chaincode的Client App
應用相關的許可權和成員

Composer非常完美地給出瞭解決方案,將整個開發過程分成3部分,每一部分都有對應的命令列工具,提供統一的開發體驗:

Business Network,業務邏輯,其中包括以下元件:

asset model,儲存於賬本上的Asset,其過程跟設計資料庫的表沒什麼兩樣。
transaction function,對應Chaincode中的各個方法,但對於開發者來講完全透明。
acl檔案,許可權定義。
query,命名查詢,供transaction function呼叫。

Rest Server

將釋出到Fabric的Business Network暴露成Restful API,供外部呼叫,完全語言中立。

Client App

嚴格來講,這一步並非必要,因為既然上面已經有了語言中立的API,理論上可以用任何框架來開發相應的Client APP。但Composer提供了一個基於Angular的模板幫助加速這一過程。

怎麼樣,這個過程是不是非常眼熟?通過開發框架固化的開發過程可以讓開發人員更快的上手,並且統一在相同的“big picture”之下。並且,上述的各個元件對於有經驗的開發者並不陌生,有助於快速理解。

大家可以在文件中的這個例子中看到完整的過程。

3. 內建測試的支援

即便是水平再爛的開發,他也希望能驗證一下自己寫的東西才好意思交出去。然而,對於Fabric應用來講,這可不是件容易的事情,因為部署太繁瑣了。

Composer再次拯救了開發!

Composer內建的runtime為測試提供了良好的支援,由於良好的抽象,這個runtime既可以是實際的Fabric,也可以是一個內建的Node.js程序。而後者則是為測試而生的。更好的是,這一切完全對開發者透明,開發的上層程式碼完全不需要改動。

對於上進心更強,想要實現自動化測試的同學,這裡有一個例子可以參考。

4. 便捷的CLI工具

相比起Fabric零散的命令集合,Composer提供了便捷的CLI,統一了開發、管理和運營任務。開發者可以利用它方便的實現:

應用打包和部署
應用腳手架生成
環境管理

讓開發更加聚焦於手頭的任務,而不是為了準備工作而分散太多精力。

前面說了Composer的那麼多好處,接下來說說Composer的侷限性。就目前的文件來看,我沒有看到如何用它來開發System Chaincode的例子。而且,我懷疑當前的版本並不支援。因此,假如你像要開發的System Chaincode,Composer可能並不能滿足你的需要。而這一任務應該算不上一個大眾型任務。

或許你會奇怪,為什麼我沒有展示一個實際的例子來證明我說的這些好處。這隻能怪Composer的文件寫得太好了,基本是傻瓜式教程,按照它的步驟,基本不會出現什麼問題。既然是這樣,幹嘛還要花時間在這個上面呢?

說到底,本文的目的只有一個:用Composer來開發未來的Fabric應用,不要再自虐了!同時,最新一期的Thoughtworks雷達也將其列為“TRIAL”並給出了下面的評語:

… However, the programming abstraction of chaincode is relatively low level given it manipulates the state of the ledger directly. Moreover, it always takes a lot of time to set up infrastructure before writing the first line of blockchain code. Hyperledger Composer, which builds on top of Fabric, accelerates the process of turning ideas into software. Composer provides DSLs to model business assets, define access control and build a business network. By using Composer you could quickly validate your idea through a browser without setting up any infrastructure.

最後,請大家記住:即使Composer降低了開發的門檻,但還是要記得認真學習Fabric文件喲!