西安一码通又崩了!教你如何设计实现防疫一码通 ...

共 3298字,需浏览 7分钟

 ·

2022-01-11 18:07

「 关注“Java项目精选”,大厂架构经验倾囊相授 


最近西安疫情特别严重,前一阵子还出现了一码通崩溃的事件,网络上对此也有各种各样的评论和说法。对于各种言论和说法我们没有权力去评头论足,但是可以从技术的角度聊一聊,如果是我们接到了这样的需求,应该来如何设计这个系统。使得它可以在关键时刻经得住考验,为防疫工作提供方便做出贡献。


首先我们分析一码通大致有哪些基本需求需要实现,应该会有个人信息登记注册以及修改的需求。还会有个人健康信息查询需求,也就是健康码了。也有个人行程信息记录需求,也就是平时我们进出小区,商场,乘坐公共交通等等的时候扫码操作。应该还有后台修改个人数据的需求,例如更改个人的红绿黄码,个人核酸检测结果等。可以对上面需求做一个如下总结:

  • 个人信息登记注册以及修改:由用户端驱动,既有读操作也有写操作,实时性要求较高,写操作需要立即得到结果,但是并发量不大(毕竟大家同时修改个人信息的概率比较低)。

  • 个人健康信息查询由用户端驱动,只有读操作,实时性要求较高,并发量比较大(大家同时刷健康码的概率非常大,这次崩溃的就是这个服务)。

  • 个人行程信息记录:由用户端驱动,只有写操作,写操作不需要立即得到结果给用户,实时性要求较不高,并发量不大(毕竟疫情期间蜂拥而出情况不多)。

  • 后台修改个人数据:非用户驱动,应该是由后台的 job 或者相关工作人员来驱动的。只有操作发量不大(毕竟非用户驱动的操作还是可控的)。


数据中心

对于这种 mission critical 的系统还是建议从数据中心的角度建立多个 site,每个数据中心的接入点都申请不同的 FQDN 域名,从接入层就利用 DNS 的来分流到多个数据中心。当然这个可以不必那么复杂,不必引入 GTM 把流量基于地理位置分发到不同的地区的数据中心,毕竟大家都在一个地区。



接入层负载均衡以及 CDN

对于每个数据中心的服务来说一定是有负载均衡的,负载均衡基于不同的维度有很多种类。有三四层负载均衡,七层负载均衡,基于应用的负载均衡,基于操作系统内核的负载均衡,还有基于硬件的负载均衡。这个系统在接入层也不需有复杂的负载均衡策略,可以追求速度,所以可以选择更快的三四次负载均衡,或者硬件负载均衡。另外系统一定是有静态资源的,例如图片或者 html/css 等等,这些资源可以完全放在 CDN 来管理,以减轻系统负载,加速静态资源访问。



服务层拆分

根据上面的需求分析,可以根据基本需求的读写特性和并发量从业务上拆分不同的服务。

  • 个人信息登记注册以及修改:读写实时性较高,但是并发量不大,所以这个服务可以直接访问我们的存储 storage。

  • 个人健康信息查询:并发量比较大,这个服务不可以直接访问我们的存储,需要引入缓存来加速访问。

  • 个人行程信息记录:写操作不需要立即得到结果给用户,实时性要求较不高,并发量不大,所以可以引入消息队列 MQ 来加速并解耦这个服务和存储。

  • 后台修改个人数据:和上面的个人行程信息记录一样。

上面的服务层一定需要有快速的动态扩容和发布的能力,所以可以考虑基于当前比较流行的 kunbernetes 平台或者 service mesh 平台。另外对于服务的协议,如果追求速度可以考虑使用二进制的 RPC 协议(例如GRPC)来代替传统的 HTTPS + JSON 格式的协议。



缓存的引入

上面的分析指出,对于只读的,并且流量大的服务,例如个人健康信息查询,我们是一定需要引入分布式缓存的。对于分布式缓存我们可以考虑下面的几点:

  • 缓存容量:西安常住人口大约1200万人,一个人分配10KB的缓存估算,大约就需要120GB,在加上25%的 Buffer,所以需要大约总共150GB的缓存。当然这么大的缓存不可能是单机的,一定是分布式的的,需要利用一些基于缓存数据分片的 sharding 方式把他们均匀的缓存在不同的机器上。

  • 缓存预加载:我们不可以指望通过应用程先查询缓存,没有数据在去存储里取并放到缓存里,这样在并发大的时候依然会有问题。所以需要有缓存的预加载过程,当然我们可以基于数据 sharing 分片的方式去加载,例如可以基于人所属的区域,分不同的批次做,这样也提高效率。

  • 缓存击穿:如果查询一个不存在的对象,例如不存在的缓存 key,那么由于缓存里没有也依然会去访问存储的。所以对于缓存击穿的情况,我们可以给它设置一个短暂的缓存时间,以及一个空的值。

  • 缓存雪崩:当我们设置缓存的时候,如果不注意缓存过期时间,如果在同一时刻大批量的缓存失效,就会有大量的访问同时进入存储。所以我们可以基于数据 sharing 分片设置不同的缓存时间。另外我们还可以有一个缓存续约服务,对于那些没有数据更新的缓存,定期批量的延长缓存时间。当然这个服务也可以数据 sharing 分片提高效率。

  • 缓存同步:有缓存就有缓存同步的问题,我们可以引入缓存同步服务,来定期把有更改的数据批量同步到缓存里。当然这里的数据一定不是哪种实时性要求高的数据,比方说红绿码变更,近期核算检测结构等。对于实时性高的数据,例如个人信息登记和修改,一定是要同时更新存储和缓存的。



存储的引入

对于存储这个块,数据量一定是比较大的,而且根据不同时期的防御政策一定会有不同的动态数据加入,数据结构变化可能比较频繁,所以可以引入 NoSql 来做数据存储。另外不仅仅是存储的问题,一定会有大数据的分析需求,有基于实时性要求比较高的流处理和可以有等待的批处理,以及将数据汇报给国家防疫平台的处理等,这里我们做不展开讨论。微信搜索公众号:程序员开源社区,回复“资源”,获取更多精品学习资料。



监控和预警的引入

对于这种 mission critical 的系统一定需要有完善的监控和预警的引入,需要从不同维度上来对整个系统来监控和预警,如:

  • 基础设施和操作系统维度:也就是我们经常会提到的计算维度的 CPU, 存储维度的 Memory/Disk,网络维度的吞吐量等等。

  • 中间件维度对各种中间件的监控,例如缓存,线程池,连接池,数据库,消息队列,应用服务器,负载均衡器等等。

  • 应用程序维度:应用程序本身的监控,也就是我们常常所说的 APM 这个概念,可以更细节的了解应用本身的运行。


总体架构设计

综合上面分析,high level 的设计可以如下:


另外从一码通的小程序详细信息上也看到一些不是很专业的地方,例如:
  • 莫名其妙的9443端口

  • 莫名其妙的消息

  • 可以看到前端调试信息按钮等

  • 友情提示一下证书还有半年多就要过期了,可以尽快换证书。



当然上面的设计和思路也只是笔者的家之言和浅浅的见解,不一定是最好最合适的方法,也许还有什么纰漏和漏洞,也欢迎大家多多交流,多提意见,一起学习。另外虽然一码通也经历了崩溃事件以及有不专业的地方,但是它毕竟也为这座城市的防疫数字化做出了贡献,也方便了防疫工作和大家,还是这座城市防疫工作中不可缺少的必要工具。希望大家都可以在疫情期间保持身心健康,注意安全,学习到多的东西,也希望疫情早日过去。

PS:如果觉得我的分享不错,欢迎大家随手点赞、在看。

(完)




加我"微信获取一份 最新Java面试题资料

请备注:666不然不通过~


最近好文


1、Kafka 3.0重磅发布,弃用 Java 8 的支持!

2、你只会用 ! = null 判空?嘿嘿!

3、这次,Swagger-ui遇到对手了!

4、一个基于Spring Boot+Vue+Redis的物联网智能家居系统

5、本机号码一键登录原理与应用



最近面试BAT,整理一份面试资料Java面试BAT通关手册,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式:关注公众号并回复 java 领取,更多内容陆续奉上。
你点的每个在看,我都认真当成了喜欢
浏览 34
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报