当前位置: 首页 > article >正文

论软件可靠性设计及其应用

摘要

2023 年 3 月,我所在的公司承接了某智慧加油站平台的建设工作。该项目旨在帮助加油站提升运营效率、降低运营成本和提高销售额。我在该项目中担任系统架构设计师,负责整个项目的架构设计工作。

本文结合我在该项目中的实践,详细论述了软件可靠性设计技术的具体应用。我们主要采用了防卫式程序设计、集群技术和检错技术三种可靠性设计技术。我们采用防卫式程序设计预见潜在错误并提前采取措施,采用集群技术避免单点故障,采用检错技术及时发现故障并报警。通过以上三种技术,我们有效地提升了系统的可靠性。

整个项目历时 10 个月开发完成,并于 2023 年 12 月正式交付并稳定运行至今,各项功能和性能指标均达到了客户要求,得到了客户和各级领导的一致好评。

正文

项目背景

随着国内成品油零售行业竞争日益激烈,某油企为增强市场竞争力,决定建设一个智慧加油站平台,通过引入信息技术来优化运营管理,进一步提升加油站的管理水平和服务质量。我所在的单位成功中标该项目,并于 2023 年 3 月正式启动该项目的建设工作。我被任命为系统架构设计师,负责该项目的系统架构设计工作。

该项目的主要建设内容包括智慧支付、智慧营销、智慧运营等功能子系统。其中智慧支付子系统提供了对多种支付方式的支持,比如现金支付、油卡支付、微信支付、支付宝支付、云闪付支付、车牌付、人脸付、ETC 支付等,以确保顾客下单支付的便利性和安全性;智慧营销子系统支持开展多种形式的营销活动,比如消费返券、趣味抽奖、积分任务、限时秒杀、充值优惠等,以提高顾客复购率;智慧运营子系统涵盖了站务管理、运营数据统计分析等功能,以提高加油站运营效率。

该项目选用 Java 作为主要开发语言,采用基于 Spring Cloud Alibaba 的微服务架构进行构建。我们选择 MySQL 作为数据库,Doris 作为实时数仓,Redis 作为分布式缓存,RocketMQ 作为消息中间件,Flink 作为实时流式计算引擎,并最终在 Kubernetes 集群中部署运行。

可靠性设计的重要性

由于加油站是一个高度运转的环境,任何故障都可能影响加油站的正常运营,因此保障系统的可靠性显得至关重要。软件可靠性是指软件在一定的时间内持续无故障运行的能力,通常使用通常用平均失效等待时间(MTTF)和平均失效间隔时间(MTBF)来衡量。

主流的可靠性设计技术主要有防卫式程序设计、集群技术和检错技术。防卫式程序设计强调在编写代码时采取预防措施,以确保程序在面对意外情况、不合理的输入或错误的使用时,仍能保持稳定运行,避免产生不可预见的行为。集群技术是一种将多台服务器连接在一起,共同工作以实现特定目标的技术。这些节点通过高速网络连接,对外表现为一个单一的系统,共同承担计算任务、数据存储和应用程序的运行。检错技术是指在软件系统出现故障后能够及时发现并告警,提醒相关人员进行处理。检错技术的代价一般低于容错技术和冗余技术。检错技术有一个明显的缺点,那就是发现故障后不能自动修复故障,需要人工进行干预。

在该项目中,为了提高系统的可靠性,我们主要采用了防卫式程序设计、集群技术和检错技术三种可靠性设计技术。下面我将详细介绍这三种可靠性技术在该项目中的具体应用。

防卫式程序设计

我们采用防卫式程序设计来预见错误并提前采取措施来减少这些错误的影响。在智慧营销子系统中,加油站通常会和合作商家联手开展个性化的营销活动,以此提高用户的忠诚度和复购率,一种常见的合作形式是用户在智慧加油站平台中参与营销活动后所获得的奖励需要通过合作商家提供的开放的 API 接口进行兑换。然而,合作商家的系统可能存在不稳定的情况,比如频繁请求响应慢或请求超时等问题。为了避免该系统被这些外部系统拖垮,在智慧营销子系统开发之初,我们就设计了熔断的处理策略。当检测到合作商家的 API 接口在一段时间内频繁出现响应慢或者请求超时等问题,系统会立即停止对合作商家 API 接口的调用,防止问题的进一步扩散。这样可以确保其他子系统的功能不受影响,依然能够正常运行。在熔断期间,系统会持续监测合作商家的系统状态,并定期发起试探性的请求,如果试探请求正常了,则恢复对其接口的正常调用,以恢复奖励兑换等功能。通过熔断措施,我们有效控制了外部系统故障的影响范围,避免了局部的故障逐渐演变为严重的系统事故。

集群技术

我们采用集群技术来避免单点故障。为了简化集群的管理,我们最终将系统部署运行在 Kubernetes 集群上。Kubernetes 可以管理多个工作节点,每个工作节点上可以部署多个服务,此外,还提供自动故障转移和服务自愈的能力。我们将整个系统划分为多个可以独立开发、独立部署的小服务,每个服务开发完成后,我们将其打包成为 Docker 镜像,并编写该服务的 Deployment 描述文件,在这个文件中配置所需的 CPU 资源、内存资源以及期望的服务副本数量等信息。然后通过 kubectl apply 命令将该服务部署到 Kubernetes 中,多个服务实例会被均匀地部署到多个工作节点上。Kubernetes 会定期检查这些服务实例的状态,确保它们按照预设的数量正常运行。如果某个工作节点宕机了,该工作节点上的服务实例会在其他工作节点上重新部署,从而实现了自动故障转移。如果某个服务实例意外停止或崩溃,Kubernetes 将自动创建新的服务实例来确保服务实例数量与预设的数量相符,从而实现了服务自愈。这一过程无需人工干预,有效地保障了系统的稳定性和可靠性。

检错技术

我们采用检错技术确保能够及时发现故障并报警,提醒相关人员进行处理。我们采用了 Prometheus 和 Grafana 搭建了一套实时自动化的监控告警系统,用于监控各个工作节点、服务以及组件的运行状态和关键指标,比如内存使用率、CPU 使用率、磁盘使用率、网络带宽占用、响应时间 TP99、请求错误率等。当检测到异常时,该监控告警系统就会自动触发告警,提醒相关人员处理。提醒的方式主要包括短信和企业微信。通过这种方式,我们可以对系统的健康状况有一个全面的了解,并且可以在问题发生时迅速做出反应。

例如,在一次消费送积分的营销活动中,监控告警系统检测到积分服务的响应时间突然增加,并触发了告警。我们收到告警信息后,通过查看 Grafana 的可视化实时监控图表发现某个工作节点的磁盘使用率达到了 100%,然后我们对该工作节点进行了进一步的排查,发现了问题源头在于该工作节点的磁盘被大量日志文件占满了,这导致积分服务无法正常提供服务。于是我们迅速采取了行动,清理了不必要的日志文件,并优化了日志的存储策略,解决了磁盘空间不足的问题,恢复了积分服务的正常运行。

总结与感悟

通过以上可靠性设计技术的运用,我们有效提高了系统的可靠性,从而确保了业务的连续性。最终,经过 10 个月的研发,该项目于 2023 年 12 月完成并交付上线,至今运行稳定,各项功能和性能指标均达到客户要求,得到了客户和各级领导的一致好评。虽然项目取得了成功,但我们也看到了一些不足之处,其中需求频繁变更导致项目团队经常加班是比较突出的问题。针对这个问题,我们采取了以下两个措施:一是规范需求变更流程,提升变更成本,以避免过度的需求变更;二是通过灵活的配置和架构设计,低成本响应需求变更。

通过该项目的开发,我在系统分析与设计方面积累了不少宝贵的经验,为我后续的工作提供了很大的帮助。这也激励着我不断学习,不断丰富自己的知识体系,为将来能够应对更复杂的工作做好准备。


http://www.kler.cn/a/387116.html

相关文章:

  • JavaScript——函数、事件与BOM对象
  • 100+SCI科研绘图系列教程(R和python)
  • vue2面试题6|[2024-11-11]
  • 速通LoRA:《LoRA: Low-Rank Adaptation of Large Language Models》全文解读
  • kafka夺命连环三十问(16-22)
  • 超详细:三大范式和反范式设计详解
  • Linux: network: ip link M-DOWN的具体含义是什么?
  • 论文阅读--基于MLS点云语义分割和螺栓孔定位的盾构隧道错位检测方法
  • 如何在 Rust 中实现内存安全:与 C/C++ 的对比分析
  • 怎么解决码流多slice场景下的马赛克、绿屏问题?
  • 云原生安全解决方案NeuVector 5.X部署实践
  • 鸿蒙笔记--skills
  • NestJS 项目中如何使用 class-validator 进行数据验证
  • 从认识 VNode VDOM 到实现 mini-vue
  • 【数据结构与算法】第9课—数据结构之二叉树(链式结构)
  • es数据同步(仅供自己参考)
  • 机器学习中的分类:决策树、随机森林及其应用
  • 鸿道Intewell高实时架构:鸿道Intewell-Hyper II 构型
  • c语言宏定义的优缺点及举例说明
  • AscendC从入门到精通系列(二)基于Kernel直调开发AscendC算子
  • Vue禁止打开控制台/前端禁止打开控制台方法/禁用F12/禁用右键
  • 如何设置docker的定时关闭和启动
  • MCU的OTA升级(未完-持续更新)
  • 19. 异常处理
  • 2.4_SSRF服务端请求伪造
  • Docker lmdeploy 快速部署Qwen2.5模型openai接口