浅谈信息系统项目可靠性及非功能需求设计

李小明

（广州铁路职业技术学院，广东 广州 510430）

0 引言

本文以微邮局项目为例浅谈信息系统项目可靠性及非功能需求设计。微邮局项目是省邮政公司为响应国家“互联网+邮政”的号召与微信建立起战略合作伙伴关系，将邮政物流、资金流、信息流与微信渠道进行整合，在提高邮政业务处理能力的同时为用户提供便捷服务的一套基于互联网的信息系统。微邮局包括三大部分：服务号、企业号、管理系统。服务号主要功能：我的邮局、寄件收件、邮品预售、报刊杂志订阅、代收代缴、微活动、微信支付、用户中心等；企业号主要功能：部门员工信息同步、移动办公、微信营销、投诉处理、统计报表、员工之家等；管理系统主要功能：各地市邮政服务号、企业号管理、菜单管理、群发推送管理、粉丝管理、订单管理、支付退款、对账清分结算、统计报表等。系统分为前、后端开发：前端采用B/S架构、struts2、mybatis、spring框架、使用java语言开发，应用服务器选用weblogic11g，数据库服务器选用mysql并使用代理服务器nginx和缓存服务器redis。后端主要是对邮政原有业务进行改造，采用省邮政原有架构，C语言开发，对内使用tuxedo中间件进行通信，对外提供webservice接口实现数据交互。

微邮局项目包含邮政寄件、邮品、报刊杂志、代收代缴等核心业务，目标用户包括全省几千万客户及内部近10万员工。由于用户量大、业务复杂度高需要系统7*24小时不间断提供服务，因此在做整体架构设计时系统可靠性设计显得格外重要。首先需要通过专家判断和会议的方式召集干系人就系统可靠性问题进行分析讨论并制定了总体方案和实施计划，在架构设计阶段对系统常见的单点故障问题进行了优化设计，采用集群及冗余的架构策略有效预防了单点问题的出现。项目实施中就接口调用异常超时等问题制定了接口重发取消等异常处理流程，对核心代码采用N版本程序控制方式由不同人员采用不同技术开发。在测试阶段，针对系统架构和异常情况进行重点测试并有效验证了系统容错及纠错能力。运维阶段采用定期机房巡检、异常短信通知等方法进行系统检查以保证系统的可靠运行，除此之外还采用了kafka中间件对消息异步化，进行服务解耦，让用户对数据处理无感知化，从用户使用的角度提高了系统的可靠性（即使后台处理出错用户也感知不到）；同时在微邮局上做秒杀、促销等活动时采用了微服务技术进行服务降级和限流等措施，提高了系统的可靠性，另外还对重要数据进行了异地多机房备份，除省局机房外选择了一个地市机房做为备份机房，对重要数据实时异地备份。在实现可靠性的同时还需要重视非功能需求的设计，在实现基本功能的同时如何满足用户对可用性、性能、安全、易操作等非功能性需求显得格外重要：可用性是基本要求，如果系统不能给用户提供服务就失去了价值也就没有了存在的必要；性能是另一个重要的因素，性能的好坏直接影响到用户的体验和对系统及企业品牌的评价，好口碑需要好性能；安全是互联网应用面临的一大挑战，个人隐私、系统安全等直接影响到客户对企业的信任度及企业的形象；系统是否易用是否好用，用户最有发言权，做系统的目的就是要服务好用户，所以易用性是不得不考虑的一个非功能性需求。

1 系统可靠性设计

（1）在需求规划阶段，针对系统可靠性问题采用专家判断、会议等方法制定具体计划和方案。在项目需求规划阶段通过会议的方式邀请客户高层、业务专家、领域专家一起就系统可靠性组织了专题讨论，明确了采用事前防错、事中容错、事后检测等多种架构策略确保系统的可靠性。

（2）在系统设计阶段，采用冗余、软件容错（恢复块、N版本程序设计、防御式程序设计）、双机双工等多种架构设计策略保证系统的可靠。在架构设计阶段采用多种策略保证系统可靠性，采用应用系统weblogic集群、分布式缓存redis、分布式消息服务kafka等多种技术手段保证应用系统的可靠性；采用mysql数据库分片加分组策略实现mysql的读写分离，主库负责写，从库负责读，采用一主多从、读写分离的方式解决高并发读的问题，采用mycat中间件实现mysql数据库的分片问题，让数据分布在多个节点机器上，有效解决大数据量磁盘不够用的问题。采用mysql数据加redis缓存的技术，在大量读请求时先读redis，如果命中直接返回，如果未命中则从mysql中读取，然后写入redis，下一次同样的查询直接从redis中读取；处理写请求时先写mysql数据库，然后同步更新redis数据库。采用软件容错技术（N版本程序设计）对核心程序由不同的人采用不同的技术和不同的语言开发多个版本，并进行部署，当一个版本异常时可以采用其他版本替代，有效地保证了软件功能的可靠性[1]。

（3）系统实施阶段，特别重视对系统异常情况的处理，通过异常交易定时重发、撤销、取消等多种处理机制保证系统交易的正常和一致。在实施阶段，对系统核心模块进行了重点开发和监控，对代码进行了走查和评审，对不按设计要求的代码进行了重新开发，对支付超时的问题进行了重点检查，是否办理业务以收到微信支付结果通知为准，待确定状态的订单，需要等待日终对账后根据实际情况进行调整。如支付成功则修改订单状态并办理业务，如支付不成功则通知用户，订单改为未支付状态。

（4）测试阶段，针对系统可靠性采取多种异常测试手段，通过模拟异常情况，检查系统的容错能力。采用模拟异常发生的情况进行测试，综合使用白盒测试、黑盒测试、灰盒测试等手段，重点测试核心模块如支付超，系统对账等涉及资金安全的模块，有效防止系统出现长短款等问题。

（5）系统上线阶段，采用集群、异步化、心跳检测等多种架构策略保证系统的可靠性。通过负载均衡、错误请求转发、集群等技术方案有效解决了单节点故障问题，有效保证了业务办理的连续性。通过服务器集群提升服务可靠性，采用负载均衡及错误请求转发等技术实现服务的连续性，使用kafka等分布式消息服务对客户端及服务端进行解耦实现请求的削峰填谷，在促销、秒杀等活动上线时对非核心服务进行降级并对流量进行限流处理防止出现缓存雪崩等服务器灾难，通过多种策略和技术的综合运用有效地提升了系统的可靠性。

（6）系统运维阶段，采用检查机制监控系统、定期巡检、异常短信通知等手段，通过科学的可靠性设计使得系统运行稳定可靠。通过巡检、检查、测试、评审等手段有效地监控风险的发生，例如在一次促销活动时，为了防止用户刷票行为影响排名的公正性，项目组采用了短信验证的手段，后来发现引入短信验证功能是一个风险点，邮政短信网关是否能短时支撑大并发是个问题，后经压力测试，确定短信网关是这次活动的瓶颈，项目组对短信网关进行了升级改造后顺利支撑了本次活动；采用每天巡检的方式安排专人对机房进行巡检，同时使用自动检测系统对系统进行监控并对发生的问题进行短信提醒。例如有一次晚上11点多，项目组成员收到短信报警，称主机温度过高，最后经过排查发现原来是空调故障导致机房温度过高[2]。

2 系统非功能需求设计

（1）对架构需求进行收集和分析，制定总体计划。项目需求规划阶段通过会议的方式邀请客户高层、业务专家、领域专家一起就系统非功能需求进行讨论，明确了几个重要的非功能需求，如系统可用性、性能、安全、易用性。由于系统面向互联网用户，要求7*24小时可用。性能要求用户与系统一次交互过程不能超过1分钟，对已收到的请求系统处理时间应该3秒内处理完成。同时要求系统有入侵防御系统和防火墙，并对敏感数据进行摘要、加密及签名处理。在做系统功能和界面设计时需要体现简单性和一致性，尽量避免和减少用户使用时思考的时间。

（2）采取事前防错、事中容错、事后检测等多种架构策略确保系统的高可用。由于系统针对互联网用户，需要7*24小时运行，在做架构策略时需要使用事前防错、事中容错、事后检测等手段。事前防错就是在故障发生前通过巡检、检查、测试、评审等手段预防风险的发生。事中容错主要是体现系统对错误的容忍度，通过负载均衡，错误请求转发、集群等技术方案有效解决单节点故障问题，有效保证了业务办理的连续性[3]。事后检测主要是采用每天巡检的手段安排专人对机房进行巡检，同时使用自动检测预警系统对系统进行自动监控，对发生的问题进行短信提醒。通过综合运用多种方法保证系统的高可用。

（3）采取多级缓存、异步解耦、服务集群等多种技术手段提升系统的性能。系统对性能要求较高，为了提升系统的性能，针对目前用户量、访问频次、数据量等信息并预留未来3～5年的资源，项目组按需求进行了架构设计，采用分布式缓存、分布式消息队列、分布式数据库等多种手段提升性能。首先采用多级缓存，使用CDN缓存、代理缓存（nginx）、对象缓存（redis）等，在使用对象缓存时考虑到对象缓存的特点，一般存放不经常改动的、有热点的数据且数据在内存中，采用redis哨兵模式一主多从，并在redis上加了一层twemproxy中间件对redis进行分片操作。这样既满足高的并发读要求也满足了数据的动态扩容引起的高并发写的要求。同时使用分布式的消息队列kafka，结合使用点对点和订阅发布模式对生产者和消费者进行解耦，削峰填谷实现系统性能的平稳性，避免出现缓存雪崩等情况。在数据库设计中，使用了mysql数据库，由于数据库需要支撑大量的并发读请求，虽然已经有了redis缓存数据库，能分担大量读的请求，但是当redis里没有命中的时候还是会从数据库中进行读取，为了解决大量用户并发读的要求，对数据库进行分组操作，1个主库负责写操作，2个从库负责读操作，考虑到以后会有大量数据增加容量会成为新的瓶颈，因此采用了分片的策略，采用一致性hash算法进行数据路由并对数据库进行分库操作，使数据分布在不同的节点机器上，实现写的动态扩容[4]。

（4）对关键信息进行摘要，对敏感信息进行加密、对争议信息进行签名，确保信息的完整性、安全性、一致性；同时采用入侵检测、防火墙等技术确保系统安全。对用户密码采用杂凑算法md5进行处理，对用户的敏感信息如支付信息采用摘要、对称加密结合非对称加密（使用对称加密算法的密钥对信息进行加密，同时使用非对称加密算法的私钥对对称加密算法的密钥进行加密）既满足了对数据加密时的性能要求又满足了对数据加密的可靠性和安全要求，另外还使用了入侵检测系统（旁接到系统避免成为瓶颈）和防火墙、安全审计等技术和策略保证系统的安全性[5]。

（5）重视用户体验。采取问卷调查、投票、数据分析等多种手段收集用户使用习惯和偏好以用户为中心进行交互界面和功能设计。需要设计调查问卷并针对目标客户群发放，调查他们的使用偏好，并在粉丝群发起投票功能调查他们的使用习惯，最后对数据进行分析和整理。在后续的功能界面设计中作为参考依据，需要结合用户使用偏好进行功能及界面设计。

（6）对非功能性需求的架构设计经验教训进行总结，并书面记录归入公司组织过程资产以便以后项目可以重用。在系统实施过程中需要特别重视对非功能需求架构设计经验的总结，对取得的成果和遇到的问题进行及时记录，以备以后使用。

3 结语

项目最终成功通过验收，并在系统架构设计过程中获得了很多经验和教训。①在进行可靠性设计时需要根据系统的负载及系统资源使用情况提前估算好系统规模，制定好未来3～5年数据备份及恢复策略；②系统用户的非功能需求（质量属性）往往存在互相约束，对某一方面要求高时，可能会降低另一方面，例如对信息传输过程中的安全性要求高了（加密级别高了），一般会降低系统的性能，因此，对这种系统权衡点的判断和把握需要综合考虑，根据用户对某种质量属性的关注程度和对系统的影响程度进行权衡；③系统整体架构设计评审通过后应严格按照评审后的内容执行。