1 論文摘要

軟件交付是是軟件外包中的重要一環。傳統外包軟件交付過程常常存在著需求變更不透明、第三方測評結果不可信或被篡改、交付軟件與被測評軟件不一致等問題。區塊鏈技術具有去中心化、不可篡改、可溯源和可執行智能合約等特點。將區塊鏈技術應用於軟件交付過程，能夠保障軟件及其關鍵數據的可信與可溯源，以期能夠解決傳統軟件交付過程存在的問題。本文設計和實現了一個基於區塊鏈的軟件交付過程管理系統。本系統為軟件需求方、軟件開發方與軟件測評方提供訂單管理、軟件證書管理、測試報告管理和軟件自動驗收等功能。本系統採用當前流行的聯盟鏈框架Hyperledger Fabric作為本系統的區塊鏈底層實現。本系統採取微服務架構，系統被劃分為細粒度且業務聚焦的若干服務，包括用戶服務、文件服務、訂單服務、軟件證書服務和自動驗收服務等。微服務貫徹了“高內聚、低耦合”的設計思想，每個服務均可獨立部署以及快速迭代。每個服務中均採用分層架構，分為展示層、控制層、邏輯層和數據持久層。為減輕區塊鏈數據存儲壓力，本系統將軟件證書等文件存入星際文件傳輸系統，在區塊鏈中僅存儲關鍵對象與代表文件地址的哈希值。本系統的技術路線為：展示層使用Vue框架生態，業務邏輯層使用SpringBoot框架，緩存數據庫使用Redis與TiDB，服務發現與註冊選用Consul，用戶認證使用LDAP。本系統使用Kubernetes進行服務編排與部署，有較強的水平拓展性與較高的服務可用性。本系統通過區塊鏈的不可篡改性保證系統數據的真實可信。為方便用戶將頁面展示信息與鏈上存儲信息進行比對，訂單詳情頁面已內置諸多可跳轉至Hyperledger Explorer的超鏈接。通過將鏈上數據與頁面數據進行對比，用戶可確定軟件測試結果是否被篡改和交付軟件與測評軟件是否一致，這使得軟件交付過程的可靠性得到保障。本系統引入TiDB作為星際文件系統數據緩存層，經過對讀接口進行測試，緩存的加入使得讀接口的效率提高近一倍。目前該系統已進入試運行階段，已有數家軟件測評結構順利接入本系統，以本系統為支撐的軟件交付生態正在建立。

關鍵詞： 區塊鏈，星際文件傳輸系統，軟件交付，微服務

2 技術介紹

2.1 星際文件系統

目在計算機的世界裡，兩個用戶如果想要互相發送信息，他們需要通用的規則集來定義信息的傳輸方式和時間，這些規則被廣泛地稱為通信協議。從1980年代開始，通信協議使得世界上的計算機可以相互連接並通信。當今的互聯網主要是客戶端和服務器間的交互，這種交互依賴以超文本媒體傳輸協議（也就是我們常說的HTTP協議）為主的IP協議。很長一段時間裡，數據存儲在集中式服務器中，並通過基於位置的尋址進行訪問。這樣可以更輕鬆地分發、管理和保護數據，並擴展服務器和客戶端的容量。然而，在安全性、隱私性和效率領域這種方式存在許多弱點：服務器的控制轉換為對數據的控制。這意味著任何控制服務器的一方都可以訪問，更改和刪除服務器上的數據。在基於位置的尋址中，數據通過它所在的位置而不是其內容來識別。這種限制意味著用戶必須一直到特定位置訪問一段數據，即使相同的數據可以在更近的地方獲得。也無法判斷數據是否已被更改，因為客戶端只需知道數據在哪裡，而不知道數據是什麼。星際文件系統是點對點協議InterPlanetaryFileSystem的中文名，一般簡稱為IPFS。該協議是JuanBenet在2014年5月份發起。IPFS試圖通過一種新穎的p2p文件共享系統解決CS模型和HTTP協議的不足。IPFS由如下幾個關鍵組件構成：分佈式哈希表、塊交換、MerkleDAG、版本控制系統、自認證文件系統。哈希表是將信息存儲為鍵/值對的數據結構，在分佈式哈希表中，數據分佈在計算機網絡上，並且有效地協調以實現節點之間的有效訪問和查找。塊交換組件是IPFS實現的一個數據交換工具，用於節點間的數據傳輸。Merkle DAG是默克爾樹（MerkleTree）和有向無環圖（Directed Acyclic Graph）的結合，默克爾樹確保在p2p網絡上交換的數據塊是正確的、未損壞的且不變的。通過使用加密散列函數組織數據塊來完成此驗證。這只是一個函數，它接受輸入並計算與該輸入相對應的唯一字母數字字符串――也就是我們說的哈希值。Merkle DAG結構的另一個強大功能是它構建了分佈式版本控制系統，它允許用戶獨立複製和編輯文件的多個版本，存儲這些版本以及稍後將編輯與原始文件合併。IPFS的最後一個重要組成部分是自我認證文件系統，它是一個分佈式文件系統，不需要特殊的數據交換權限。它是“自我認證”的，因為提供給客戶端的數據是通過文件名進行身份驗證的。有了這個認證，用戶可以安全地訪問遠程內容。簡單得講，使用分佈式哈希表，節點可以存儲和共享數據，而無需中央協調，MerkleDAG可實現唯一標識，防篡改和永久存儲的數據，這樣用戶可以通過版本控制系統訪問編輯數據的過去版本。

IPFS從根本上改變了查找的方式，這是它最重要的特徵。使用HTTP我們查找的是位置，而使用IPFS我們查找的是內容。IPFS的做法則是不再關心中心服務器的位置，也不考慮文件的名字和路徑，只關注文件中可能出現的內容。把資源文件放到IPFS節點，它會得到一個新名字――HashKey，這是一個由文件內容計算出的加密哈希值。哈希值直接反映文件的內容，哪怕只修改1比特，哈希值也會完全不同。和FastDFS等其他的文件系統相比，IPFS擴展了加密貨幣和其他區塊鏈技術,這都歸功於IPFS提供的數據持久性與不可變更性，雖然這些特徵的代價是額外的存儲空間。本項目中，通過將一部分文件存在IPFS中從而做薄了區塊鏈中存儲的數據，區塊鏈中僅存IPFS文件的Hash值，整個系統的性能得到了一定的提升。

2.2 微服務

最初軟件開發一般選用單體架構即所有業務均寫在同一項目之中，隨著項目變大會導致代碼膨脹並難以維護。後來為了具備一定的可擴展性和可靠性，垂直架構被提出，通過負載均衡改善前後端通信瓶頸問題，再後來SOA架構嘗試解決了複雜應用系統之間是如何集成與互通，現如今的微服務架構則是進一步探討一個複雜應用系統該被如何設計才能夠更好得進行團隊開發與更便於管理。微服務架構的本質就是圍繞業務領域組件來創建各細業務粒 度應用，讓應用可以獨立得被開發、管理與部署。

微服務的好處可以總結如下：每個微服務組件都簡單靈活，負責獨立業務，可由小規模團隊獨立開發，可獨立部署；不需要一個龐大的應用服務器來支撐，可以由一個小團隊更專注專業負責其開發與運維，相應得也就更高效可靠；微服務架構遵循“高內聚低耦合”的設計思想，每個微服務業務相對獨立，且每個微服務有良好的可水平拓展性與可修改性；微服務架構與開發語言無關，每個微服務開發團隊可自由選擇合適的語言和工具。

在引入了微服務架構後，也會暴露一些新的難點，例如依賴服務變更困難、團隊之間的服務接口文檔變更不透明、依賴服務導致難以上線、驗證獨立服務較為困難等。同時微服務還引入了分佈式架構中的一系列問題，例如分佈式事務的處理、依賴服務不穩定和服務上線依賴等。從部署運維角度分析，部署製品數量的增多與監控進程的增多帶來更復雜的運維場景。

為儘可能解決上述問題，儘可能享受微服務架構帶來的便利，通常會在開發、測試、部署運維等環節綜合運用多種技術與方案。主流的微服務框架一般需要包括服務發現與服務治理，服務容錯，服務熔斷，服務網關，服務配置，負載均衡，消息總線，服務跟蹤等功能。Spring Cloud是由Netflix開源出的一套成熟組件，由獨立組件負責上述的每個功能。除了Spring Cloud整體方案，利用Nginx、Consul、Etcd以及Dubbo等由不同團隊維護的開源軟件也可以實現微服務架構。

2.3 Devops工具鏈

DevOps代表著開發（Development）和運維（Operations）的組合，強調軟件開發人員和運維人員的溝通與合作，通過容器與編排等技術來使得軟件構建、軟件自動測試、軟件部署發佈更加得快捷、頻繁與可靠。換句話講，DevOps是一個完整的涉及軟件開發、軟件測試和軟件部署的工作流，這個工作流以持續集成和持續部署為基礎，來優化軟件開發、測試、系統運維中的所有環節。廣義的DevOps工具鏈包括代碼管理、構建工具、自動部署、持續集成、配置管理、容器、容器編排、服務註冊與發現、日誌管理、系統監控壓力測試、消息總線以及項目管理等諸多類型的工具。本小節僅選取系統開發中最有代表性的容器技術、編排技術、服務器管理技術和服務發現技術進行介紹與分析。

容器技術：Docker是一個開源的應用容器引擎，由Go語言進行開發，通過Apache2.0協議開源。Docker可以讓開發者把應用打包成一個標準鏡像，並且以容器的方式運行。Docker容器將一系列軟件包裝在一個完整文件系統中，這個文件系統包含應用程序所需的一切，包括代碼、運行時工具、系統工具以及系統依賴。幾乎任何可以裝在服務器上的東西都可以被裝入Docker中。這些策略保證了Docker容器內應用程序運行環境的穩定性。Docker依賴LinuxKernel中的Namspace和Cgroups功能，所以即使Docker也可以在Windows上運行，本質上是先在Windows上裝了Linux系統虛擬機後再運行Docker。故本系統選用Centos等Linux系列服務器進行部署安裝，以避免不必要的性能損失。

容器編排工具：Kubernetes在2015年發佈，最初由谷歌創建。其Kubernetes本質上是開源的集群管理軟件，用於部署、運行和管理Docker容器。通過Kubernetes，開發人員可以專注於應用程序本身，而不用擔心提供它們運行時的底層基礎設施。Kubernetes使與部署和管理應用相關的所有工作都得以簡化。Kubernetes會自動執行發佈和回滾操作，並監控服務的運行狀況以在出現不良影響之前阻止那些存在問題的發佈。它還會對服務不間斷地執行運行狀況檢查，重新啟動有故障或停滯的容器，且只會在確認已成功啟動服務時向客戶提供服務。此外，Kubernetes還會自動根據利用率上下調節服務容量，確保在需要的時刻只運行需要的服務容器。與容器一樣，Kubernetes支持對集群進行聲明式管理，以便對設置進行版本控制。最重要的是，Kubernetes可在任何地方使用，開發者可以在本地部署、公有云部署以及混合部署之間進行協調。這讓整個團隊的基礎架構可以覆蓋位於任何位置的用戶，讓應用可以實現更高的可用性，讓整個團隊可以在安全與費用上取得平衡，一切都可根據項目具體需求定製。

服務器管理技術：Ansible是一個開源的IT自動化引擎，可以消除運維人員工作中的重複性事務，還可以顯著提高IT環境的可擴展性，一致性和可靠。Ansible中的自動執行任務可被分為三種。配置在基礎架構中設置所需的各種服務器是Ansible最常見的功能。Ansible也可用於配置管理，也就是更改應用程序、操作系統或設備的配置；啟動和停止服務;安裝或更新應用程序;實施安全政策;或執行各種其他配置任務。Ansible還可以用於應用程序部署，通過自動將內部開發的應用程序部署到生產系統，使DevOps更容易更流暢。

服務發現技術：Consul是一個分佈式，高度可用服務網格系統，除了允許服務相互發現之外，Consul還允許開發者通過內置運行狀況檢查來監控群集運行狀況，還可以充當分佈式鍵值存儲。Consul的由agent和server組成。agent允許服務公佈它們的存在，而Consul的server收集agent共享的信息，並作為服務信息的中央存儲庫。agent在提供服務的節點上運行，並負責健康檢查服務以及節點本身。Consul還可以與當前流行的容器管理平臺進行配合使用，如Kubernetes和Azure Service Fabric。雖然Kubernetes和Service Fabric等容器編排工具都提供了自己的服務發現和健康檢查機制，但Consul允許這些平臺與位於其管理邊界之外的服務集成。例如，在Kubernetes集群外部運行的Web服務或數據庫，可以通過配置部署在Kubernetes上的Consul進行服務發現。

3 工程實現與設計

3.1 需求分析

圖1 系統用例圖

本系統的涉眾主要包括軟件需求方、軟件提供方和軟件測評機構三種類型。軟件需求方因自身的業務發展而產生了新的軟件需求，在本平臺發佈訂單後選擇有資質的提供商與測評機構，依賴本平臺完成交易。一般軟件需求方擁有把軟件需求文檔化的能力，希望通過本系統保障軟件交付過程順利開展。軟件提供商是有較強軟件開發能力的團隊或組織，通過本平臺與軟件需求方達成合作，可以通過本平臺進行軟件製品證書的上傳。軟件測評機構是有較強軟件測試能力的組織或機構，可以根據對軟件的測評結果出具有行業說服力和可行度的測試報告。

3.2 總體架構

圖 2 系統架構圖

本系統的系統架構圖如圖 2所示，本小節從設計與技術的角度進行介紹。為了保證業務層面的高內聚低耦合，開發階段的快速迭代與個性化部署，本系統採用了微服務架構，選用consul作為服務發現與服務註冊的中間件。本系統提供了豐富的業務API與集成SDK，最大限度得豐富了用戶的使用方式。

前端服務採用了Vue框架及其生態中的路由管理器等組件，其優雅的框架設計和出色的性能既提高開發效率也帶來高效的渲染效率。本系統選用了餓了麼開源出的elementUI組件庫配合Vue框架進行信息展示，elementUI是餓了麼從其自身使用Vue框架過程中抽離出的一套標準組件庫，和Vue框架及其生態有著天然的默契。前端服務在項目啟動時向consul發送其地址信息進行服務註冊，並獲得其他業務服務的地址與信息。前端服務通過HTTP請求對其他業務提供的資源與接口進行訪問。

除了前端服務外，服務端的其他服務均採用了SpringBoot框架進行業務邏輯開發，SpringBoot框架可拓展性強且支持眾多服務組件。根據常見的微服務劃分標準，結合對系統用例進行分析，本系統中業務服務可被劃分為用戶服務、訂單服務、軟件證書服務、測試報告服務、自動驗收服務、文件服務，每個服務均獨立使用一個容器資源，詳細的Kubernetes部署方案見本文第五章相關內容。所有業務服務在啟動時均向consul集群進行服務註冊，並得到相關的服務地址以完成後續的業務邏輯。所有的業務服務均採用較為傳統的分層設計，較大程度得減少業務耦合且有良好的可拓展性。在用戶服務的設計過程中，出於兼容存量系統與減少重複開發的目的，本系統選擇接入了LDAP來存儲於認證用戶信息。系統採用了Kubernetes的ingress-nginx組件為負載均衡器，同時ingress-nginx還提供了集群外部訪問Kubernetes集群內部服務的能力，強力支持了本系統對外提供API這一功能。為了減少區塊鏈的存儲壓力，本系統中僅訂單信息，軟件信息，自動驗收相關信息存儲於區塊鏈之中，其他例如需求文檔等均存儲於IPFS之中，同時為了優化IPFS中數據的讀取效率，採用了TiDB和redis作為其緩存，可通過配置文檔進行選擇切換。

4 總結與展望

為改善與解決傳統的軟件交付過程中存在著需求變更不透明、三方測評不可信和交付軟件與測評實體不一致等缺點，本系統利用區塊鏈技術去中心化、可溯源以及不可篡改等優勢，將訂單數據、軟件證書數據和自動驗收相關數據存於區塊鏈中，同時引入IPFS用於存儲非關鍵數據減輕區塊鏈存儲壓力，使得整個系統更加合理。關鍵信息上鍊後，需求變更根據訂單歷史被追溯，三方測評結果不可篡改，交付過程中涉及到的軟件實體信息均在區塊鏈與IPFS中可追蹤，這些變化改善了傳統軟件交付流程，整個系統也因此變得可信與穩固。本系統在多方面都還有很多不足之處和可拓展的空間。

首先，本系統在功能上還有一些欠缺和不足。目前系統中的訂單確認功能還稍顯簡陋，訂單確定在現實場景中需要涉及到招標、投標以及簽寫合同等過程，本系統目前僅可作為線下過程的一種補充，後續的開發中可考慮將招標投標結果和合同文檔等進行電子化。此外本系統目前已對接集成南京**公司的移動端兼容性測試服務與移動端性能測試服務，以後需要通過進一步的線下運營接入更多測試服務提供商以豐富系統多元性。

第二，本系統內部接口設計時已儘可能考慮底層技術與底層服務的可替換性，例如文件系統與緩存系統，不同底層技術之間的組合是否會帶來更好地性能或者更高的穩定性，還需要進一步的探索與測評。與此同時，底層技術的選用應可在配置文件中進行配置。

第三，雖然系統在設計之初與編寫過程中已儘可能注意性能優化，但隨著業務量進一步上升，本系統還是會面臨一定的性能壓力，此時需要對區塊鏈底層技術的選用進行考量。

最後，本系統還有和眾包相結合的可能性。鏈上的軟件證書中可進一步包含具體開發者對本項目的貢獻程度，這樣鏈上的所有軟件證書信息通過某種方法綜合起來可得到具體某位開發者的某種開發能力，這對眾包流程中的眾包工人選擇是一種幫助。