在冷风中我凌乱了半小时，只因健康码刷不出来

聊聊小背景

前几天的早晨我早写字楼门口干等了半小时，背后的缘由居然是健康码的二维码刷不出来，保安小哥还一直跟我讲，支付宝出不来你用微信啊，用微信啊。。

他们用的相同的接口，我用微信有卵用啊，冷风中我甩了甩仅有的几根秀发，扬长而去。。。

做为程序员的我就开始了心里的吐槽大会：这咋作的啊，不行呀，这就打不开了，确定没作优化，确定没用缓存，确定没作压力测试。。。。。

下面做为技术的视角来分析下这个场景的实现，以及能够怎么去优化。这只是我YY哈，真实场景别人是怎么实现的我也不清楚哈。

需求剖析

每一个人都有一个对应的健康码，健康码分为几种颜色，也就对应了几个状态。本质上就是经过健康码的颜色可否区分这个用户是否去太高风险地址。

首先第一个问题就是须要根据多维度的数据去计算出这个码的颜色，好比根据用户的行动轨迹去分析。至于实际上有哪些维度我也不知道，大概猜想行动轨迹确定是其中一点。

大概的存储也很简单，就是userId code等字段，这个场景若是须要历史数据能够单独归档便可，只留最近一天的数据提供查询便可。

实现剖析

最简单的方案就是每次查询实时去分析，这样结果的真实性更高，不足点在于体验不是很好，若是逻辑多的话确定是没法在1s内给用户响应的，因此在上面分析的时候咱们设计了一张表进行存储，确定是提早计算好的，好比一天一次，半天一次之类的形式。

那咱们基于已经有表的形式去作分析，这个业务场景就是很典型的读多写（凌晨写）少的场景。若是不作任何改动，每次请求直接查询表直接响应便可。在高并发场景下只能依赖数据库的并发能力来扛住这些请求，很容易出现系统挂掉，响应慢的状况，也就是为何我在门口等了半小时的缘由。

增长缓存

最好的方式就是加缓存了，直接将码的内容缓存起来，前端根据内容生成健康码便可。首先这种场景不能再查询以后加缓存，由于大部分人的监控码可能也就早晨进公司的时候用一次，因此不适合查询后再写缓存的操做。

须要在凌晨计算每一个人健康码的时候，同时将数据写一份到缓存中，固然这个能够根据平时的访问的数据进行分析，哪部分人天天都会用到，只预先缓存这一部分人的便可。

缓存后，基本上90%的请求都能命中缓存了，由于天天上班的这部分人基本上不会有太大的变化。剩下的请求用数据库去扛，若是仍是扛不住能够加大缓存存储量，用空间换时间。或者数据库多搞几个从节点便可。

内外部隔离

在架构设计中，隔离也是很是重要的一环。隔离的做用就是为了在出问题的时候将故障范围下降到最小。

这健康码的这个场景中，首先健康码本身有一个专属的APP，在支付宝刷不出来的时候我特地用它本身的APP去试了一下，一样也是打不开。

也就是说查询健康码是一个独立的服务，这个服务可能会被内部的产品，好比APP调用，也有可能会经过Open API暴露给外部渠道调用，好比支付宝。

这个健康码须要作什么隔离？

• 数据库隔离

能够独立出一个或多个从节点给对应的服务进行隔离，好比内部服务用库1，外部服务用库2，相互不影响。

• 服务隔离

库隔离了不能解决根据问题，服务还得隔离。区份内部服务，外部服务。Open API只链接外部服务，内部的网关只链接内部服务。

• 调用方限流

针对不一样的调用方作不一样的限制，内部服务容许80%的量均可以知足。外部服务20%的量能够知足。这样在压力大的状况下，本身内部的产品是影响最小的。也就是你在支付宝可能打不开健康码，在我本身的APP能够打开。

不过这种仍是得根据实际场景去分析，像健康码这种场景，也许外部的访问量远远超过了内部的量，由于大部分人可能都是用支付宝，微信啊去打开。因此能够根据实际场景去限制流量。

关于做者：尹吉欢，简单的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》做者, 公众号猿天地发起人。