论软件可靠性设计及应用

论软件可靠性设计及应用

摘要：2020年4月，本人所在的某市金融投资集团启动了集团综合管理系统建设，该项目实现基金、融资租赁、资金管理、转贷、融资担保、保理等金融业务管理及人力资源、智能办公、法务管理等内部管理功能。在此项目中，我担任了架构师，负责项目总体架构设计工作。本文以该综合管理系统为例，主要论述了软件可靠性设计在该系统中的应用。在资金计算模块中我们使用了N程序版本设计避免因为单一模块错误而导致整体性的错误；在程序中大规模的使用检错技术，并通过搭建预警系统，及时报警进行人工介入；为了从根源上提升程序可靠性，我们通过采用面向服务的架构及层次架构风格，并在程序中使用了大量的设计模式，降低软件复杂度。最终项目顺利上线，平稳运行，可靠稳定的系统得到了领导和同事的一致好评。
正文：本人所在的某市金融投资集团已经建设了移动办公系统、财务系统、融资租赁系统、基金管理系统等应用系统，但仍有部分业务缺乏信息化支撑，已建成的系统比较分散，主要是“竖井式”方式建设，系统与系统之间信息不共享以及信息与业务流程相脱节。针对这些问题，2020年4月，经集团党委决定，启动集团综合管理系统建设，实现以下功能。一、实现转贷、保理、融资担保、资金管理、人力资源、智能办公等业务流程信息化，同时整合基金管理系统、移动办公系统、财务系统等已有信息资产，促进部门、子公司之间横向协同。二、建立统一共享的信息平台，利用数据报表平台为管理层提供决策信息支持，实现纵向管控。三、建立涵盖分布式文件存储、单点登录、分布式事务支持、短信邮件通知、可控任务调度等服务的基础IT设施，提供高质量、可重用的平台服务。
在此项目中，我担任架构师，负责项目总体架构设计。由于项目范围较大，我采用分层设计，总体分为IT基础设施层、业务层、数据管控层。鉴于业务流程高度类似，业务层中的金融业务又分为通用业务层与具体业务层，通用业务层涵盖项目立项、尽调、调整、合同签订、投放、首付款、收尾整套业务流程，具体业务层在通用业务层上定制实现个性化需求。
软件可靠性设计技术主要有三种。分别是容错设计、检错设计以及降低软件复杂度设计。
如果错误会导致严重后果，那么容错设计是在错误发生时避免造成系统故障的一种设计技术。容错技术主要有三种：1.恢复快设计，即通过选取一组操作作为容错设计单元，设计若干个功能相同、实现不同的程序文本，每个时刻都只有一个文本处于运行状态，当其运行错误时，立刻用备用文本替换，从而形成动态冗余，以达到程序可靠运行的目的；2.N程序版本设计，即设计多个模块或者不同版本，对于相同的输入和相同的初始条件产生的操作结果进行多数表决，从而避免单一模块或版本出现故障导致程序总体故障；3.冗余设计，即在一套完整系统上，设计多个不同路径、不同算法、不同实现的模块或系统，以在系统出现故障时，可以用冗余模块或系统进行替换。检错技术是在程序出现故障时，及时发现并报警，由人工介入进行处理，相对容错技术具有成本低的优点，但是缺点是不能自动处理，需要人工介入。降低程序复杂度可以有效提高软件可靠性，通过简化程序结构，优化数据流，缩短代码数量等均可以做到降低软件复杂度的效果。本文着重介绍N程序版本技术、检错技术、降低软件复杂度技术在项目中的应用。
一、通过N程序版本技术实现容错设计。
金融领域的系统由于涉及资金庞大，本身对软件可靠性的要求就比较高。虽然集团综合管理系统主要是内部管控使用，但是对于软件可靠性仍然不能放松。尤其是各个业务的资金计算模块。综合考虑，我们决定使用N程序版本设计，一方面可以确保程序不会因为单一模块的故障而导致整体功能的计算错误，第二程序在单一模块出现错误时也可以继续运行，对于业务人员是透明无感知的，不会影响业务的进行。首先对于资金计算模块的算法，需求分析人员与业务专家进行详尽的沟通，并进行多次的模拟演练，确立需求的完整性、一致性。然后我们确定好各个业务的资金计算模块的接口及使用流程，将开发人员分为三组，在保证接口和使用流程统一的情况下，分别开发算法。对得到的算法，我们封装了一致的使用模块，在该基础上，我们编写单元测试，生成大量数据进行自动化测试，确保在测试阶段，算法产生的结果是一致的，并由业务专家人工计算结果与算法产生结果进行比对，从而验证结果的正确性。在实际使用过程中，对于输入和相同的初始条件，不同算法产生的结果进行多数表决，当然正常情况下，结果应该是完全一致的，如果有一个不一致，那么就发布警报，但操作继续，业务人员无感知，并由开发人员介入进行检查问题所在，当然如果三个结果均不一致，则判定系统故障，需人工介入处理。
二、通过检错技术实现低成本的可靠性保障。
在实际应用中，出于成本考虑，我们无法对程序大规模的采用容错设计技术，包括时间成本、人工成本、金钱等等。那么检错技术就是一个高性价比的选择。因此在本项目中，我们大量的应用了检错技术。首先，一个稳定的监控预警平台是必须的。我们搭建了基于prometheus和alertmanager的开源监控预警框架。通过prometheus实时监控ELK日志系统，当发生错误时，altertmanager会及时发出预警，通知维护人员介入处理。另外，prometheus会与系统保持心跳连接，在心跳出现故障时发出预警。最后程序代码中大量的错误检查是必须的。计算结果需要在合理的区间范围内，如获取集团部门数据时，返回了空的部门列表，那么必然是错误，此时就需要抛出异常。又比如服务间的相互调用，迟迟没有返回，此时可能是另一个服务已经停止工作，或者超过负载，那么就应该触发超时错误。再比如对于企查查的接口调用，返回了余额不足导致接口返回错误，此时合理的错误检查就会发现错误，并向用户返回合适的错误提示。最后为减轻维护人员的压力，我们对错误进行分级，重要错误24小时都需要即时处理，次要错误可延迟处理。
三、降低软件复杂度从根源上提升软件可靠性。
软件缺陷的根源来自软件的复杂度，越是复杂的设计会产生越多的缺陷。因此我们采用了大量的优秀设计经验降低软件复杂度。首先，我们采用层次架构风格简化系统结构，按业务维度分为IT基础设施层，业务层，数据管控层，按技术维度分为表现层、业务逻辑层、数据访问层。通过设计合理的接口协议，对于每层只需要关注于层之间的接口交互以及层内的实现，而不需要跨层考虑。另外，通过大规模的应用设计模式这一有着大量开源实现的可靠解决方案，我们大大降低了代码质量所带来的可靠性风险。如我们在业务产品系列实例化过程采用了抽象工厂模式，在OSS分布式存储实现过程中采用了策略模式，在树形控件实现过程中采用了组合模式等等，这些实现稳定可靠，且设计优良易维护、扩展性又非常强。
最后实现中我们设计了大量的复用组件，这些组件应用的最多，就越证明它们经历了实践的考验，也证明了它们具有良好的设计，毕竟没有良好设计的组件是没法大规模复用的。这类组件包括分布式存储组件、分布式事务组件、持久化组件等等。
在项目开发中，我们也发现了一些不足之处。例如，将业务层分为通用业务层和特定业务层的设计，虽然实现了大规模业务的复用，但是也同样的大大提升了产生问题时所带来的的影响，我们对通用业务层的细微改动可能会产生其他业务的错误，而由于业务一直处于变化过程中，改动又是不可避免的，从而对软件可靠性带来威胁。因此我们采用与业务专家保持紧密联系，对于通用业务层的改动保持慎重评估，三思而后行的策略，并编写大量单元测试保证可靠性。
项目经过一年4个月的开发，于2021年9月上线，至今运行平稳，实现了所预期的横向协作、纵向管控的目标，有力地支撑了集团业务的开展运营，获得了领导和同事的高度认可。通过可靠性设计，一方面降低了系统缺陷的概率，另一方面，错误实现时系统也能做到容错或检错并预警。在实际过程中，多次预警提示错误的发生，从而大大提高了用户体验，并及时处理维护，进一步提升了系统的可靠性。