OS Proof of Stake）方式，是一種通過業(yè)務(wù)規(guī)則達(dá)成共識的方式；實(shí)用拜占庭容錯（PBFT  Practical Byzantine Fault Tolerance）方式，是一種通過技術(shù)規(guī)則達(dá)成共識的機(jī)制。在公有鏈上，工作量證明（POW）還是一種最主要的共識方式，不容易取代，但在聯(lián)盟鏈上，完全可以根據(jù)自己的情況，創(chuàng)造出新的共識方式出來。我們就根據(jù)這一想法，在特定業(yè)務(wù)中創(chuàng)造過共識算法，解決分布式數(shù)據(jù)存儲的一致性問題。

點(diǎn)對點(diǎn)可靠傳輸：可靠消息與P2P

區(qū)塊鏈技術(shù)是一組技術(shù)的組合，既然是一個分布式的記賬簿，就要解決數(shù)據(jù)可靠傳輸問題。包括記賬節(jié)點(diǎn)（信任節(jié)點(diǎn)）之間、非記賬節(jié)點(diǎn)（非信任節(jié)點(diǎn)）、客戶端與記賬節(jié)點(diǎn)（信任節(jié)點(diǎn)）之間的數(shù)據(jù)傳輸。在以前我們的方案中，往往通過可靠消息或者P2P方式解決數(shù)據(jù)傳輸問題，這些技術(shù)也被用于區(qū)塊鏈技術(shù)中。但必須說明的是，在真實(shí)業(yè)務(wù)場景下，不可能把所有的數(shù)據(jù)都記錄在記賬簿中，部分業(yè)務(wù)數(shù)據(jù)還是要保存在自己的系統(tǒng)中，這就還需要在技術(shù)框架上做到本地業(yè)務(wù)數(shù)據(jù)與區(qū)塊鏈的記賬簿保持一致，后文會具體闡述，總之，區(qū)塊鏈平臺只能保證自身數(shù)據(jù)之間的一致，業(yè)務(wù)不能完全依賴區(qū)塊鏈平臺保證數(shù)據(jù)一致性。

 

智能合約：觸發(fā)器與存儲過程

智能合約是指當(dāng)一定條件滿足的情況下，可以被自動執(zhí)行的數(shù)字化合約。實(shí)現(xiàn)這一特性，在數(shù)據(jù)庫中就是由觸發(fā)器和存儲過程完成的。雖然在目前流行的應(yīng)用架構(gòu)中，都不建議把邏輯寫在存儲過程中，但觸發(fā)器和存儲過程還是常用的工具，尤其在數(shù)據(jù)遷移相關(guān)的運(yùn)維活動中。區(qū)塊鏈技術(shù)中智能合約就是觸發(fā)器和存儲過程，他是一個在沙箱中運(yùn)行的腳本，用于執(zhí)行區(qū)塊鏈業(yè)務(wù)中的業(yè)務(wù)邏輯，也可以用于各種檢查。舉個例子，A產(chǎn)生一筆支付時，可以通過智能合約在數(shù)據(jù)鏈上進(jìn)行檢查，如果發(fā)現(xiàn)A的余額無法支付這筆交易，就可以中止這筆交易。和存儲過程相比，智能合約運(yùn)行在沙箱之中，不能對外部 API 做調(diào)用。這也比較好理解，如果允許外部調(diào)用，就可能無法保證自身的數(shù)據(jù)一致性，后面我們會講到這種缺陷如何彌補(bǔ)。美中不足的是目前的智能合約并不支持 SQL 語法。

數(shù)據(jù)安全：用業(yè)務(wù)手段達(dá)成妥協(xié)

交易數(shù)據(jù)是透明的，但不是全部透明，而是相對透明，這是區(qū)塊鏈技術(shù)的一個難點(diǎn)，關(guān)鍵有二：（1）如何保護(hù)隱私，僅僅能看到自己可見的數(shù)據(jù)；（2）密鑰分配問題，例如新加入鏈中的一個節(jié)點(diǎn)會被分配一個新的密鑰，如何用這個密鑰解讀以前鏈中存儲的信息。可見與不可見，這是一個矛盾，理論上沒有一個完美的方案，這里我不對區(qū)塊鏈技術(shù)如何加密、如何做密鑰管理、如何同態(tài)加密等方式做解讀，而是講講如何通過業(yè)務(wù)方法而不是技術(shù)手段規(guī)避這一問題。舉個例子，在一個小企業(yè)支付的聯(lián)盟鏈中，核心企業(yè)包括某銀行、企業(yè)A，為A的上下游企業(yè)提供信貸業(yè)務(wù)，對于所有交易的數(shù)據(jù)，銀行和核心企業(yè)A都是可見的，他們擁有記賬節(jié)點(diǎn)，對于其他加盟企業(yè)，只擁有非記賬節(jié)點(diǎn)，他們雖然也有全部的數(shù)據(jù)，但是只能看到自己相關(guān)的數(shù)據(jù)。很明顯，加盟企業(yè)放棄了自己的部分隱私權(quán)，但也得到了生意的機(jī)會，這種方式加盟企業(yè)是可以接受的，就好比貸款企業(yè)要向銀行提供經(jīng)營數(shù)據(jù)一樣。數(shù)據(jù)安全問題，在技術(shù)上很難解決，但通過業(yè)務(wù)手段是可以規(guī)避的，這也是我們看好聯(lián)盟鏈的重要原因。

為分布式應(yīng)用而生的微服務(wù)，與區(qū)塊鏈技術(shù)是天生的一對

最后說說區(qū)塊鏈技術(shù)與微服務(wù)架構(gòu)的關(guān)系。大家知道，微服務(wù)架構(gòu)是一個分布式的應(yīng)用技術(shù)架構(gòu)，目的是有效的對應(yīng)用進(jìn)行拆分，實(shí)現(xiàn)敏捷開發(fā)、快速演化、便捷容錯與彈性伸縮。

微服務(wù)的一個核心概念是API網(wǎng)關(guān)，由于服務(wù)的顆粒變細(xì)，網(wǎng)關(guān)承擔(dān)著安全與訪問認(rèn)證等諸多職能。而在現(xiàn)有的大多數(shù)微服務(wù)架構(gòu)中，大家都更多的在談接入網(wǎng)關(guān)的概念，實(shí)際上按照信息的流向，除接入網(wǎng)關(guān)外，微服務(wù)還應(yīng)該有接出網(wǎng)關(guān)的概念。

前面說到，區(qū)塊鏈技術(shù)本質(zhì)上就是分布式數(shù)據(jù)庫，微服務(wù)架構(gòu)與區(qū)塊鏈技術(shù)的結(jié)合，并不能簡單的看成是微服務(wù)與數(shù)據(jù)庫的結(jié)合，而應(yīng)該把區(qū)塊鏈平臺做為一個第三方應(yīng)用進(jìn)行交互，這也是微服務(wù)架構(gòu)很好發(fā)揮作用的地方。上圖中紅圈所示的就是微服務(wù)與區(qū)塊鏈平臺進(jìn)行交互的方式。而微服務(wù)的接出網(wǎng)關(guān)，就應(yīng)該起到區(qū)塊鏈網(wǎng)關(guān)的作用。
 

雖然目前的區(qū)塊鏈平臺一般都有SDK和REST服務(wù)兩種方式，按照上述的原則，一般不要使用 SDK，而是遠(yuǎn)程調(diào)用方式，采用微服務(wù)的設(shè)計原則，使用區(qū)塊鏈網(wǎng)關(guān)，把微服務(wù)與區(qū)塊鏈平臺集成的功能集中到網(wǎng)關(guān)中，見下圖：

微服務(wù)通過區(qū)塊鏈網(wǎng)關(guān)與區(qū)塊鏈平臺交互，區(qū)塊鏈網(wǎng)關(guān)主要功能包括通訊網(wǎng)關(guān)、事件監(jiān)聽，同時配合微服務(wù)應(yīng)用框架，完成數(shù)據(jù)一致性、對賬功能。與區(qū)塊鏈網(wǎng)關(guān)集成的能力，是微服務(wù)架構(gòu)天生具備的。所以我們說微服務(wù)與區(qū)塊鏈，天生是一對。

通訊網(wǎng)關(guān)：處理微服務(wù)發(fā)起的對區(qū)塊鏈平臺的調(diào)用

由于區(qū)塊鏈平臺的服務(wù)能力（每秒交易數(shù) TPS）有限，為保證區(qū)塊鏈平臺的可用性，區(qū)塊鏈網(wǎng)關(guān)采用了異步處理模式，實(shí)現(xiàn)限流、隔離、服務(wù)升降級等能力。

網(wǎng)關(guān)在微服務(wù)應(yīng)用與區(qū)塊鏈平臺之間建立了隔離，避免平臺與微服務(wù)之間互相影響，這是一種 MiddleBox 的集成方式，用一個獨(dú)立的基礎(chǔ)設(shè)施做集成。微服務(wù)之間的集成往往采用 MiddlePipe 的模式，但是區(qū)塊鏈平臺做為一個第三方應(yīng)用，采用 MiddleBox 方式比較好，統(tǒng)一管理與運(yùn)維比較方便。

由于區(qū)塊鏈平臺提供的接口各有不同，區(qū)塊鏈網(wǎng)關(guān)在接受請求后記錄交易流水，把區(qū)塊鏈平臺提供的服務(wù)模擬為冪等服務(wù)，調(diào)用者可以多次調(diào)用區(qū)塊鏈網(wǎng)關(guān)，而區(qū)塊鏈網(wǎng)關(guān)僅僅調(diào)用區(qū)塊鏈平臺一次。為方便運(yùn)維，我們可以為區(qū)塊鏈平臺提供的服務(wù)定義SLA，根據(jù)這些定義靈活的進(jìn)行調(diào)用的控制。

區(qū)塊鏈網(wǎng)關(guān)的內(nèi)部實(shí)現(xiàn)是一個 SEDA 架構(gòu)（分階段事件驅(qū)動架構(gòu)），把接入、接出和處理分開（處理主要是記錄流水、報文打解包、安全效驗(yàn)等功能），三階段之間用隊(duì)列連接，采用異步模擬同步的方式，這是一個用于集成的基礎(chǔ)架構(gòu)。

接入、處理、接出三個階段可處理資源是可以調(diào)配的，資源主要包括處理線程和接入接出的連接，根據(jù)不同業(yè)務(wù)可以有不同的資源為之服務(wù)，這樣升降級、限流等特性就比較容易實(shí)現(xiàn)。

為了方便運(yùn)維，需要對業(yè)務(wù)有分組的能力，可以根據(jù)分組進(jìn)行批量的運(yùn)維管理。

事件監(jiān)聽：Hook與輪詢模式

如果記賬簿發(fā)生了改變，如何通知微服務(wù)呢，這就是區(qū)塊鏈網(wǎng)關(guān)中事件監(jiān)聽發(fā)揮的作用。目前很多區(qū)塊鏈平臺并沒有提供事件接口，即使未來有也很難統(tǒng)一，前面也說過，智能合約運(yùn)行在沙箱中，為保證數(shù)據(jù)一致性不可能支持對外部服務(wù)的調(diào)用，也不能做為事件監(jiān)聽的回調(diào)，這樣就需要在區(qū)塊鏈網(wǎng)關(guān)中進(jìn)行處理。

微服務(wù)可以注冊對某一類交易進(jìn)行監(jiān)聽，區(qū)塊鏈網(wǎng)關(guān)定時通過區(qū)塊鏈平臺的查詢接口檢索，發(fā)現(xiàn)數(shù)據(jù)變更時通知微服務(wù)。這是一個效率不高的方法，但區(qū)塊鏈平臺本身性能也不高，時延主要由共識機(jī)制造成，輪詢的做法并不會有太大影響，這也是期待區(qū)塊鏈平臺本身提升的地方。

數(shù)據(jù)一致性：可靠事件模式是首選

不能把所有數(shù)據(jù)都存儲在區(qū)塊鏈平臺中，而是將交易數(shù)據(jù)存儲在區(qū)塊鏈平臺，這樣就有了本地數(shù)據(jù)庫的數(shù)據(jù)與區(qū)塊鏈交易數(shù)據(jù)的一致性問題。

一般來說，我們不能依賴區(qū)塊鏈平臺支持事務(wù)的回滾，因?yàn)檫@個分布式的記賬簿一旦記賬就是不可更改的，我們甚至不能指望區(qū)塊鏈平臺實(shí)時給應(yīng)用反饋記賬是否成功，因?yàn)橛锌赡芊祷爻瑫r錯誤，不清楚是否記賬成功。于是，區(qū)塊鏈網(wǎng)關(guān)需要和微服務(wù)配合保證數(shù)據(jù)的一致性。

一般情況下微服務(wù)中的業(yè)務(wù)處理采用異步模式，發(fā)出記賬申請后處于等待狀態(tài)，區(qū)塊鏈網(wǎng)關(guān)將記賬申請轉(zhuǎn)發(fā)給區(qū)塊鏈平臺。如果區(qū)塊鏈平臺返回接受Accept或者拒絕Reject，將結(jié)果通知微服務(wù)；如果區(qū)塊鏈平臺返回超時或者不可確定錯誤，即開始定時輪詢，得到結(jié)果后通知微服務(wù)。同時，微服務(wù)本身需要具備事務(wù)補(bǔ)償?shù)哪Ｊ剑绻涃~失敗進(jìn)行反交易處理。這種數(shù)據(jù)一致性處理的方式，是微服務(wù)多種處理方式中的一種，我們一般使用服務(wù)編排的方式降低這種模式的開發(fā)復(fù)雜度。

下面是一個示例：

這是一個可靠事件與區(qū)塊鏈交互的流程：

1）應(yīng)用框架接到請求后首先記錄業(yè)務(wù)流水，然后執(zhí)行業(yè)務(wù)邏輯，記錄業(yè)務(wù)數(shù)據(jù)，最后在事件表中留下對區(qū)塊鏈平臺調(diào)用的記錄，事務(wù)完成
2）事件處理輪詢事件記錄，有更新時通過區(qū)塊鏈網(wǎng)關(guān)調(diào)用區(qū)塊鏈平臺，如果調(diào)用成功，改變事件狀態(tài)，如果失敗就要調(diào)用業(yè)務(wù)補(bǔ)償?shù)臋C(jī)制了

對賬

既然數(shù)據(jù)有本地存放，也有區(qū)塊鏈平臺存放，就有不一致