中科金財數字貨幣(中科金財區塊鏈平臺容器化最佳實踐)

作者：陳超，北京中科金財科技股份有限公司研發中心技術經理，精通 Java/Go 等開發語言，熟練掌握 Kubernetes、Docker、微服務架構，了解比特幣、以太坊等公鏈技術體系，了解 Fabric 等聯盟鏈技術體系，精通泛金融數字化 解決方案。

KubeSphere 開源社區的伙伴們，大家好。我是北京中科金財科技股份有限公司研發中心技術經理陳超，很高興有機會同大家一起分享中科金財基于 KubeSphere 融合區塊鏈技術二次開發改造的經驗。

業務介紹

公司區塊鏈戰略

自 2019 年 10 月 24 日區塊鏈上升為國家戰略至今已滿兩年。繼 20 年區塊鏈被納入“新基建”后，21 年 3 月份，區塊鏈被寫入《中華人民共和國國民經濟和社會發展第十四個五年規劃和 2035 年遠景目標綱要》，規劃提出培育壯大區塊鏈等新興數字產業。

公司研究政策趨勢并結合多年 B 端科技服務的經驗，將區塊鏈技術及應用建設納入公司的戰略，持續在區塊鏈技術底層、上層業務應用及整體運維管理方面進行建設。

區塊鏈平臺的定位

區塊鏈技術集眾多技術之大成，且在行業中的應用價值方面還處于不斷探索的階段。從底層鏈技術方面來看，國外的聯盟鏈 Fabric、公鏈以太坊等，國內的開源聯盟鏈 fisco bcos、政府背書的星火鏈，長安鏈，樹圖等，同時國內還有一些企業自主開發的區塊鏈技術，如趣鏈公司的區塊鏈、中科金財的中科金鏈、天河國云的天河鏈、復雜美的 chain33，不同的鏈底層技術所涉及的部署、維護、應用接入方式都可能不太一樣，造成了開展行業應用的成本較高，而為了降低用戶在接入和維護區塊鏈設施時的實踐成本和學習成本，且盡可能的適配不同的技術底層，在區塊鏈中間件的標準定義下，需要一套區塊鏈即服務（Blockchain as a Service）平臺。

背景介紹

BaaS 平臺的建設現狀

中科金財于 18 年已開展 BaaS 平臺的建設，采用相對成熟穩定的應用架構進行開發，逐漸加入了基于多租戶的 RBAC 權限體系、資源及區塊鏈網絡監控、區塊鏈動態部署及節點管理等功能，并在一些項目場景中投入使用。

但由于整體架構的缺陷，在部署效率、部署資源動態管理、區塊鏈網絡服務狀態實時監控、賬本高可用、證書托管等方面遇到了較大的技術難度，進一步迭代升級的成本非常大。因此重新進行 BaaS 的總體設計，擁抱 Kubernetes、擁抱云原生變得非常重要。

BaaS 為什么擁抱云原生

云原生是關于速度和敏捷性的，有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用，能夠構建容錯性好、易于管理和便于觀察的松耦合系統。

符合云原生架構的應用程序應該是采用開源技術棧（Kubernetes+Docker）進行容器化部署，利用基礎設施管理能力實現資源彈性伸縮、服務動態部署與資源利用率優化等。

中科金財 SinoBaaS 平臺在對區塊鏈網絡進行動態部署管理、運行檢測、資源彈性擴充等方面的迫切需求與云原生的一些特點非常契合，因此在新的版本改造過程中決定全面集成 Kubernetes。

選型說明

在決定擁抱云原生架構的時候我們選型決定要使用其中非常活躍和成熟的 Kubernetes 作為我們平臺的底層支撐，但是 Kubernetes 整體系統比較復雜學習成本比較高，對非專業用戶使用非常不友好。綜合考慮之后我們決定選擇一個較完善的 Kubernetes 發行版本。我們針對市場上一些比較流行的平臺做了評估，最終選擇了 KubeSphere 作為我們的管理平臺。

選擇 KubeSphere 主要原因有以下幾點：

KubeSphere 代碼開源，這對于我們后期進行二次開發非常有利；

KubeSphere 整體功能比較完善，也集成了非常多的功能插件，通過這些插件不僅能夠快速搭建一套穩定的環境且更有利于我們后期和 BaaS 平臺做融合 ;

KubeSphere 的整體口碑評價很高，社區交流與官方支持都比較活躍 ;

KubeSphere 是國內的青云公司開發的，整體設計比較貼合國人的使用習慣這極大的降低了學習成本。

整體融合

KubeSphere 擁有一套非常完善的配套功能，這讓我們只需要重點關注區塊鏈相關的功能組件開發就可以。中科金財 BaaS 平臺在 KubeSphere 上做了以下融合：

新增聯盟管理組件，其中主要包含了區塊鏈網絡創建；區塊鏈信息概覽；組織、通道、鏈碼管理；交易詳情查詢；數據存證；資產轉賬等功能。

依托 KubeSphere 的用戶角色體系構建區塊鏈網絡盟主等用戶角色體系。

通過 KubeSphere 提供的日志、監控、審計等服務組件對區塊鏈網絡中的節點進行運維監管。

定制化 ks-installer 安裝工具，實現快速標準化的搭建一套穩定的 BaaS 平臺。

實踐過程

平臺的整體架構

中科金財針對 BaaS 平臺所需要具備如靈活部署、資源動態伸縮管理、可視化運維、細顆粒度監控與預警、運行高可靠等方面的核心能力，進行了中科金財區塊鏈即服務平臺 SinoBaaS 的總體設計，設計圖如下：

安全可控：提供基于 RBAC 的級權限管理體系、提供日志審計，全方位保障平臺與服務的安全可靠；

極速上手：通過對區塊鏈應用于生態的構建提供全流程賦能，幫助用戶專注于業務應用層的創新與接入，降低區塊鏈使用門檻；

高可用性：支持平臺、鏈節點的集群化部署，可以按需動態擴容，滿足企業級安全需求；

智能運維：支持為提供聯盟鏈、節點、主機等多維度的實時監控服務，通過 Dashboard 提供豐富的圖表展現形式，實現監控數據的可視化，輕松了解鏈、節點、主機等資源的運行健康狀態；

支持可插拔形式的多種區塊鏈底層（中科金鏈和 Hyperledger Fabric 等）在不同環境中的多種部署模式（云主機、物理機)，靈活滿足業務層技術選項，降低對于環境屬性的依賴，可以持續集成管理市場上其他的鏈技術底層；

高擴展性：支持通過加入自定義插件、第三方云原生插件來擴展平臺的性能，比如加入 CA 服務插件，可集中化進行插件的管理。

平臺所采用的存儲方案

SinoBaaS 在初期的實踐中使用了 PersistentVolume 的 localhost 模式，這種方式使得區塊鏈節點對物理節點的耦合性非常高，且證書也都保存在物理環境中，使得 Kubernetes 的自動調度的特性被嚴重限制了。在組建區塊鏈網絡中還需要通過證書加密，證書保存到本地安全隱患也非常高，一旦磁盤損壞可能會導致證書丟失，失去了證書的節點服務就跟失去了身份的人一樣，后續的補償措施非常困難。

因此在開發過程中，引入了獨立的分布式存儲，并將證書等信息存儲在 Kubernetes 的 ConfigMap 中，整個區塊鏈網絡運行所產生的賬本數據、狀態數據、證書等都得到了高可靠的存儲，解決了 Kubernetes 在漂移調度過程中資源依賴問題。

平臺部署方案

在 BaaS 平臺未融合 KubeSphere 改造前，區塊鏈網絡部署過程相當繁瑣，首先需要我們手動生成區塊鏈網絡所需的證書再分別拷貝到節點機器上，再通過修改腳本參數生成部署組織節點的 yaml 文件，然后才能部署到各個機器中，整個部署過程十分不標準且容易出錯，排查起來問題比較困難，整體部署效率較低。

我們在選擇 KubeSphere 時就考慮到它擁有一套標準的部署流程，而且 ks-installer 工具也是開源的非常適合我們針對部署痛點進行優化。優化過后的 ks-installer 集群可以實現只需要根據不同項目環境修改特定的幾個參數就可以非常流暢的部署一套標準的 BaaS 平臺。

平臺融合區塊鏈方案

部署區塊鏈網絡

我們認為使用 BaaS 進行部署區塊鏈網絡時一般考慮幾點要素：

易用性

隱藏區塊鏈關鍵技術的概念，比如共識算法，P2P 網絡，密碼學，交易管理等。

隱藏技術細節，BaaS 平臺的網絡的搭建，比如落塊的規則，peer 錨節點的設定，狀態數據庫選擇 LevelDB 還是 CouchDB 等。

操作足夠簡單，輸入幾個配置信息就能搭建區塊鏈網絡。

安全與穩定

基于 RBAC 的身份鑒別。

平臺的監控告警。

數據完備，容災切換等高可用機制。

彈性部署，并發業務

能進行水平擴展與收縮，比如能迅速新增節點，關閉 Node 節點時平臺服務不會收到影響。

同時支持多用戶多業務實現鏈上操作。

開放與隱私管理

對各類區塊鏈技術及各類應用場景需要保持開放性，比如存儲智能合約的鏈碼倉庫，以及鏈碼管理。

用戶信息，證書，部署信息，賬本數據，交易信息進行隔離。

創建完的聯盟的架構如下：

整個區塊鏈聯盟使用 Namespace 作為資源的隔離，整體的搭建也分為三層 : 服務層（service），容器層（Pod），和分布式存儲。

區塊鏈網絡管理

區塊鏈的管理，直接面對用戶，提供給運維或者普通用戶來操作，所以既要保證可操作性又要保證關鍵數據的呈現。

當然針對各類應用場景如數據層證，資產轉賬等常用場景我們也提供了內置的鏈碼，如需定制化智能合約可以通過鏈碼倉庫來上傳鏈碼，并進行實例化等操作，能有比較好的開放性。

本地化開發模式

在對 KubeSphere 進行二次開發的過程中，前端的本地化開發比較容易只需要替換 server/config.yaml 中的 server:apiServer:url/wsUrl 地址便可。但后端的本地化開發便涉及到若干問題：如何確保開發環境與測試環境的一致，如何快速開發調試，如果開發涉及到多個云上多個服務之間的相互調用又該如何？這些問題成為了團隊開發的痛點。

這讓我們團隊積極探索本地化開發的方式，其中telepresence和kt-connect都能解決以上痛點，實現的效果類似，都能將集群流量轉發到本地。_ 這里使用 kt-connect 官方原圖說明一下 _。

image.png

多租戶融合

KubeSphere 平臺提供了多租戶管理，角色管理，并以企業空間，項目進行更細顆粒度的權限管理。結合區塊鏈 BaaS 平臺也需要多租戶，創建區塊鏈聯盟，并在聯盟中創建區塊鏈節點和服務。BaaS 在 KubeSphere 的多租戶的基礎上進行融合，提供多租戶的登錄能力，每一個租戶創建自己的區塊鏈服務；通過 BaaS 創建的區塊鏈服務來滿足業務系統的上鏈需求。

區塊鏈創建一個聯盟，包含一個和多個組織同時每個組織擁有一定數量的區塊鏈節點，提供區塊鏈服務。通過 BaaS 平臺創建用戶并關聯相應的組織，當創建聯盟時邀請相關組織加入聯盟。

用戶基本信息如下：包括用戶名，用戶所屬組織，用戶郵箱等信息。

在 BaaS 平臺中的組織管理中可以添加組織并關聯到用戶，再邀請到創建的聯盟中進行通道和智能合約的操作。

實踐過程中遇到的問題

SinoBaaS 平臺從開始改造，到積極擁抱云原生架構，到最終選擇 KubeSphere 作為技術開發平臺，也遇到不少的問題和挑戰 :

不熟悉 K8s：在 K8s 概念、部署、使用方式的各個方面都要學習和探索。

不熟悉云原生的開發和調試流程：不熟悉 KubeSphere 的前后端和安裝腳本 ks-install，從最開始的二進制方式運行 ks-apiserver，本地化調試前端 , 到容器化部署，在開發過程中也缺乏對容器化開發調試的方法，到最后選擇 telepresence 代理方式調試服務。

不熟悉 KubeSphere 的代碼和功能組件 : 通過官方文檔和社區逐漸熟悉 kapi 接口，KubeSphere 的架構和在 CRD 的擴展方面不斷的摸索，最終在自定義 CRD 部分，重新設計區塊鏈部分的 CRD 結構。

區塊鏈功能和 KubeSphere 的融合：在融合方面，由于區塊鏈服務和 KubeSphere 功能還是有不少差異。在聯盟管理，項目角色以及企業空間等方面的融合與展示，以達到不至于特別突兀的效果，團隊內部進行了數次討論。

使用效果

SinoBaaS 平臺經過 KubeSphere 的初步改造升級，完成了區塊鏈聯盟的創建，組織管理，通道管理，鏈碼倉庫，鏈碼管理，區塊和交易查詢，數據存證和資產轉賬等功能。聯盟的創建和刪除更加的便捷，融合 KubeSphere 的企業空間和項目進行了多層級的權限管理，不同角色的用戶可以有不同的區塊鏈視圖，看到不同的區塊鏈的節點和服務信息。簡單效果如下：

區塊鏈瀏覽器頁面：

聯盟概覽頁面：

信息查詢頁面（可以通過區塊號，區塊 hash，交易 ID 等進行查詢操作）：

未來規劃和展望

在 SinoBaaS 1.0 版本開發結束后，我們也在抓緊推進后續版本的規劃和迭代，在此也做一下列舉說明，以供參考交流。

本地協同開發模式

目前可以實現將 ks-apiserver 云上的流量全部攔截在本地，但是在面對多人協同開發時還存在不足，下一步需要實現創建路由規則重定向特定流量，實現多人協作場景下互不影響的本地調試。

自定義服務組件

目前區塊鏈網絡還是以本地化 SDK 的方式接入，在使用便捷性和標準化方面還存在不足，且還無法對訪問進行審計管控，因此還需要在平臺中開發基于 AK/SK 的 API 服務，作為區塊鏈網絡對外接入訪問的入口，并將 API 的服務作為 KubeSphere 的一個服務組件，并配置進 ks-installer 中，隨平臺的一起初始化部署，并在 Service Components 中可以查詢到服務的狀態。

后續甚至可以加入更多的 DApp 應用，都可以納入服務組件中統一管理，并在應用環節深度集成到平臺的各個功能中。

集群聯邦下打造區塊鏈聯邦網絡

SinoBaas 平臺為更好的適應復雜網絡場景下的需求，如多個參與組織都有獨立的局域網，相互間以專線形式通訊，考慮依托 KubeSphere 的多集群托管模式實現跨集群區塊鏈組網和區塊鏈跨網絡通信，真正解決聯盟鏈應用下復雜網絡對區塊鏈運行及管理的影響。

基于應用商店來打造合約商店

KubeSphere 中提供了應用商店的功能，用戶可以上傳、部署應用商店的應用或者自定義應用。區塊鏈中有很多基于智能合約的應用（溯源、存證、加密貓，基于 ERC721 的數字藏品等），將基于智能合約的應用打造成標準的合約模板，借助應用商店的機制來打造合約商店，方便 SinoBaaS 平臺的用戶自主選擇合約應用進行部署。