前几天的早晨我早写字楼门口干等了半小时，背后的原因竟然是健康码的二维码刷不出来，保安小哥还一直跟我讲，支付宝出不来你用微信啊，用微信啊。。
他们用的相同的接口，我用微信有卵用啊，冷风中我甩了甩仅有的几根秀发，扬长而去。。。
作为程序员的我就开始了内心的吐槽大会：这咋做的啊，不行呀，这就打不开了，肯定没做优化，肯定没用缓存，肯定没做压力测试。。。。。
下面作为技术的视角来分析下这个场景的实现，以及可以怎么去优化。这只是我YY哈，真实场景别人是怎么实现的我也不清楚哈。
需求剖析每个人都有一个对应的健康码，健康码分为几种颜色，也就对应了几个状态。本质上就是通过健康码的颜色能否区分这个用户是否去过高风险地址。
首先第一个问题就是需要根据多维度的数据去计算出这个码的颜色，比如根据用户的行动轨迹去分析。至于实际上有哪些维度我也不知道，大概猜测行动轨迹肯定是其中一点。
大概的存储也很简单，就是userId code等字段，这个场景如果需要历史数据可以单独归档即可，只留最近一天的数据提供查询即可。
实现剖析最简单的方案就是每次查询实时去分析，这样结果的真实性更高，不足点在于体验不是很好，如果逻辑多的话肯定是无法在1s内给用户响应的，所以在上面分析的时候我们设计了一张表进行存储，肯定是提前计算好的，比如一天一次，半天一次之类的形式。
那我们基于已经有表的形式去做分析，这个业务场景就是很典型的读多写（凌晨写）少的场景。如果不做任何改动，每次请求直接查询表直接响应即可。在高并发场景下只能依赖数据库的并发能力来扛住这些请求，很容易出现系统挂掉，响应慢的情况，也就是为什么我在门口等了半小时的原因。
增加缓存最好的方式就是加缓存了，直接将码的内容缓存起来，前端根据内容生成健康码即可。首先这种场景不能再查询之后加缓存，因为大部分人的监控码可能也就早晨进公司的时候用一次，所以不适合查询后再写缓存的操作。
需要在凌晨计算每个人健康码的时候，同时将数据写一份到缓存中，当然这个可以根据平时的访问的数据进行分析，哪部分人每天都会用到，只预先缓存这一部分人的即可。
缓存后，基本上90%的请求都能命中缓存了，因为每天上班的这部分人基本上不会有太大的变化。剩下的请求用数据库去扛，如果还是扛不住可以加大缓存存储量，用空间换时间。或者数据库多搞几个从节点即可。
内外部隔离在架构设计中，隔离也是非常重要的一环。隔离的作用就是为了在出问题的时候将故障范围降低到最小。
这健康码的这个场景中，首先健康码自己有一个专属的APP，在支付宝刷不出来的时候我特意用它自己的APP去试了一下，同样也是打不开。
也就是说查询健康码是一个独立的服务，这个服务可能会被内部的产品，比如APP调用，也有可能会通过Open API暴露给外部渠道调用，比如支付宝。
这个健康码需要做什么隔离？
数据库隔离
可以独立出一个或多个从节点给对应的服务进行隔离，比如内部服务用库1，外部服务用库2，相互不影响。
服务隔离
库隔离了不能解决根据问题，服务还得隔离。区分内部服务，外部服务。Open API只连接外部服务，内部的网关只连接内部服务。
调用方限流
针对不同的调用方做不同的限制，内部服务允许80%的量都可以满足。外部服务20%的量可以满足。这样在压力大的情况下，自己内部的产品是影响最小的。也就是你在支付宝可能打不开健康码，在我自己的APP可以打开。
不过这种还是得根据实际场景去分析，像健康码这种场景，也许外部的访问量远远超过了内部的量，因为大部分人可能都是用支付宝，微信啊去打开。所以可以根据实际场景去限制流量。
关于作者：尹吉欢，简单的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》作者, 公众号猿天地发起人。