从去年年底到现在，随着疫情的反复，很多城市的一码系统都失效了，这证明一码系统在技术上还是存在一些不足，所以本次分享将从架构、设计等方面介绍如何使用PAST问题解决框架来研究和解决这些问题。01PASTProblemSolvingFrameworkPAST中第一个单词P是Problem，代表一个问题。遇到问题时，不要急于进入计划阶段。您应该首先进行研究和分析，以确认问题所在。EricEvans在《领域驱动设计》中也提到了这一点，理解目标领域并将学到的知识融入软件是领域驱动设计（DDD）的首要任务，强调了问题的重要性。第二个字A是Analysis，代表矛盾分析。问题的原因可能有很多。在这个过程中，首先要找出主要矛盾和次要矛盾，然后针对这些原因或矛盾找到相应的解决方案，即S。此时，可以先列出选项，再权衡取舍并且可以在Tradeoff阶段进行权衡。在软件或者架构设计的实践中，大部分时间都是在做权衡，而不是做决定，所以需要在设计中进行权衡，最终制定出方案。根据不同的计划，可能需要顺势而为，在最后阶段对结果进行回顾。02问题下图为某市易兆通系统。假设产地为西虹市，图1（左）为正常情况下的一码制，包括姓名、身份证号和二维码，其中二维码分为绿码、红码或黄色代码。此外，图1下方（左）还包含15天内的疫苗接种信息和核酸检测结果。从图中可以看出，一马通的主入口集成了诸多功能。图1（右）是一通系统周一上午的故障显示页面，显示一通系统空白。此外，还存在核酸检测结果不显示任何信息等问题。■图103分析3.1主要矛盾在分析阶段，需要对这些问题进行调查分析，找出问题产生的原因和矛盾。此时主要是周一早上大量市民需要从不同场合打开易通系统的核酸认证页面，易通系统之间的矛盾无法同时满足大并发。易通系统打不开，导致用户反复刷新，系统用户请求激增。这时候请求可能会直接到达后台甚至服务层，然后进入分布式缓存或者数据库，造成后台服务器流量骤增，网络带宽相应增加。3.2架构分析接下来，进一步分析架构和设计。从数据层面来说，可能没有很好的缓存机制。很多查询请求直接进入服务器甚至数据库，导致缓存崩溃，大量流量被“操蛋”。到数据库。从变更频率弹性来看，单码通系统的问题是个人代码页聚合了太多内容，没有基于容器的集群构建和熔断机制。从CFR跨功能需求来看，问题是开发者在设计服务时没有考虑服务器的峰值限制，在系统测试设计阶段没有进行性能和压力测试，导致系统最终超过加载。网络瓶颈方面，理论上1000M网卡的传输速度为125MB/s，100M网卡的传输速度为12.5MB/s。当天失败的可能性可能是网络带宽不够支持，导致网络流量大。瓶颈。图204解决方案列举分析完成后，需要针对问题制定解决方案。在列举方案的过程中，不要急于表达自己的倾向，应先确定备选方案，并进行排列组合。4.1基于数据分层架构对于数据，可以分为UI层个性数据、缓存数据和DB全量数据。缓存设计遵循就近原则。数据离用户越近，性能可能越好。根据这个原理，基于数据的分层架构实际上是一种漏斗型架构，是一种基于对象和集合的缓存策略，可以减少对底层系统的访问。对于每一层数据，可以采用不同的方法进行处理。UI层个性数据，针对一码系统存在的问题，当用户点击查询核酸结果时，可以禁用按钮，禁止重复提交功能。比如15秒后才能开启，会阻塞stopflow。对于缓存的数据，可以在浏览器中缓存，比如缓存常见的图片、静态文件、脚本等。这可能只需要有限的资源就可以让请求进入相应的后续阶段。此外，还可以利用CDN缓存分发网络。当数据从UI层到达应用层或服务器时，可以使用NGINX或中间服务器作为代理。例如，在服务器端，为经常查询但修改较少的数据创建缓存。对于全量的DB数据，主要关注的应该是存储，而不是复杂的计算。当达到一定流量时，数据库供应商可以支持数据库限流。返回相应的异常码会告诉用户不可用，相应的服务器可以根据情况进行熔断处理，以免数据库一直在处理信息而无法响应，从而导致整个应用程序崩溃。此外，当易通系统当天出现问题时，建立不同的微服务动态弹性扩展核酸报告也是一个不错的选择。划分方法是DDD。■图34.2业务变化的频率和灵活性在开始业务的过程中，或者在一些比较复杂的系统中，可以做一些体验设计，对系统的业务能力进行划分。需要根据上下文和系统业务能力判断是否从单体转为微服务。此外，还必须考虑业务变更的频率和灵活性。比如核酸检测，就是近期使用频率很高的一个功能。放在首页，进入系统后直接查询。事实也证明，西虹市在疫情发生几天后就将核酸检测的功能直接放到了页面上，这也间接说明了业务变更的频率对于系统的设计非常重要。图44.3CFR–测试设计和性能对于CFR，图5显示了指导性测试的四个象限。Q1象限从技术角度支持团队的整个测试，包括单元测试和组件测试，可以帮助团队尽快发现问题。Q2象限支持从业务角度进行团队测试，更侧重于发现功能和业务问题。Q3象限从业务角度对产品进行评估，主要包括一些探索性测试。Q4象限从技术角度对产品进行评估，包括性能测试、压力测试和安全测试。4个象限可以分为质量交付（Q1、Q2、Q3）和运维（Q1、Q2、Q3、Q4）两个准则。随着DevOps的盛行，这四个象限往往结合起来制定有效的测试策略，使测试和开发能够在项目中落地。图5从性能设计的角度来看，在高并发的情况下，比如每秒100个请求，是否应该将100个请求直接放在服务器和数据库上进行100次查询呢？显然不是，解决方案应该是将这些请求合并在一起。请求可以通过时间限制器或定时器的形式进行组合，查询后可以找到对应的API并返回。这实际上是批量查询的一种变体。但是如果请求比较少，就不需要合并请求，需要根据情况配置。还有另一种方法称为限流。这时候可以使用令牌桶算法。令牌桶的容量是固定的，按照一定的速率添加令牌。如果桶已满，则不再添加。.也可以使用漏桶算法。无论当前并发数多少，流量都能保证后台程序接收到的请求数是一定的，可以达到限流的目的。该方法不适用于单码传递系统事件的情况。中间件限流方式是Tomcat使用maxThreads来实现限流，也可以使用NGINX的limit_req_zone和burst来实现限流。NGINX的limit_conn_zone和limit_conn两个命令可以控制并发连接总数。4.4网络瓶颈在网络瓶颈方面，为了防止网络拥塞，可以尝试将访问方式从HTTP改为TCP，比如访问Redis缓存。在这种情况下，使用RESP方法。也可以使用更高级别的网卡，比如DNS负载均衡，让多个IP对应同一个域名。05Tradeoff权衡与权衡制作软件就是要做出权衡。具体来说，前端登陆后，客户端缓存、浏览器缓存、CDN缓存都可以开始运行。首先，访问服务器。这里的服务器包含了对应的NGINX或者负载均衡器。然后流量到达应用层和服务层。如果这个阶段流量很大，可以做多线性能优化或者高性能RPC，也可以加缓存。然后就可以进入微服务框架了。回到缓存部分，数据访问层可能包括Redis等，一些经常访问但不经常更改的数据可以缓存在这里，通过请求合并或查询减少I/O。在存储层，数据库更注重数据的全量。如果数据库压力比较大，可以考虑分库分表。根据不同的数据情况，甚至不同的人、不同的地区也可以建立自己的数据库进行访问。在基础设施方面，系统必须能够支持快速扩展。如果考虑到业务变化的频率灵活性，那么云原生是必不可少的。最后列出一个方案，仅供参考。问答环节1.如何带领和管理初创公司的技术团队？要想带领团队，首先要确定团队的方向，即项目愿景。愿景确定后，就有了目标，再根据实际情况，确认支持这些目标所需的人员技能要求。其次，团队需要提升自己的能力，因为为了完成业务目标，需要相应的能力输出。此外，如果团队成员较多，则必须有团队规范，使公司或项目的战略以过程为导向，以过程工具为导向。对于组织来说，我认为有必要继续学习，尝试从客户的角度去解决它的痛点。2、易通系统的CDN设计原则是什么？一般在配置的时候，需要明确哪些是可以缓存的。例如，不经常访问或频繁更改的数据，可以根据业务数据的情况，放在CDN缓存中。3.如何合并请求？Java中有一些特性函数可以引入到请求中。比如一秒有100个请求。请求引入后，可以分成10份，通过线程池1秒遍历10次。具体可以将请求分别添加到线程池中，然后线程池定时触发调用请求。feature函数使得请求从数据库返回后，可以找到对应的请求。对于这些问题，在JavaSpring中都有比较成熟的解决方案。
