中科金财区块链平台容器化最佳实践
作者：陳超，北京中科金財科技股份有限公司研發(fā)中心技術(shù)經(jīng)理，精通Java/Go等開發(fā)語言，熟練掌握 Kubernetes、 Docker、微服務(wù)架構(gòu)，了解比特幣、以太坊等公鏈技術(shù)體系，了解 Fabric 等聯(lián)盟鏈技術(shù)體系，精通泛金融數(shù)字化 解決方案。
KubeSphere 開源社區(qū)的伙伴們，大家好。我是北京中科金財科技股份有限公司區(qū)塊鏈中心的平臺即服務(wù)產(chǎn)品研發(fā)負(fù)責(zé)人陳超，很高興有機(jī)會同大家一起分享中科金財基于 KubeSphere 融合區(qū)塊鏈技術(shù)二次開發(fā)改造的經(jīng)驗(yàn)。
業(yè)務(wù)介紹
公司區(qū)塊鏈戰(zhàn)略
自 2019 年 10 月 24 日區(qū)塊鏈上升為國家戰(zhàn)略至今已滿兩年。繼 20 年區(qū)塊鏈被納入“新基建”后，21 年 3 月份，區(qū)塊鏈被寫入《中華人民共和國國民經(jīng)濟(jì)和社會發(fā)展第十四個五年規(guī)劃和 2035 年遠(yuǎn)景目標(biāo)綱要》，規(guī)劃提出培育壯大區(qū)塊鏈等新興數(shù)字產(chǎn)業(yè)。
公司研究政策趨勢并結(jié)合多年 B 端科技服務(wù)的經(jīng)驗(yàn)，將區(qū)塊鏈技術(shù)及應(yīng)用建設(shè)納入公司的戰(zhàn)略，持續(xù)在區(qū)塊鏈技術(shù)底層、上層業(yè)務(wù)應(yīng)用及整體運(yùn)維管理方面進(jìn)行建設(shè)。
區(qū)塊鏈平臺的定位
區(qū)塊鏈技術(shù)集眾多技術(shù)之大成，且在行業(yè)中的應(yīng)用價值方面還處于不斷探索的階段。從底層鏈技術(shù)方面來看，國外的聯(lián)盟鏈 Fabric、公鏈以太坊等，國內(nèi)的開源聯(lián)盟鏈 fisco bcos、政府背書的星火鏈，長安鏈，樹圖等，同時國內(nèi)還有一些企業(yè)自主開發(fā)的區(qū)塊鏈技術(shù)，如趣鏈公司的區(qū)塊鏈、中科金財?shù)闹锌平疰湣⑻旌訃频奶旌渔湣?fù)雜美的 chain33，不同的鏈底層技術(shù)所涉及的部署、維護(hù)、應(yīng)用接入方式都可能不太一樣，造成了開展行業(yè)應(yīng)用的成本較高，而為了降低用戶在接入和維護(hù)區(qū)塊鏈設(shè)施時的實(shí)踐成本和學(xué)習(xí)成本，且盡可能的適配不同的技術(shù)底層，在區(qū)塊鏈中間件的標(biāo)準(zhǔn)定義下，需要一套區(qū)塊鏈即服務(wù)（Blockchain as a Service）平臺。
背景介紹
BaaS 平臺的建設(shè)現(xiàn)狀
中科金財于 18 年已開展 BaaS 平臺的建設(shè)，采用相對成熟穩(wěn)定的應(yīng)用架構(gòu)進(jìn)行開發(fā)，逐漸加入了基于多租戶的 RBAC 權(quán)限體系、資源及區(qū)塊鏈網(wǎng)絡(luò)監(jiān)控、區(qū)塊鏈動態(tài)部署及節(jié)點(diǎn)管理等功能，并在一些項(xiàng)目場景中投入使用。
但由于整體架構(gòu)的缺陷，在部署效率、部署資源動態(tài)管理、區(qū)塊鏈網(wǎng)絡(luò)服務(wù)狀態(tài)實(shí)時監(jiān)控、賬本高可用、證書托管等方面遇到了較大的技術(shù)難度，進(jìn)一步迭代升級的成本非常大。因此重新進(jìn)行 BaaS 的總體設(shè)計，擁抱 Kubernetes、擁抱云原生變得非常重要。
BaaS 為什么擁抱云原生
云原生是關(guān)于速度和敏捷性的，有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用，能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。
符合云原生架構(gòu)的應(yīng)用程序應(yīng)該是采用開源技術(shù)棧（Kubernetes+Docker）進(jìn)行容器化部署，利用基礎(chǔ)設(shè)施管理能力實(shí)現(xiàn)資源彈性伸縮、服務(wù)動態(tài)部署與資源利用率優(yōu)化等。
中科金財 SinoBaaS 平臺在對區(qū)塊鏈網(wǎng)絡(luò)進(jìn)行動態(tài)部署管理、運(yùn)行檢測、資源彈性擴(kuò)充等方面的迫切需求與云原生的一些特點(diǎn)非常契合，因此在新的版本改造過程中決定全面集成 Kubernetes。
選型說明
在決定擁抱云原生架構(gòu)的時候我們選型決定要使用其中非常活躍和成熟的 Kubernetes 作為我們平臺的底層支撐，但是 Kubernetes 整體系統(tǒng)比較復(fù)雜學(xué)習(xí)成本比較高，對非專業(yè)用戶使用非常不友好。綜合考慮之后我們決定選擇一個較完善的 Kubernetes 發(fā)行版本。我們針對市場上一些比較流行的平臺做了評估，最終選擇了 KubeSphere 作為我們的管理平臺。
選擇 KubeSphere 主要原因有以下幾點(diǎn)：
整體融合
KubeSphere 擁有一套非常完善的配套功能，這讓我們只需要重點(diǎn)關(guān)注區(qū)塊鏈相關(guān)的功能組件開發(fā)就可以。中科金財 BaaS 平臺在 KubeSphere 上做了以下融合：
實(shí)踐過程
平臺的整體架構(gòu)
中科金財針對 BaaS 平臺所需要具備如靈活部署、資源動態(tài)伸縮管理、可視化運(yùn)維、細(xì)顆粒度監(jiān)控與預(yù)警、運(yùn)行高可靠等方面的核心能力，進(jìn)行了中科金財區(qū)塊鏈即服務(wù)平臺 SinoBaaS 的總體設(shè)計，設(shè)計圖如下：
平臺所采用的存儲方案
SinoBaaS 在初期的實(shí)踐中使用了 PersistentVolume 的 localhost 模式，這種方式使得區(qū)塊鏈節(jié)點(diǎn)對物理節(jié)點(diǎn)的耦合性非常高，且證書也都保存在物理環(huán)境中，使得 Kubernetes 的自動調(diào)度的特性被嚴(yán)重限制了。在組建區(qū)塊鏈網(wǎng)絡(luò)中還需要通過證書加密，證書保存到本地安全隱患也非常高，一旦磁盤損壞可能會導(dǎo)致證書丟失，失去了證書的節(jié)點(diǎn)服務(wù)就跟失去了身份的人一樣，后續(xù)的補(bǔ)償措施非常困難。
因此在開發(fā)過程中，引入了獨(dú)立的分布式存儲，并將證書等信息存儲在 Kubernetes 的 ConfigMap 中，整個區(qū)塊鏈網(wǎng)絡(luò)運(yùn)行所產(chǎn)生的賬本數(shù)據(jù)、狀態(tài)數(shù)據(jù)、證書等都得到了高可靠的存儲，解決了 Kubernetes 在漂移調(diào)度過程中資源依賴問題。
平臺部署方案
在 BaaS 平臺未融合 KubeSphere 改造前，區(qū)塊鏈網(wǎng)絡(luò)部署過程相當(dāng)繁瑣，首先需要我們手動生成區(qū)塊鏈網(wǎng)絡(luò)所需的證書再分別拷貝到節(jié)點(diǎn)機(jī)器上，再通過修改腳本參數(shù)生成部署組織節(jié)點(diǎn)的 yaml 文件，然后才能部署到各個機(jī)器中，整個部署過程十分不標(biāo)準(zhǔn)且容易出錯，排查起來問題比較困難，整體部署效率較低。
我們在選擇 KubeSphere 時就考慮到它擁有一套標(biāo)準(zhǔn)的部署流程，而且 ks-installer 工具也是開源的非常適合我們針對部署痛點(diǎn)進(jìn)行優(yōu)化。優(yōu)化過后的 ks-installer 集群可以實(shí)現(xiàn)只需要根據(jù)不同項(xiàng)目環(huán)境修改特定的幾個參數(shù)就可以非常流暢的部署一套標(biāo)準(zhǔn)的 BaaS 平臺。
平臺融合區(qū)塊鏈方案
部署區(qū)塊鏈網(wǎng)絡(luò)
我們認(rèn)為使用 BaaS 進(jìn)行部署區(qū)塊鏈網(wǎng)絡(luò)時一般考慮幾點(diǎn)要素：
- 隱藏區(qū)塊鏈關(guān)鍵技術(shù)的概念，比如共識算法，P2P 網(wǎng)絡(luò)，密碼學(xué)，交易管理等。
- 隱藏技術(shù)細(xì)節(jié)，BaaS 平臺的網(wǎng)絡(luò)的搭建，比如落塊的規(guī)則，peer 錨節(jié)點(diǎn)的設(shè)定，狀態(tài)數(shù)據(jù)庫選擇 LevelDB 還是 CouchDB 等。
- 操作足夠簡單，輸入幾個配置信息就能搭建區(qū)塊鏈網(wǎng)絡(luò)。
- 基于 RBAC 的身份鑒別。
- 平臺的監(jiān)控告警。
- 數(shù)據(jù)完備，容災(zāi)切換等高可用機(jī)制。
- 能進(jìn)行水平擴(kuò)展與收縮，比如能迅速新增節(jié)點(diǎn)，關(guān)閉 Node 節(jié)點(diǎn)時平臺服務(wù)不會收到影響。
- 同時支持多用戶多業(yè)務(wù)實(shí)現(xiàn)鏈上操作。
- 對各類區(qū)塊鏈技術(shù)及各類應(yīng)用場景需要保持開放性，比如存儲智能合約的鏈碼倉庫，以及鏈碼管理。
- 用戶信息，證書，部署信息，賬本數(shù)據(jù)，交易信息進(jìn)行隔離。
創(chuàng)建完的聯(lián)盟的架構(gòu)如下：
整個區(qū)塊鏈聯(lián)盟使用 Namespace 作為資源的隔離，整體的搭建也分為三層 : 服務(wù)層（service），容器層（Pod），和分布式存儲。
區(qū)塊鏈網(wǎng)絡(luò)管理
區(qū)塊鏈的管理，直接面對用戶，提供給運(yùn)維或者普通用戶來操作，所以既要保證可操作性又要保證關(guān)鍵數(shù)據(jù)的呈現(xiàn)。
當(dāng)然針對各類應(yīng)用場景如數(shù)據(jù)層證，資產(chǎn)轉(zhuǎn)賬等常用場景我們也提供了內(nèi)置的鏈碼，如需定制化智能合約可以通過鏈碼倉庫來上傳鏈碼，并進(jìn)行實(shí)例化等操作，能有比較好的開放性。
本地化開發(fā)模式
在對 KubeSphere 進(jìn)行二次開發(fā)的過程中，前端的本地化開發(fā)比較容易只需要替換 server/config.yaml 中的 server:apiServer:url/wsUrl 地址便可。但后端的本地化開發(fā)便涉及到若干問題：如何確保開發(fā)環(huán)境與測試環(huán)境的一致，如何快速開發(fā)調(diào)試，如果開發(fā)涉及到多個云上多個服務(wù)之間的相互調(diào)用又該如何？這些問題成為了團(tuán)隊(duì)開發(fā)的痛點(diǎn)。
這讓我們團(tuán)隊(duì)積極探索本地化開發(fā)的方式，其中telepresence和kt-connect都能解決以上痛點(diǎn)，實(shí)現(xiàn)的效果類似，都能將集群流量轉(zhuǎn)發(fā)到本地。_ 這里使用 kt-connect 官方原圖說明一下 _。
多租戶融合
KubeSphere 平臺提供了多租戶管理，角色管理，并以企業(yè)空間，項(xiàng)目進(jìn)行更細(xì)顆粒度的權(quán)限管理。結(jié)合區(qū)塊鏈 BaaS 平臺也需要多租戶，創(chuàng)建區(qū)塊鏈聯(lián)盟，并在聯(lián)盟中創(chuàng)建區(qū)塊鏈節(jié)點(diǎn)和服務(wù)。BaaS 在 KubeSphere 的多租戶的基礎(chǔ)上進(jìn)行融合，提供多租戶的登錄能力，每一個租戶創(chuàng)建自己的區(qū)塊鏈服務(wù)；通過 BaaS 創(chuàng)建的區(qū)塊鏈服務(wù)來滿足業(yè)務(wù)系統(tǒng)的上鏈需求。
區(qū)塊鏈創(chuàng)建一個聯(lián)盟，包含一個和多個組織同時每個組織擁有一定數(shù)量的區(qū)塊鏈節(jié)點(diǎn)，提供區(qū)塊鏈服務(wù)。通過 BaaS 平臺創(chuàng)建用戶并關(guān)聯(lián)相應(yīng)的組織，當(dāng)創(chuàng)建聯(lián)盟時邀請相關(guān)組織加入聯(lián)盟。
用戶基本信息如下： 包括用戶名，用戶所屬組織，用戶郵箱等信息。
在 Baas 平臺中的組織管理中可以添加組織并關(guān)聯(lián)到用戶，再邀請到創(chuàng)建的聯(lián)盟中進(jìn)行通道和智能合約的操作。
實(shí)踐過程中遇到的問題
SinoBaaS 平臺從開始改造，到積極擁抱云原生架構(gòu)，到最終選擇 KubeSphere 作為技術(shù)開發(fā)平臺，也遇到不少的問題和挑戰(zhàn) :
- 不熟悉 K8s：在 K8s 概念、部署、使用方式的各個方面都要學(xué)習(xí)和探索。
- 不熟悉云原生的開發(fā)和調(diào)試流程：不熟悉 KubeSphere 的前后端和安裝腳本 ks-install，從最開始的二進(jìn)制方式運(yùn)行 ks-apiserver，本地化調(diào)試前端 , 到容器化部署，在開發(fā)過程中也缺乏對容器化開發(fā)調(diào)試的方法，到最后選擇 telepresence 代理方式調(diào)試服務(wù)。
- 不熟悉 KubeSphere 的代碼和功能組件 : 通過官方文檔和社區(qū)逐漸熟悉 kapi 接口，KubeSphere 的架構(gòu)和在 CRD 的擴(kuò)展方面不斷的摸索，最終在自定義 CRD 部分，重新設(shè)計區(qū)塊鏈部分的 CRD 結(jié)構(gòu)。
- 區(qū)塊鏈功能和 KubeSphere 的融合：在融合方面，由于區(qū)塊鏈服務(wù)和 KubeSphere 功能還是有不少差異。在聯(lián)盟管理，項(xiàng)目角色以及企業(yè)空間等方面的融合與展示，以達(dá)到不至于特別突兀的效果，團(tuán)隊(duì)內(nèi)部進(jìn)行了數(shù)次討論。
使用效果
SinoBaaS 平臺經(jīng)過 KubeSphere 的初步改造升級，完成了區(qū)塊鏈聯(lián)盟的創(chuàng)建，組織管理，通道管理，鏈碼倉庫，鏈碼管理，區(qū)塊和交易查詢，數(shù)據(jù)存證和資產(chǎn)轉(zhuǎn)賬等功能。聯(lián)盟的創(chuàng)建和刪除更加的便捷，融合 KubeSphere 的企業(yè)空間和項(xiàng)目進(jìn)行了多層級的權(quán)限管理，不同角色的用戶可以有不同的區(qū)塊鏈視圖，看到不同的區(qū)塊鏈的節(jié)點(diǎn)和服務(wù)信息。簡單效果如下：
區(qū)塊鏈瀏覽器頁面：
聯(lián)盟概覽頁面：
信息查詢頁面（可以通過區(qū)塊號，區(qū)塊 hash，交易 ID 等進(jìn)行查詢操作）：
未來規(guī)劃和展望
在 SinoBaaS 1.0 版本開發(fā)結(jié)束后，我們也在抓緊推進(jìn)后續(xù)版本的規(guī)劃和迭代，在此也做一下列舉說明，以供參考交流。
本地協(xié)同開發(fā)模式
目前可以實(shí)現(xiàn)將 ks-apiserver 云上的流量全部攔截在本地，但是在面對多人協(xié)同開發(fā)時還存在不足，下一步需要實(shí)現(xiàn)創(chuàng)建路由規(guī)則重定向特定流量，實(shí)現(xiàn)多人協(xié)作場景下互不影響的本地調(diào)試。
自定義服務(wù)組件
目前區(qū)塊鏈網(wǎng)絡(luò)還是以本地化 SDK 的方式接入，在使用便捷性和標(biāo)準(zhǔn)化方面還存在不足，且還無法對訪問進(jìn)行審計管控，因此還需要在平臺中開發(fā)基于 AK/SK 的 API 服務(wù)，作為區(qū)塊鏈網(wǎng)絡(luò)對外接入訪問的入口，并將 API 的服務(wù)作為 KubeSphere 的一個服務(wù)組件，并配置進(jìn) ks-installer 中，隨平臺的一起初始化部署，并在 Service Components 中可以查詢到服務(wù)的狀態(tài)。
后續(xù)甚至可以加入更多的 DApp 應(yīng)用，都可以納入服務(wù)組件中統(tǒng)一管理，并在應(yīng)用環(huán)節(jié)深度集成到平臺的各個功能中。
集群聯(lián)邦下打造區(qū)塊鏈聯(lián)邦網(wǎng)絡(luò)
SinoBaas 平臺為更好的適應(yīng)復(fù)雜網(wǎng)絡(luò)場景下的需求，如多個參與組織都有獨(dú)立的局域網(wǎng)，相互間以專線形式通訊，考慮依托 KubeSphere 的多集群托管模式實(shí)現(xiàn)跨集群區(qū)塊鏈組網(wǎng)和區(qū)塊鏈跨網(wǎng)絡(luò)通信，真正解決聯(lián)盟鏈應(yīng)用下復(fù)雜網(wǎng)絡(luò)對區(qū)塊鏈運(yùn)行及管理的影響。
基于應(yīng)用商店來打造合約商店
KubeSphere 中提供了應(yīng)用商店的功能，用戶可以上傳、部署應(yīng)用商店的應(yīng)用或者自定義應(yīng)用。區(qū)塊鏈中有很多基于智能合約的應(yīng)用（溯源、存證、加密貓，基于 ERC721 的數(shù)字藏品等），將基于智能合約的應(yīng)用打造成標(biāo)準(zhǔn)的合約模板，借助應(yīng)用商店的機(jī)制來打造合約商店，方便 SinoBaaS 平臺的用戶自主選擇合約應(yīng)用進(jìn)行部署。
本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！
總結(jié)
以上是生活随笔為你收集整理的中科金财区块链平台容器化最佳实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java成绩录入系统健壮性_Java第三
- 下一篇： 佳能Canon iR8500 LIPS