1. 首页
  2. >
  3. 技术专题
  4. >
  5. 区块链

基于区块链的软件交付过程管理系统的设计与实现

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中可追踪,这些变化改善了传统软件交付流程,整个系统也因此变得可信与稳固。本系统在多方面都还有很多不足之处和可拓展的空间。

首先,本系统在功能上还有一些欠缺和不足。目前系统中的订单确认功能还稍显简陋,订单确定在现实场景中需要涉及到招标、投标以及签写合同等过程,本系统目前仅可作为线下过程的一种补充,后续的开发中可考虑将招标投标结果和合同文档等进行电子化。此外本系统目前已对接集成南京**公司的移动端兼容性测试服务与移动端性能测试服务,以后需要通过进一步的线下运营接入更多测试服务提供商以丰富系统多元性。

第二,本系统内部接口设计时已尽可能考虑底层技术与底层服务的可替换性,例如文件系统与缓存系统,不同底层技术之间的组合是否会带来更好地性能或者更高的稳定性,还需要进一步的探索与测评。与此同时,底层技术的选用应可在配置文件中进行配置。

第三,虽然系统在设计之初与编写过程中已尽可能注意性能优化,但随着业务量进一步上升,本系统还是会面临一定的性能压力,此时需要对区块链底层技术的选用进行考量。

最后,本系统还有和众包相结合的可能性。链上的软件证书中可进一步包含具体开发者对本项目的贡献程度,这样链上的所有软件证书信息通过某种方法综合起来可得到具体某位开发者的某种开发能力,这对众包流程中的众包工人选择是一种帮助。