接种新冠疫苗后对集群和服务化的思考

Posted 2021-08-21 kumfo

整套思考和想法算是一种灵光乍现，昨天下去去打了第二针疫苗，经历了一整套流程后，发现整套流程规划很有意思，感觉整套流程非常贴合这几年流行的微服务的架构思想．

整套流程可以从里面看到 熔断，限流，消息通知，队列，缓冲区，负载均衡 等等.

全局负载均衡

一个城市，可以打疫苗的人很多，需要打疫苗的时候，就需要预约，或者报名，而一旦预约，就相当于浏览器开始发起了网络请求。而一个城市会有很多的疫苗服务站，对于要打疫苗的人来说，可以选择的地方很多，但是用户是不知道哪些疫苗服务点是空闲的，疫苗服务方可以把用户分配到不同的服务点。而这个过程就是全局负载均衡 了。

全局负载均衡关键的技术是智能DNS，它可以通过多种负载均衡策略来将客户端需要访问的域名解析到不同的数据中心不同的线路上，比如通过IP地理信息数据库解析到最近的线路，或者权衡不同线路的繁忙度解析到空闲的线路等等。

而对于疫苗服务方，就是把用户分发到就近的某个服务点，然后给用户下发可以打疫苗的凭证，告知用户可以去打疫苗了。

入口网关

到达疫苗服务点后，首先会进入入口，入口这里会有几个安保人员，或者说是服务人员，一次来打疫苗的人可能有一个、几个甚至几十个，人少量的时候（当人数少于这些服务人员），会有部分服务人员空闲，人多的时候，会排成队列，对这些人员的疑问进行处理，然后再往后续步骤分发。

这个过程中，服务人员其实充当的是一种网关，对服务进行负载均衡，往空闲位置发送。另外这个过程通常来说，会比较快，然后人员可以安排比较少，对应的就是服务器资源可以给得比较少。

取号

经过入口的处理后，用户就会进入取号阶段，取号的时候，也会安排两个人员进行处理，用户在入口的时候经过处理后，会以队列的形式进入到取号区，入口是解决用户一些疑问和对后续服务再次做负载的，而进去取号阶段就开始正式的后续服务了。取号的过程中会验证凭证，如果没有可以打疫苗的凭证，就会被告知不可以打疫苗，这个过程可以说是一个 拦截器 的过程，对不合理的服务请求进行拦截。

拦截后产生的可以交错 异常,那么就需要对 异常 进行处理，比如告知用户怎么去获取凭证、怎么预约。如果编写成程序，这个过程是需要一个专门的异常处理的，但是由于是人，所以就会很灵活，再取号过程中顺带就会进行异常处理了，会询问用户是哪个社区，然后告知用户怎么处理后续步骤。

全局缓冲区

关于缓冲区的程序概念，这里就不做解释，我们关注一下打疫苗这个过程的缓冲区。经过取号后，用户就会进入缓冲区，缓冲区是一个临时搭建起来的方舱，里面有空调，有椅子，用户可以在这里进行等待。

有了缓冲区之后，用户就可以在缓冲区有序的等待后续的服务，就不会到处乱窜，好管理。对后续的服务也不会造成直接的冲击。

从我所看到的情况来看，这个缓冲区是最大的，也是一个最重要的缓冲区，我把这个叫做“全局缓冲区”，其实从全局上的道理来看，这的确也充当了一个全局的缓冲区。

消息通知

整个疫苗服务过程都充满消息通知，消息通知依靠的是挂在每个服务位置的大喇叭。从程序的设计上来说，消息通知的内容应该是轻量级的内容，足够简单，也足够快。对应到这里的疫苗服务来说，消息的确足够轻量，基本就是：“两千号前请前往疫苗等候室，两千号前请前往疫苗等候室，两千号前请前往疫苗等候室。”。足可见消息的轻量，消息轻量也足够快。另外这里可见说了三遍，这可以算是消息的重试方式，由于是单向消息通信，多次消息可以确保接收消息的服务完全接收到消息。

当然，这里可能也会有人去上厕所了，导致消息漏掉，而对于在缓冲区等候的人可以询问缓冲区服务人员，进行消息确认。而这里的服务人员又充当了异常处理器。

疫苗缓冲区

打疫苗的过程就是一个产生实际服务的过程，疫苗服务在室内。进入室内时候会检查号码凭证，这个号码凭证是在取号的时候拿到的凭证。

另外，从取号的缓冲区收到消息通知的人进入到打疫苗的过程中，还会进入一次缓冲区，不过这个缓冲区容量较小，因为容量小，所以会更快。进入缓冲区等候的时候，这个时候还会接收到一次消息通知，接收到消息通知后满足号数内的用户才能进入打疫苗的流程。

经过门口安保人员验证通过后，进入打疫苗的室内。

队列

队列也是用于处理缓冲的，但是队列更轻量。进入打疫苗的实际流程后，会排队等候服务，比如需要建档的进行建档，需要验证是否是打第二针疫苗的就进行第二针疫苗的验证。如果预约的是一针疫苗服务，那么就会进入一针疫苗的相关流程处理。

多进程处理

打疫苗的过程就是一个多进程处理，对于建档，验证打什么针的过程也是一个多进程的过程，每个过程会有好几个人进行处理。

队列进入多进程的验证流程，通过后，会产生新的队列。而对于验证后推入的队列是同一个，由于每个处理验证、建档的工作人员处理不一致，会产生并发情况，比如两个人同时进入队列，这个过程就会产生类似于锁这样的效应。比如两个人甚至三个人进入队列入口，那么工作人员就会让人员等待，然后再快速安排进入队列。而如果进入队列的用户的确过多，那么此时就会进入一个小的缓冲区，大家可以在这个缓冲区坐一会，或是选择看一会手机，然后等队列空闲再次安排进入队列。

实际打疫苗的过程再从这个队列出队再次进入多进程的处理。这个过程，似乎有些不合理的地方，从道理来看，应该是经过建档、验证这个多线程环节后，直接流入到后续的绑定的打疫苗工作人员就行，就不用再次进入同一个队列，然后后续打疫苗的工作人员再从队列里面取。

但是实际上这个安排具有一定的合理性。首先就是，处理建档、验证的工作人员和实际打疫苗的工作人员不是匹配的，那么进入队列后，统一安排是一个不错的方案，而通常来说，在没有意外的情况下这个队列是足够快的。而对于不够快的情况下，又提供了缓冲区，解决并发和阻塞的问题。

监控、反馈、治理

监控这个就很好理解了，会有专门的工作人员对整套体系进行检查、反馈、协调、信息收集。有了这些东西后，又可以给全局负载均衡提供信息，这样就可以得到尽可能匹配的流量流入。

收集到的各方面信息又可以用于完善整套系统本身，让整套系统的资源得到更好的利用，不会让工作人员达到很累的状态，也不会让某一些工作人员处于很闲的状态。以及对内部产生的问题进行修复、调整。

集群、服务化

从整体来看，一个疫苗服务点其实可以当作一个集群，因为最终的结果就是多个工作人员给需要打疫苗的人员打疫苗，构成了一个打疫苗的集群。

放大了来看，各个疫苗服务点（集群）够成了一整套服务体系。

如果把整套疫苗系统当作一个服务来看待的话，那么各种政务服务系统就构成了整个城市，各个城市服务系统的相互调用就构成了一整套的微服务体系架构。

后记

程序是来源于生活的抽象，有时候，对于生活场景的思考，还是非常有意思的，从生活场景中的思考能加强对抽象的理解，而抽象的思想又能给现实生活事情上的处理提供指导。