1 论文摘要

软件交付是软件外包的重要环节。在传统的外包软件交付过程中，经常会出现需求变更不透明、第三方评估结果不可靠或被篡改、交付软件与被评估软件不一致等问题。区块链技术具有去中心化、不可篡改、可追溯、可执行智能合约等特点。将区块链技术应用于软件交付过程，可以保证软件及其关键数据的可信性和可追溯性，以解决传统软件交付过程中存在的问题。本文设计并实现了一个基于区块链的软件交付过程管理系统。该系统为软件需求者、软件开发人员和软件测试人员提供订单管理、软件证书管理、测试报告管理和软件自动验收等功能。本系统采用目前流行的联盟链框架Hyperledger Fabric作为本系统区块链的底层实现。该系统采用微服务架构，将系统划分为用户服务、文件服务、订单服务、软件证书服务和自动受理服务等多个细粒度、业务重点突出的服务。微服务实现了“高内聚、低耦合”的设计思想，每个服务都可以独立部署，快速迭代。每项服务采用分层架构，分为表示层、控制层、逻辑层和数据持久层。为了减轻区块链的数据存储压力，该系统将软件证书和其他文件存储在星际文件传输系统中，只有代表文件地址的关键对象和xdddxh存储在区块链。该系统的技术路线如下：表示层采用Vue框架生态，业务逻辑层采用SpringBoot框架，缓存数据库采用Redis和TiDB，服务发现和注册采用Consul，用户认证采用LDAP。该系统采用Kubernetes进行服务安排和部署，横向扩展性强，服务可用性高。该系统通过区块链的不可篡改性保证了系统数据的真实性和可信度。为了方便用户将页面上显示的信息与链中存储的信息进行比较，订单详细信息页面中内置了许多可以跳转到Hyperledger Explorer的超链接。通过链接数据与页面数据的对比，用户可以判断软件测试结果是否被篡改，交付的软件是否与评测软件一致，保证了软件交付过程的可靠性。在该系统中，TiDB被引入作为星际文件系统的数据缓存层。测试完读取接口后，通过添加缓存，读取接口的效率几乎提高了一倍。目前，系统已进入试运行阶段，多种软件评估结构已成功接入系统，系统支持的软件交付生态正在建立。

关键词：区块链，星际文件传输系统，软件交付，微服务

00-1010 2.1星际文件系统

目标在计算机世界中，如果两个用户想要互相发送信息，他们需要一组通用规则来定义信息的传输模式和时间。这些规则被广泛称为通信协议。自20世纪80年代以来，通信协议使世界上的计算机能够相互连接和通信。今天的互联网主要是客户端和服务器之间的交互，这依赖于以超文本传输协议(也称为HTTP协议)为主的IP协议。长期以来，数据存储在集中式服务器中，并通过基于位置的寻址进行访问。这使得分发、管理和保护数据变得更加容易，并扩大了服务器和客户端的容量。然而，在安全、隐私和效率等领域，这种方法存在很多弱点：将对服务器的控制转化为对数据的控制。这意味着控制服务器的任何人都可以访问、更改和删除服务器上的数据。在基于位置的寻址中，数据是由其位置而不是其内容来标识的。这种限制意味着用户必须一直访问某个特定位置的数据，即使可以在更近的地方获得相同的数据。也不可能确定数据是否已经更改，因为客户端只需要知道数据在哪里，而不需要知道它是什么。星际文件系统是点对点协议行星际文件系统的中文名称，一般称为IPFS。该协议由胡安贝内特于2014年5月发起。IPFS试图通过一个新颖的p2p文件共享系统来解决CS模型和HTTP协议的不足。IPFS由以下关键组件组成：分布式哈希表、块交换、MerkleDAG、版本控制系统和自认证文件系统。哈希表是一种将信息存储为键/值对的数据结构。在分布式哈希表中，数据分布在计算机网络上并有效协调，实现节点间的有效访问和搜索。块交换组件是IPFS实现的数据交换工具，用于节点间的数据传输。Merkle DAG是mtdzt树和有向无环图的结合。mtdzt树保证了p2p网络上交换的数据块是正确的、未被破坏的、不可改变的。这种验证是通过使用加密散列函数组织数据块来完成的。这只是一个接受输入并计算对应于输入的唯一字母数字字符串的函数，也就是我们所说的xdddxh。Merkle DAG结构的另一个强大功能是，它构建了一个分布式版本控制系统，允许用户独立复制和编辑文件的多个版本，存储这些版本，以后将编辑内容与原始文件合并。IPFS的最后一个重要组成部分是自认证文件系统，这是一个分布式文件系统，不需要特殊的数据交换权限。这是“自认证”，因为提供给客户端的数据是通过文件名认证的。通过这种身份验证，用户可以安全地访问远程内容。简单地说，使用分布式哈希表，节点可以存储和共享数据，而无需中央协调。MerkleDAG可以实现数据的唯一标识、防篡改和永久存储，让用户可以通过版本控制系统访问过去版本的编辑数据。

IPFS从根本上改变了搜索方式，这是它最重要的特点。通过HTTP，我们在寻找位置，而通过IPFS，我们在寻找内容。做IPFS的方法是不关心中央服务器的位置，或者文件的名称和路径，而只关心文件中可能的内容。将资源文件放在IPFS节点中，它将获得一个新名称——Hashkey，这是一个根据文件内容计算的加密xdddxh。Xddxh直接反映文件的内容，即使只修改了一位，xdd xh也会完全不同。和快速DFS等

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

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

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

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

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