战“疫”思考|如何快速搭建一个口罩预约系统
2020-03-02 11:00:05 来源: 作者:

由于当前新型冠状病毒疫情形势严峻,口罩成了紧俏商品,多地政府和药店都纷纷推出了口罩预约系统,为市民缓解了“口罩荒“带来的不便,也增强了市民的信心和安全感。然而,因为这类系统大多数是紧急研发部署上线的,有些地方的口罩预约系统在上线初期不可避免地遇到了一些问题,造成了不好的影响。



例如:有的系统一上线就因为访问量过大而瘫痪;有的上线后被吐槽功能不完整或者预约规则不合理;有的因为口罩货源过少难以约到让市民认为是鸡肋;有的预约后要排长队领取让人担心会增加感染风险……



以上这些问题,说明了要搭建部署一个“口罩预约系统”,并不像看上去那么简单。开普云认为,出现问题的原因大致分为四类:

 1、需求分析不够充分

 2、质量控制能力偏弱

 3、系统架构设计不够合理

 4、社会资源整合不够充分


那么,要快速搭建一个口罩预约系统对主办方和开发方有那些考验呢?


1、社会治理和资源整合能力

政府是不生产和销售口罩的,政府主导发布口罩预约系统的主要优势在于它有最强大的资源整合能力。一个口罩预约系统,需要多方配合才能真正运作起来,除了相关的各政府部门外,还必须充分调动相关的社会资源参与,包括药店、供应链、物流平台、运营商、发布渠道等各方面资源。在一些已经“封楼”的地区,还要协调好社区、物业、志愿者服务,毕竟口罩不是虚拟产品,不可能网上申请了就马上有货、就马上能送到申请者手中的。


在设计一个口罩系统过程中,必须充分考虑各种可能的场景需求和应对的解决方案,尽最大努力保证公平和效率,以及如何利用各种资源和数据去实现公平和效率。


2、软件项目开发和管理能力

一个传统的软件系统开发流程,从启动到需求调研,再到设计、开发、测试、上线部署,必须要经过一个周期。但是疫情不等人,早一天发布口罩预约系统,就能早一天为公众提供一份安全保障。



开普云为广东某地市推出的口罩预约系统,采取了敏捷项目管理方法,结合DevOps开发运维模式,从开始设计到上线,仅仅用了不到3天时间。上线之后根据口罩货源变化和预约增长情况快速调整需求,持续发布更新系统,从最初网上预约/药店核销,再加入在线支付/快递上门,并随时根据预约和货源数据分析情况优化预约规则,有效地保障了网上预约口罩工作的顺利推行,保证了口罩快速、便捷、安全地发放到市民手中。



随着“战疫“工作的进一步开展,还有健康申报、电子健康证、疫情线索上报等与口罩预约相关的一批小应用也相续推出。这些应用会使用共同的数据资源,例如人口、住址、健康、流动情况等各方面数据,应用之间也会存在数据使用的交集,例如口罩预约时,可以同时申报个人健康数据等。所以,在设计上一方面要考虑业务组件、技术框架复用,另一方面要考虑如何有效利用数据服务,基于现有的应用和数据中台所提供的能力,快速推出各种抗疫情应用功能。


3、运维保障能力

一个地市的口罩预约系统,从上线开始,就注定要承受巨大的访问压力,系统架构设计应能够在大规模并发之下响应及时,并且支持弹性扩容。



广东某地市口罩预约系统采用Kubernetes技术构建,由15个节点组成集群,包括Kubernetes调度高可用节点,work节点,ingress服务、私有仓库(代码发布),缓存节点,查询节点,持久化数据库节点等,并采取了根据访问量使用HPA进行自动扩容、数据库延时写入、前端分布式缓存等一系列电商级别的部署技术。整套系统使用Prometheus实时监控,运维人员根据监控数据及时预判,提前处理,保证了数百万市民始终能正常使用包括口罩预约在内的应用功能。



并发高峰截图   

系统压力截图   

集群状态截图   


     结    论     

包括口罩预约在内的一系列小应用,虽然看上去功能都似乎很简单,但是“麻雀虽小,五脏俱全”,更是“大平台、小前端”思想的具体体现。在这个疫情形式严峻的非常时期,能否快速推出和部署这样的系统,一方面考验了当地政府的社会治理和资源整合能力,另一方面,对于软件开发方来说,更能体现出平时在业务分析、项目管理、技术架构、质量管控、运维保障等各方面的综合硬实力。


疫情面前,没有旁观者,我们都是命运共同体。开普云愿与您分享更多战“疫”征途中的思考与实践!