淺談區塊鏈技術與阿里雲的探索實踐

作者 | 余珊

本文根據 QCon 北京 2018 站上的演講整理而成，原題《區塊鏈 Hyperledger Fabric 的落地挑戰與阿里雲探索經驗分享》。

這是今天的主題大綱，我們開始先會回顧一下區塊鏈的概念技術和業務，我們會探討一下區塊鏈在企業場景落地的一些關鍵考慮的問題，下面也會介紹一下我們阿里雲推出區塊鏈的一些相關的工具。最後的話，我們會做一些重點分享，我們在區塊鏈落地，從規劃、運維、到應用這方面去分享我們的一些探索經驗。

首先我們先回顧一下區塊鏈的基本概念，最近一兩年大家無論主動或被動的已經受到了很多區塊鏈技術和業務科普的洗禮。 首先，區塊鏈是什麼？它是一種分散式共享賬本技術，在參與區塊鏈網路的交易各方以及監管方可以共享賬本，這個賬本有這樣一個特性，一旦交易經過各方的確認，交易的數據就不可實現任何的更改。第二，交易歷史是全程可以回溯的，交易信息裡面涉及到些商業機密，交易方的身份等等都得到隱私的保護，交易本身是通過智能合約 Smart Contract 去自動執行的。

區塊鏈的類型有很多，公有鏈、私有鏈、聯盟鏈等等，在阿里雲這邊，我們的工作更多是關注聯盟鏈這種類型。區塊鏈本身不是一個全新的技術，它是基於一些業界已有的關鍵技術去構成的一套體系，包括比如基於拜占庭等共識演算法。還有基於密碼學的一些技術基礎，像非對稱密鑰、數字簽名等等技術。此外，它本質是一個分散式系統架構，所以會涉及到一些分散式計算如高可用，水平擴展，Gossip 通訊協議等等一些技術。

區塊鏈要解決的核心問題，是在缺乏信任基礎的商業環境下，各方如何來進行交易和協作的問題。大家看到有很多講區塊鏈價值，比如說提升了協作效率，降低了時間成本，提升了信息透明度等等，根源都在於我們缺乏信任以及或信任度不足的情況下，在傳統模式引入的各種冗餘的流程、冗餘的模式、中介機構所導致的。同時區塊鏈也會帶來像去中心化 / 多中心化這樣的結果，但是去中心化不是區塊鏈的目的，真正目的是要解決跨企業的信任問題。

其實業界在區塊鏈的實現技術上有很豐富的類型，這列舉了一些影響力比較大的主流技術。其中一個在開源界影響比較大的是 Linux 基金會 Hyperledger 這樣一個傘形項目，下面包含了很多區塊鏈技術實現以及一些工具。其中獲得最廣泛採用的是 Hyperledger Fabric 這個項目，項目初期是由 IBM 和 DAH 一起貢獻的源代碼，現在全球參與的項目成員數量已經是非常多了，其次還有 Sawtooth，Iroha 等等。

其他的實現技術還有以太坊，以太坊早期是從以太幣發展起來的，那麼現在也有一些面向商業場景以及聯盟鏈的分支技術。還有像 R3 Corda，R3 Corda 是面向金融場景開發的一種區塊鏈技術，與之相比， Hyperledger Fabric 更多是面向通用行業、通用業務場景的。此外還有各個廠商自研的區塊鏈技術，例如阿里這邊有螞蟻金服自研的螞蟻區塊鏈技術。

這一頁大概總結一下在 Hyperledger Fabric 的發展過程中它的架構演進的過程，在 Hyperledger Fabric v0.6 採用的是左圖這樣一種架構體系。它跟很多廠商自研的區塊鏈技術是一種類似的架構，它主要由 Peer 節點構成，Peer 上面保存了賬本，賬本在不同 Peer 之間會共享以及同步複製，Peer 上面也會運行共識演算法以及智能合約。後來 Hyperledger Fabric 從 1.0 開始採用了一種新的架構，它的優勢是可以實現架構的水平擴展和解耦，它的共識演算法可以實現可插拔的模式，來解決傳統比如拜占庭共識演算法帶來的節點數要在一開始就固定好，後期無法動態擴展這些問題。

區塊鏈的業務應用場景非常的豐富，相信大家在國內外也看到了很多落地的案例，這裡我也大概列舉了一些。比如說公益慈善、信用證、資產證券化、資產託管等等，我也會介紹一下在一些重點的場景上面，區塊鏈的價值以及面臨的挑戰是什麼。

比如說在商品溯源這個場景，區塊鏈實現的是商品從出廠到中間經過物流、倉儲、經銷商、零售、電商平台，再到消費者，這個過程中它的產品溯源信息的不可篡改的特性。但是在這業務場景落地有一個很關鍵的挑戰，雖然區塊鏈實現了鏈上數據的不可篡改，但也要解決實體商品本身如何跟區塊鏈上的數據做一個可信的關聯。因為我們要避免出現標籤是真的，區塊鏈溯源數據都是真的，但是實體商品是假的。這個環節不是區塊鏈就可以把它全部解決，我們還要結合像防偽技術等等，去形成更完整的溯源方案。

在數字內容版權這個領域，區塊鏈的價值在於可實現對無論視頻、音頻、電影、音樂、電子書等等內容的創作權的存證確認，以及更進一步的，在消費、交易環節給創作者做公平的收益分享。要在這個場景落地也有一些很關鍵的挑戰，就是怎麼保證在內容、交易和消費的環節，將消費數字內容的工具和流程均納入到區塊鏈這種利益分配的體系，這是區塊鏈在這個場景落地的一個很關鍵挑戰。

在供應鏈金融，核心企業在供應鏈中往往處於很強勢的地位，那麼如何把核心企業的信用資質傳導到供應鏈的上游和下游，比如上游的多級供應商，以及下游的多級經銷商，讓他們可以基於核心企業的背書，得到更低成本、更高效的融資，這是供應鏈金融區塊鏈一個核心價值。但裡面的關鍵落地挑戰在於，怎麼能吸引到整個供應鏈上下游那麼多企業都願意參與到區塊鏈這個業務體系來。

基因醫療數據存儲和共享，這個場景有一定共通性，因為它也會適用於像金融大數據，或者是互聯網大數據，這些數據資產的存儲和共享。這裡面區塊鏈價值在於，可以對數據資產的所有權做一個確認，並且在這種數據資產交易的平台或者體系裡面，可以根據所有者的這些不可篡改的確權存證來保證數據交易的利益的在各方實現分配。但裡面也有一些關鍵挑戰，例如怎樣去保證數據交易在數據使用這個環節，數據資產不會發生泄露或者被違規使用，或者被購買方二次倒賣等等，這是數據資產業務落地的一個關鍵挑戰。各個行業區塊鏈落地也都面臨著很多挑戰，上面舉的是一些比較典型的例子。

對於企業來說，現在關心區塊鏈，並且想和業務結合的企業越來越多。我們與阿里雲的客戶、以及我們的合作夥伴進行了很多探討，以及內部我們也正在開發一些落地方案。

對一個企業來說，要應用區塊鏈到底需要考慮哪些維度的問題？大概分為這幾個類別。比如說在業務方面，我們首先要做一件事是要有「人」的保證，這個人才的團隊包含很多方面，需要區塊鏈的技術人才，需要部署區塊鏈底層，或者業務底層的雲平台的技術人才，需要有業務應用開發的團隊去支持，需要有業務方面的一些專家，所以這是人才團隊的維度。

另外業務場景選擇，有很多企業場景，如果能用傳統的中心化方案或者系統去解決的話，那麼就要反思是否有必要去用區塊鏈。如果說有一些場景是涉及到跨企業協作，並且確實缺乏信任基礎的，這個就可以考慮應用區塊鏈。

下面是業務流程優化，區塊鏈在業務應用裡面是有一個特點，尤其在聯盟鏈，它涉及到跨企業的業務流程，所以不像傳統的流程只限於企業內部，只是幾個部門之間的協作，跨企業的業務流程需要在保證各方平等、自治的基礎上，建立起業務流程以及進一步優化，這些都是必須考慮的問題。

應用開發模式，解決的是如何在你的業務人員或開發人員與區塊鏈底層技術之間構建起一個橋樑，把區塊鏈底層的這些 API 調用、SDK 調用變成你的業務模型、業務流程，讓業務人員能夠理解和使用。接下來是可視化分析，區塊鏈本身運行是類似於一個黑盒子，如果我們在企業落地，我們關心是它對業務貢獻的商業價值，怎樣把這種一個黑盒的系統變成對商業的決策者來說是可視化、可量化，並且可用於做 BI 分析的設計。數據建模和管理指的是，區塊鏈裡面賬本存儲的是 key value，是區塊鏈對應的業務場景的數據建模存儲的內容。那麼區塊鏈業務數據怎麼和企業的主數據之間去建立起關聯，以及做後期的數據模型的管理？這些也是企業需要考慮的。

下面的話，像技術方案選型，就涉及到區塊鏈技術本身的不同流派、不同區塊鏈類型等等的選擇，以及相應的開發編程語言、開發框架的選擇，還有底層部署雲平台技術的選擇。平台設計實施，這包含了整個平台方案以及業務部署方案的設計實施。高可用和災備，這裡面涉及到跨企業區塊鏈業務協作體系，怎麼既要保證本企業業務服務的可持續性，也要保證在跨企業協作中，不會因為一個企業的節點，導致了整個聯盟鏈的業務的癱瘓，所以這都是要考慮的很關鍵的問題。

像安全合規治理，這是大家應用區塊鏈最關心的一個點，因為我都把我的業務數據放在一個跨企業的聯盟鏈上面，我是非常重視裡面的數據安全，商業隱私的保護，尤其大家如果還涉及到，比如說進軍海外市場，涉及到和美國政府或歐盟打交道，這些很嚴格的數據保護的要求，隱私保護的政策等等，這方面也是我們應用區塊鏈必須要考慮的。

另外平台應用運維，這裡面就涉及到因為區塊鏈的不可篡改特性，導致上面的配置、數據、應用的管理相比傳統有很大的不同和挑戰。下面是運營，市場營銷宣傳，我看業界很多公司做得很好，這塊我就不用多說了。生態系統參與包含了企業去應用區塊鏈，同時要考慮，是否要跟外部的，比如說區塊鏈相關的官方組織，以及開源社區的技術參與，以及業務生態系統的參與，比如說，基於某個業務形成的這些行業聯盟，以及行業協會等等的參與。

所以這裡面涉及到的問題是覆蓋了很多維度，今天可能不能對所有問題都有一個標準的答案。但我們會對其中一些地方，分享我們的一些探索經驗。

面的話，是介紹我們在探索過程中用到的工具，就是去年 10 月份，我們在杭州雲棲大會發布的基於阿里雲容器服務的區塊鏈解決方案。這其實是我們在區塊鏈領域探索的第一小步，目前我們也在緊張地開發一些更新的產品形態和更多的落地方案。

這裡面它核心解決是什麼問題？對很多企業來說應用區塊鏈，關注的是怎麼快速地去把業務和區塊鏈結合，實現業務應用上線，我想聚焦的是業務創新本身，沒有足夠的比如人員團隊或者是時間去進行區塊鏈整個底層的建設，所以這是企業一方面的訴求。

另一方面的訴求是由區塊鏈的技術特性決定的，因為它的不可篡改的特性會導致了在開發業務應用的時候，區塊鏈系統裡面的數據，區塊鏈的整個網路的配置，不是說管理員去改幾個參數，或者是去做 roll back、delete 等等就可以恢復成一套全新的環境。你需要把整個環境鏟掉，然後重新把它再搭建起來才能進下一輪的開發測試等等。這就導致了在業務應用的開發過程迭代的效率問題。這類的話，我們的區塊鏈解決方案可以提供基於界面化的一鍵自動化配置部署，讓企業可以在幾分鐘內就可以得到一套企業級的區塊鏈開發測試環境，這是我們當時解決用戶痛點的一個出發點。

這個是解決方案的大體架構，這裡我也不做太多介紹了。大家可以看一下，這裡面體現了如何在 Kubernetes 集群技術上去搭建一套 Hyperledger Fabric 區塊鏈服務的最基本的要素的展現，企業在進行區塊鏈技術選型時候也可以參考這些緯度，去選擇區塊鏈平台。

下面我們就重點講講我們在這三個領域上面的探索經驗。

第一個是基於 Hyperledger Fabric 的業務和數據存儲容量的估算方法。下面這個圖展示的是 Hyperledger Fabric 的完整交易流程以及部署架構，給大家介紹一下基於 Hyperledger Fabric 的區塊鏈交易是怎麼進行的。首先業務應用會通過 CA 服務去進行身份的註冊以及登錄之後，就可以去連接不同組織的背書 Peer 節點，把交易請求發送給背書的 Peer 節點，進行區塊鏈交易模擬運行，模擬運行是通過裡面的 Chaincode 容器去進行的，再把模擬交易結果返回給 Client，再發給上面的 Orderer 服務，去把這些模擬運行的交易結果變成一個個區塊，這就是區塊鏈裡面出塊的那個環節。Orderer 服務內部是把 transaction 交易信息放到後台 Kafka 隊列，再從隊列取出後組成一個個區塊的。組成區塊之後，Orderer 會把區塊廣播發送給整個業務網路里的 Peer 節點，每個 Peer 節點收到這些塊之後，就會對裡面的 transaction 做一個 validation，再把裡面合法的交易 commit 到區塊鏈的這些賬本裡面，這就是區塊鏈 Hyperledger Fabric 一個交易的整體流程。

但對一個企業來說，我如果要搭建一個基於區塊鏈的業務系統，我光了解這個流程是不夠的，尤其是企業的架構師、或者預算和採購的團隊，以及甚至 CTO 他會問這個問題：你這套系統到底能支撐我多大的業務量？尤其區塊鏈裡面最重要的是交易數據，那麼為了對交易數據做持久化，我要規劃多大的存儲資源才能滿足我企業業務未來一年、兩年、三年的運行的需要，這是我們遇到的很多客戶在落地前問的第一個問題。

這個問題不好回答，因為由於區塊鏈比如 Hyperledger Fabric 本身的交易流程以及底層技術架構複雜性，業界也沒有很好的估算的方法。我們進行了對 Fabric 架構和代碼的分析，以及通過一些容量的測試，得出了一些估算方法，下面跟大家分享一下。

首先我們對整個 Fabric 技術架構的存儲增長的熱點做了一個定性的分析，可以看到在 Orderer 這個節點，每個 Orderer 它會保存賬本的一個 block file，就是交易歷史文件，它跟我們的交易量是線性相關的，增長的壓力是比較大的。

其次是 Kafka 集群的隊列，剛才講的在 Orderer 收到交易數據以後是放在 Kafka Broker 的隊列裡面，這裡面也會有數據容量的增長，這塊是黃色，代表它增長壓力是中等的，後面會解釋一下。其次在整個網路裡面每個 Peer 又有兩部分，在 Peer 的 Ledger 裡面也有 block file，這塊也是隨著交易量會有一個線性增長。其次 StateDB 是存儲賬本的世界狀態，這一部分也會跟交易相關，但是它不是一個直接線性相關的關係。

有了這個定性的分析結果之後，我們再進一步看看如何定量的去得出估算的結果。這裡是經過剛才講的一系列架構代碼分析，以及容量測試，得到的一個估算公式。可能它還不是非常完美的，但是在實際應用中已經能提供非常有用的信息。我大概解釋一下，區塊鏈有個多鏈的概念，就是 Fabric 有個多鏈的概念，通過 Channel 去實現，每個 Channel 代表了一種業務，這種業務有獨立的賬本，跟其他的 Channel 是隔離的關係。我們可以讓用戶提供一個輸入，比如說它可以估算每種業務每天平均交易筆數作為基礎，因為這裡我們進行的是容量估計，而不是做 Performance 峰值估計，這是第一個輸入參數。

其次 Fabric 每一筆交易的基本開銷是 Fabric transaction 這種數據結構，這個數據結構我們分析過代碼，大概是 2.9KB 的大小，但是還有其他附加的，比如說 Index 的一些開銷以及 Block 的一些開銷，我們大概取一個估算值，大概 4K 左右的一個結果。那麼再加上每一筆交易平均業務數據大小，那就是你的真正交易 Payload 數據，你想把什麼數據寫在鏈上，這個 Payload 的大小。這裡要乘個 2，乘 2 是個很關鍵的點，在剛才講的背書交易的過程，它這個交易 transaction 數據是包含兩部分，一個叫了 chaincode proposal payload，以及 proposal response payload，它是把我的業務數據這一部分進行了兩次的表述，在我的 transaction 數據結構裡面，這就是為什麼有乘 2 的原因。

其次就是業務 Channel 數量，我搭起來一套 Fabric 區塊鏈網路，不希望只服務於一種業務，希望可以支持多種業務，那麼要乘上相應的業務 Channel 數量。要支持業務年的時間，還有 Peer 節點數量，Peer 節點是因為每個 Peer 上面會存儲區塊鏈的 block file 來記錄賬本，乘 2，2 到 1 之間是個很有意思的，它涉及到每個 Peer 既有 block file，也有 StateDB，比如企業級我們現在用 CoachDB，但這個數據特徵是跟你的業務類型緊密相關的，如果說你每個交易都是創建一個新的 key value，跟你多筆交易 update 同一個 key value，對 StateDB 的開銷是不一樣的。

另一方面，因為像 CoachDB 它應用了 Google 的 Snappy 壓縮技術，真正的交易的 Payload 進到 StateDB 裡面存成 key value，它不是原生的數據大小，而是它會經過一段時間壓縮之後，數據量會大大的減小，當然壓縮比例會跟業務數據的本身這些數據的一些特徵會有關係，這就是一個比較彈性的，因為涉及到我剛才講的 StateDB 的特性。此外 Orderer 的節點數量，這裡面就涉及到，因為 Orderer 它保存了一套完整的數據賬本，那麼它跟 Peer 的賬本是一致的，這塊還有相應的開銷。

然後就是 Kafka，Kafka 的隊列是有一個功能是做 retention period 的保證，經過 retention period 之後，它可以把隊列里的消息，就假定是客戶不需要的可以把它清除掉，在 Fabric 裡面 kafka Retention 天數大概是 7 天，當然用戶可以自定義了，7 天的量，再乘以 replica，replica 是 kafka 用來做數據的高可用的，同一套數據在 kafka 會有多套副本。在 Fabric 裡面，kafka replica 數量是 3，這是只需要保存 7×3 的這樣一個量。這就是整個估算的方法，下面我給出對應的 Excel 公式，大家也可以針對你的情況自己得出一套自動計算的估算公式。

面再講講，在運用估算方法以及注意的點，也反映了區塊鏈這個業務應用系統一些設計原則。第一個，每條業務 channel 它是有總的大小限制，這個來自於哪裡呢？因為剛才講到每個 channel 它有一套賬本，賬本核心是 Block，記錄所有的交易數據、交易歷史記錄，這個 Block 是以一個個 append-only 類型的文件來存儲，這些文件大概是有 10 的 6 次方這樣的數量上限，每個大小是 64 兆，乘下來，技術上大小上限是 61TB。剛才看到估算的這些值，但是它的上限，比如說每個 Order 或者每個 Peer，它上面的業務數據量是不能超過 block file 的上限的。

第二個就是我們要注意到底什麼東西是適合放在區塊鏈的，這不僅僅是容量規劃的問題，而是整個業務場景選擇的問題，因為首先區塊鏈的特徵是適合保存證據，它不是用來作為原始的數據存儲，或大數據存儲的基礎設施。另外的話，如果你的業務場景，頻繁地去更新同一個 Key，比如銀行裡面轉賬、支付交易，那麼我們就要思考這種是否適合區塊鏈一個特質，因為區塊鏈在業界也有一個不成文的共識，它本身不涉及用於支撐高頻交易業務的。另外還有 Block 開銷，因為剛才講了 transaction 是封裝在 Block 裡面的，這個 Block 本身從數據結構上大概有 1.9KB 的基本開銷，Block 數量跟 transaction 數量比例是不定的，因為有下面幾個原因，看到數字貨幣像比特幣，它的出塊是根據礦工挖礦，也就做一系列的窮舉計算以及做哈希計算得到一個滿足難度條件的隨機數等等，這是數字貨幣出塊。

但是在 Fabric 裡面出塊，它只需要滿足這樣三條標準，比如 Block 裡面包含的 transaction 筆數達到上限，它就可以去出一個塊。或者是 Block 裡面包含的 transaction 總的 byte 位元組數達到了上限，或者是從第一條 transaction 進入 Block 之後，等待時間到達上限都可以產生一個塊。因為這三條標準導致了 transaction 數量與 Block 數量是沒有嚴格的對應的關係，順便說一句，這三個標準跟 IBM MQ 做網路批量的高效傳輸三條標準是基本一致的，業界有很多設計是很巧合的。

其他還有一些比較次要的考慮因素，比如說 Fabric 容器鏡像開銷，Fabric 涉及到容器鏡像從三五百兆再到 1.5G，1.3G 都有，假如說所有的鏡像單獨存成文件，大概是 11G 的開銷，當然如果我們把鏡像存儲在 Docker Registry 裡面比如說 Harbor，或者是雲上的鏡像服務，它占的實際體積會小很多，因為基於 docker image 分層文件系統的技術。但是如果對企業來說可能要考慮，我要備份多少套的鏡像版本來支撐業務的升級、回滾，或者是開發的需要，這是存儲開銷。此外還有業務應用跟其他軟體的容器鏡像、以及數據的存儲備份等等這些開銷，但這些都是相對次要的一些因素。

我們分享完第一個探索經驗，下面將從運維角度，怎麼對 Hyperledger Fabric 日誌來實現企業級的運維分析。可能在座的很多同仁會有過使用 Fabric 日誌的一些經驗，比如說我們可以通過像 Kubernetes 控制台，去查看某一個 Peer 節點、Orderer 節點的日誌信息，或者通過命令行運行 kubectl logs 或 docker logs 命令，也可以看到每個節點的容器的日誌信息。但問題是這些手段滿足不了企業級運維和業務分析的需求，這裡所面向的對象很可能是區塊鏈運維繫統的團隊，甚至某些場合下會涉及到業務相關的團隊。

那麼到底企業級的運維與業務分析需要怎樣的 Fabric 日誌的工具或者能力呢？其實這種區塊鏈的業務系統可以結合，比如說雲平台的日誌服務，或者像開源的 ELK 方案去搭建出日誌分析系統，去跟區塊鏈整合起來。下面舉幾個例子說明我們需要哪些能力。第一個就是我們希望對區塊鏈業務系統的日誌實現實時索引以及動態查詢的能力。比如說這個例子裡面，我們是用阿里雲的區塊鏈解決方案整合了阿里雲日誌服務來進行示例，這裡我們需要對某一個業務 Channel 來進行實時的索引查詢，來看這個日誌的一些分布，以及跟這個業務 Channel 相關的日誌信息，可以通過關鍵字，以及像一些類 SQL 的查詢語句來快速實現查詢。

第二個例子，對企業來說，可能要對一些比較敏感的，或者是高優先順序，或者是對風險有關的一些日誌信息，實現自動告警的功能，並且這些告警可以去對接，比如簡訊，郵件，企業及時通信工具如釘釘等等一些工具。在下面這個示例中，我們就可以去對某一個區塊鏈應用系統來設定一些告警規則，檢查在某一個 Peer 節點上是否有運行某個特定，如某個高敏感性 chaincode 應用，設置這樣一條規則，在配置好規則以後，後面當我業務系統一旦滿足這個條件，那麼就會自動通過郵件，以及簡訊，向用戶自動發送告警，並且運維人員在告警記錄裡面可以看到告警的這個過程。

再下一個實踐就是，我們企業是希望能夠獲得一種關於區塊鏈業務系統運行情況的可視化的統計圖表，以及報表數據輸出。這裡我們做了一個圖表分析，就是在這幾個 Peer 節點上，我們其實是做了幾個事情：在一個 Peer 上面調用了 10 次智能合約，在另一個 Peer 上面調用了 100 次智能合約。在我們實際的日誌的圖表分析裡面，就可以看出業務調用情況的體現，因為這裡基準的這些日誌數量是進行賬本數據同步的一些日誌，那麼額外的這一部分的 Delta 日誌數量是對應這 10 次 chaincode 調用的，另外這部分更大的 Delta 日誌數量就是在這 Peer 上進行 100 次 chaincode 調用的情況。 這些日誌分析圖表可以作為業務團隊去分析，比如說在不同業務區域，進入區塊鏈業務系統流量的差別，或者說跟不同企業對接的區塊鏈業務系統，它的流量差異等等，都可以作為一個業務分析的依據，以及說後續可以導出成 Excel 的形式。

以上就是我今天對前面的兩個探索經驗的分享，謝謝大家！

作者介紹

余珊，阿里花名御功，目前在阿里雲容器服務部門擔任高級技術專家，負責容器技術、區塊鏈產品和解決方案的研發工作。本科和碩士畢業於中國科技大學。在 IBM 中國開發中心的十年工作期間帶領了 IBM MQ、Kubernetes、微服務、Hyperledger Fabric 等相關產品和技術的研發工作，並且積累了豐富的銀行、金融、政府、零售、製造、醫療、能源等行業的企業客戶項目經驗。

想近距離同餘珊交流？

8 月 18-21 日，來北京國際會議中心參加 BCCon！

以 BATJ 為首的各互聯網企業，雖對區塊鏈的布局各有側重，卻殊途同歸，共同推動著區塊鏈技術的發展和落地。布局區塊鏈的重要關頭，你的 idea 可行嗎？這裡有 30+ 路線供參考。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！