昨天上午和高校、电网产业单位的专家一起讨论一个十分高深的课题《可成长软件理论在电力行业的应用》，这是人工智能中的一个高端领域，也就是软件自动编码，说白一点，就是人工智能自己编程序来提升自己的智能。我当时开玩笑说，这个领域成熟了，那黑客帝国的场景早晚会出现了。
当时我和高校的专家分享了一些电力行业用户对高校合作的看法。其中最为负面的看法是，高校的理论水平确实高，不过因为高校的专家不能很好的理解电网业务，甚至有些团队不屑于理解业务，导致合作更多的注重理论研究，实际落地效果不佳。
其实不仅是做高端的理论研究，对于架构设计来说也是如此，一个不能很好的理解业务的架构师，可能可以设计出十分高大上的架构，但是很难设计出符合客户业务需求及相关的投资、预算、研发能力的系统架构来。研发团队因为研发能力不足导致无法贯彻架构师的意图，并不是研发团队单方面的责任，这也是架构师不接地气的表现。
昨天我写的关于西安一码通的文章阅读量很大，这也让我感到有点意外，这一千多文字是因为上午有这个研讨会，所以早上起来后在家里的餐桌上码出来的，写之前根本就没想好要写点啥，打开电脑的瞬间想起早上起床后看到朋友发来的一篇文章，才决定以此为题材，写一个关于预案的文章。
后来有朋友给我留言，认为王卫对的思路是错的，应该从加固信息系统的角度去做强调而不是退缩了，去搞人工操作来应对灾难场景。我想这位兄弟可能把信息系统和企业业务想的太简单了，天底下没有不停服的信息系统，在工业商业界并不是所有的问题都是IT可以搞定的，王卫的务实是在对当时企业的信息化能力的正确评估的基础上做出的。要提升这个能力是需要人才，财力，业务流程优化三方面共同发展才能实现的，需要数年时间，而再次出现类似问题很可能就在明天。
昨天公众号上的留言很多，也有朋友和我探讨我提出的预案的可行性。不过他们提出的一些问题我总觉得都是从信息化角度去考虑的，不管是微服务还是互联网模式，都是没有经过和具体的业务碰撞的产物。
于是我也把自己当成一个架构师，来考虑核酸普遍筛查业务系统的架构该如何设计。首先从业务角度上讲，信息化是为了帮助核酸筛查业务执行时，建立试剂盒和使用这个试剂盒采样的人群之间的关系，并当检验结果出来后能够很快把结果和这些人进行关联。
大家往往容易忽视的是，核酸普筛业务和核酸检测业务的不同，普筛业务其实只要重点关注阳性检查样本与相关人员之间的关系就可以了。对于阴性的样本完全可以做简化处理。如果用核酸检测业务的模式去设计普筛业务，把核酸普筛看作是普通核酸检测业务的规模化肯定是不对的。
基于业务需求，这个APP首先要解决的是如何构建这种数据关联的问题。试剂盒上的二维码标签可以唯一的确定这盒试剂，检验时也是通过这个二维码标签的内容作为纽带来建立结果与相关人的关系的。这个二维码标签可以通过手机APP十分精准的读取并登记在APP的本地数据区里。那么我们在做核酸普筛时首先会在一个通道上分发这个试剂盒，同一通道上的数人共用一个试剂盒。分发时扫描二维码，以后所有这条通道上后续使用这个试剂盒的人的身份证号码都需要被采集，并和这个编码建立关联。
如何采集这些人的身份证号码呢？实际上在这个环节我们需要的是一个低成本的快速的数据输入，广东的粤核酸是可以参考的比较好的实现模式。每个受检人员只要扫一次小程序二维码，个人就可以输入自己的信息：姓名，身份证号码，手机号码，然后到服务器上做一次验证，拿到一个令牌就可以完成个人信息验证工作了。此时这些信息和令牌一起通过一种加密的方法存储在用户的手机里。这个工作不需要大家一起做，每个人只要做一次就可以了。
每个人的手机里准备好这些数据后，如果需要检测核酸的时候，就拿出手机，出示这个二维码给防疫人员扫描就可以了，走过通道的时候，防疫人员的手机扫描二维码后就可以获得这个人的姓名，身份证号码，手机号等信息，和前面扫描获得的试剂瓶的编号编成一组，等这一瓶的人员信息采集完毕后一次性打包压缩上传就可以了。真正做核酸的时候，系统的并发量并不是参加筛查的人口的数量（受检者只需根据本地数据生成合法的二维码，不需要访问服务器），而是拿着手机扫描的工作人员的数量，这种并发量肯定是可控的。
当然为了确保信息的正确性，这个用户信息并不能永久有效，需要定期去服务器上做重新认证，可以规定半个月内要做一次重新认证，此时只需要通过一个接口去更新一下凭证的有效性，增加租期就可以了。这部分操作，基本上访问一下redis之类的内存数据库就可以完成。复杂点的还可以搞一个布鲁姆过滤器，进一步提高性能，具体技术问题我就不细说了，有的是架构方面的专家可以搞出比我牛数倍的方法来。如果服务器并发量太大，可以临时延长凭证的有效期，暂时让用户先使用二维码采集身份证信息，等系统不忙的时候进行验证后发送新的凭证租期到用户手机。通过这样的改造，我想做核酸检测时候，服务器端的负载应该小很多，哪怕我们的开发商并没有任何互联网应用的研发经验，用传统架构去开发这个系统，应该难度也不大了。从上面的描述可以看出，一个系统架构的设计是通过对业务的充分理解后的针对性的设计，这样设计出来的系统是高效和便于开发的。
至于我说的那个备胎方案，实际上也是相当简单的。如果我们能够事先考虑到一次筛查中，只有少量人口是阳性，大多数是阴性的，那么哪怕是信息化程度相对较低的临时性方案，也是很容易实现的，因为我们的目标是在第一时间抓住那些检测阳性的样本，对于阴性样本可以极简处理，甚至处理不过来时候可以暂不处理。
当然最好的备用方案是和主方案租用不同的云服务，如果主方案选的是天翼云，那么备用方案可以选择阿里云华为云之类的。检测时，只要手机装一个APP，能够扫描识别试剂盒上的编码，然后把和这个试剂盒同一组的所有人员的身份证号码拍张照片，关联保存在一起。当时也可以做离线的身份证号码识别，也可以不用。如果网络通，这些信息直接上传到服务器上，如果不通，可以在手机上暂存。
核酸检测后，如果发现某个试剂盒阳性，则找到这个试剂盒相关的人的身份证照片，这时候人眼识别还是电脑识别都不重要了。每天出现的阳性人数总是有限的。
对于检测阴性的人员的数据，如果也要输入系统，则可以今后通过一个批量识别程序慢慢的扫描识别，识别后把身份证号码收集齐了批量上传到系统中，设定为参与检测并为阴性。这些人和试剂盒之间的关系啥的根本就不重要了，因为我们的目的是做筛查，而不是为每个人出一份核酸检测报告，事实上大规模筛查和重点筛查大部分是不出单独的报告的。这种实现方式只需要和一码通系统做几个接口就可以搞定这件事，我想疫情当前，研发人员加个班，搞出来的天数都是有限的。
如果你真正的理解了业务，那么根据业务去设计架构应该是很简单的，什么微服务动态扩展，领域建模，对这样简单清晰的业务逻辑也真的不需要。传统架构的数据库+内存缓冲+负载均衡搞定每秒数万笔系统访问问题都不大，这就可以解决每秒几十万人的检测需求了。
我们搞信息化的，总是喜欢根据自己的IT惯性去设计系统，而不愿意先去倾听业务，分析业务逻辑，再去针对性的设计合理的架构，这总会让我们陷入误区。实际上之前和不少建设类似应用的人员沟通过这方面的业务架构，发现他们的方案都是从每秒要检测多少人去推算系统需要多大的并发处理能力，需要怎么样动态扩展以节约资源，而没有意识到先优化好业务逻辑，再去设计架构，可能可以省更多的钱。
