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 系统用例图