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

點對點可靠傳輸：可靠消息與P2P

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

 

智能合約：觸發器與存儲過程

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

數據安全：用業務手段達成妥協

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

為分布式應用而生的微服務，與區塊鏈技術是天生的一對

最后說說區塊鏈技術與微服務架構的關系。大家知道，微服務架構是一個分布式的應用技術架構，目的是有效的對應用進行拆分，實現敏捷開發、快速演化、便捷容錯與彈性伸縮。

微服務的一個核心概念是API網關，由于服務的顆粒變細，網關承擔著安全與訪問認證等諸多職能。而在現有的大多數微服務架構中，大家都更多的在談接入網關的概念，實際上按照信息的流向，除接入網關外，微服務還應該有接出網關的概念。

前面說到，區塊鏈技術本質上就是分布式數據庫，微服務架構與區塊鏈技術的結合，并不能簡單的看成是微服務與數據庫的結合，而應該把區塊鏈平臺做為一個第三方應用進行交互，這也是微服務架構很好發揮作用的地方。上圖中紅圈所示的就是微服務與區塊鏈平臺進行交互的方式。而微服務的接出網關，就應該起到區塊鏈網關的作用。
 

雖然目前的區塊鏈平臺一般都有SDK和REST服務兩種方式，按照上述的原則，一般不要使用 SDK，而是遠程調用方式，采用微服務的設計原則，使用區塊鏈網關，把微服務與區塊鏈平臺集成的功能集中到網關中，見下圖：

微服務通過區塊鏈網關與區塊鏈平臺交互，區塊鏈網關主要功能包括通訊網關、事件監聽，同時配合微服務應用框架，完成數據一致性、對賬功能。與區塊鏈網關集成的能力，是微服務架構天生具備的。所以我們說微服務與區塊鏈，天生是一對。

通訊網關：處理微服務發起的對區塊鏈平臺的調用

由于區塊鏈平臺的服務能力（每秒交易數 TPS）有限，為保證區塊鏈平臺的可用性，區塊鏈網關采用了異步處理模式，實現限流、隔離、服務升降級等能力。

網關在微服務應用與區塊鏈平臺之間建立了隔離，避免平臺與微服務之間互相影響，這是一種 MiddleBox 的集成方式，用一個獨立的基礎設施做集成。微服務之間的集成往往采用 MiddlePipe 的模式，但是區塊鏈平臺做為一個第三方應用，采用 MiddleBox 方式比較好，統一管理與運維比較方便。

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

區塊鏈網關的內部實現是一個 SEDA 架構（分階段事件驅動架構），把接入、接出和處理分開（處理主要是記錄流水、報文打解包、安全效驗等功能），三階段之間用隊列連接，采用異步模擬同步的方式，這是一個用于集成的基礎架構。

接入、處理、接出三個階段可處理資源是可以調配的，資源主要包括處理線程和接入接出的連接，根據不同業務可以有不同的資源為之服務，這樣升降級、限流等特性就比較容易實現。

為了方便運維，需要對業務有分組的能力，可以根據分組進行批量的運維管理。

事件監聽：Hook與輪詢模式

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

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

數據一致性：可靠事件模式是首選

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

一般來說，我們不能依賴區塊鏈平臺支持事務的回滾，因為這個分布式的記賬簿一旦記賬就是不可更改的，我們甚至不能指望區塊鏈平臺實時給應用反饋記賬是否成功，因為有可能返回超時錯誤，不清楚是否記賬成功。于是，區塊鏈網關需要和微服務配合保證數據的一致性。

一般情況下微服務中的業務處理采用異步模式，發出記賬申請后處于等待狀態，區塊鏈網關將記賬申請轉發給區塊鏈平臺。如果區塊鏈平臺返回接受Accept或者拒絕Reject，將結果通知微服務；如果區塊鏈平臺返回超時或者不可確定錯誤，即開始定時輪詢，得到結果后通知微服務。同時，微服務本身需要具備事務補償的模式，如果記賬失敗進行反交易處理。這種數據一致性處理的方式，是微服務多種處理方式中的一種，我們一般使用服務編排的方式降低這種模式的開發復雜度。

下面是一個示例：

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

1）應用框架接到請求后首先記錄業務流水，然后執行業務邏輯，記錄業務數據，最后在事件表中留下對區塊鏈平臺調用的記錄，事務完成
2）事件處理輪詢事件記錄，有更新時通過區塊鏈網關調用區塊鏈平臺，如果調用成功，改變事件狀態，如果失敗就要調用業務補償的機制了

對賬

既然數據有本地存放，也有區塊鏈平臺存放，就有不一致