共计 3727 个字符，预计需要花费 10 分钟才能阅读完成。
本文内容源自「声网开发者守业讲堂 Vol.02」的演讲分享，分享讲师为 Thoughtworks 专家级咨询师刘勇智。大家能够点击此链接，观看视频回放以及下载讲师 PPT。
从去年年底到当初，随着疫情的重复，很多城市的一码通零碎呈现了故障，这证实一码通零碎在技术上还存在一些有余，所以本次分享将介绍如何利用 PAST 问题解决框架，从架构和设计方面钻研和解决这些问题。
01 PAST 问题解决框架
PAST 的第一个单词 P 是 Problem，代表的是问题。当遇到问题的时候，不要急于进入计划阶段，应该先进行调研和剖析，确认问题到底是什么。这也是 Eric Evans 的《畛域驱动设计》中提到的，了解指标畛域并将所学到的常识融入到软件中是畛域驱动设计（DDD）的首要任务，这强调了问题的重要性。
第二个单词 A 是 Analysis，代表的是剖析矛盾 。导致问题产生的起因可能有多种，在这个过程中要先找出主要矛盾和次要矛盾，而后针对这些起因或者矛盾 找到对应的 Solution，也就是 S。此时，能够先列举计划，而后 在 Tradeoff 阶段进行衡量和取舍。在进行软件或者架构设计的实际中，大多数时候都在做衡量，而不是决策，所以须要对设计进行取舍，最终制订出计划。依据不同的计划，可能要趁势而为，在最初阶段进行功效的 review。
02 Problem 问题
下图为某一城市的一码通零碎。假如产生地为西虹市，图 1（左）是失常状况下的一码通零碎，蕴含姓名、证件号和二维码，其中二维码分为绿码、红码或者黄码。另外，图 1（左）的下方还蕴含疫苗接种信息以及 15 天内的核酸检测后果。由图可知，一码通的主入口集成了泛滥的性能。图 1（右）为周一晚上一码通零碎的故障显示页面，显示一码通零碎空白，此外，还呈现了核酸检测后果不显示任何信息等问题。
■图 1
03 Analysis 剖析
3.1 主要矛盾
在分析阶段须要针对这些问题尝试进行考察和剖析，找到问题的起因和矛盾。此时次要是大量市民须要在周一早上从不同场合关上一码通零碎的核酸证实页面，与一码通零碎不能同时满足大并发量之间的矛盾。一码通零碎无奈关上，导致用户重复刷新，零碎用户申请飙增。此时，申请可能间接达到后盾甚至服务层，进而进入分布式 cache 或者数据库，这造成 后盾服务器的流量突增，对应的网络带宽减少。
3.2 架构剖析
接下来进一步剖析架构和设计，从数据层面来说，可能没有造成很好的缓存机制，很多查问申请都间接进入服务器甚⾄数据库，造成了缓存的击穿，很多流量被“怼”到了数据库。从变动频率弹性来说，一码通零碎的问题在于，个⼈码页⾯聚合了太多的内容，没有基于容器的集群搭建和熔断机制 。从 CFR 跨性能需要来说，问题在于， 开发人员在进行服务设计时没有思考服务器的峰值限度，在零碎测试设计阶段没有做好性能和压⼒测试，导致系统最终超过了负荷。从⽹络瓶颈来说，实践上来说 1000M ⽹卡的传输速度是 125MB/s，100M ⽹卡的传输速度是 12.5MB/s，在当天呈现故障的违心可能是网络带宽不够撑持，导致网络上的瓶颈。
■图 2
04 Solution 计划枚举
实现剖析之后须要制订问题解决方案，在计划枚举过程中，不要焦急表白本人的偏向，应该先确定备选计划，并对其进行排列和组合。
4.1 基于数据分层架构
针对数据来说，能够分为 UI 层共性数据、缓存数据和 DB 全量数据。缓存设计遵循就近准则，数据离用户越近越好，这样性能可能就越好。依照这种准则，基于数据的分层架构实际上是一种漏斗型架构，它是以对象和汇合为单位的一种缓存策略，可能缩小对上层零碎的拜访。针对每一层数据，能够采纳不同的办法进行解决。
对于 UI 层共性数据，就一码通零碎呈现的问题而言，当用户点击查问核酸后果时，能够令按钮不可用，从性能上禁止反复提交，比方设置 15 秒当前能力关上，这样就会阻断流量。对于缓存数据，能够在浏览器进行缓存，比方把常见的图片、动态文件、脚本缓存起来，这可能只须要无限的资源就能够让申请进入对应的后续阶段。此外，还能够利用 CDN 缓存散发网络。数据从 UI 层达到应用层或者服务端，能够采纳 NGINX 或者两头服务器进行代理，比方在服务器端为频繁查问，但批改较少的数据建设缓存。
对于 DB 全量数据，次要应专一于存储，而不是进行简单的运算。数据库厂商能够反对数据库限流，当达到肯定的流量时。返回对应的异样码会通知用户不可用，对应的服务端依据状况能够进行熔断解决，而不至于让数据库始终解决信息而不能响应，进而导致整个利用解体。另外，在当天一码通零碎呈现问题的时候，建设不同的微服务对核酸报告进行动静的弹性扩容是一个不错的抉择，划分伎俩就是 DDD。
■图 3
4.2 业务变动频率和弹性
在守业过程中或在一些比较复杂的零碎中，能够做一些体验设计，对系统业务能力进行划分。要基于上下文，依据零碎业务能力判断是否从单体转为微服务。另外，还要思考业务变动频率和弹性，比方核酸检测是近期应用十分频繁的性能，将其放至主页，进入零碎后能够间接查问。事实也证实，过后西虹市在疫情呈现几天后就把核酸检测这个性能间接放到页面上，这间接阐明了业务变动频率对系统的设计是很重要的。
■图 4
4.3 CFR – 测试设计与性能
针对 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 对应同⼀个域名。
05 Tradeoff 衡量和取舍
做软件就是做衡量。具体来说，前端落地后，客户端缓存、浏览器缓存、CDN 缓存等都能够开始运行，首先拜访服务器，这里的服务器蕴含对应的 NGINX 或者负载均衡器，流量接下来达到应用层和服务层，如果此阶段流量较大，能够多线进行性能优化或者高性能的 RPC，也能够增加缓存。而后能够进入微服务框架。
回到缓存局部，数据拜访层可能蕴含 Redis 等，一些频繁拜访但不常常变的数据就能够缓存到这里，通过申请合并或者查问缩小 I/O。在存储层，数据库比拟重视全量数据，如果数据库压力比拟大，能够思考分库和分表。依据不同的数据状况，甚至不同的人、不同的区，都能够建设本人的数据库来进行拜访。从基础设施来说，零碎要可能反对疾速的扩容，如果把业务变动频率弹性思考进去，那么云原生是不可短少的。最初列出一个计划仅供参考。
答疑环节
1、如何率领和治理初创企业的技术团队？
要想率领团队，首先应该确定团队的方向，也就是我的项目愿景。确定愿景之后才有了指标，而后依据理论状况，确认撑持这些指标实现所须要的人员技能要求。其次，团队要进行能力晋升，因为要实现业务指标，须要对应的能力输入。另外，如果团队人员比拟多，还要有团队标准，使公司或者我的项目的策略流程化，流程工具化。对于组织来说，我认为还要进行不停的学习尝试，应该从客户的角度来解决其痛点。
2、一码通零碎的 CDN 设计有什么准则？
个别状况下，在配置的时候，要明确有哪些是可能缓存起来的。比方，能够把不常常拜访也不常常变动的数据放到 CDN 缓存中，具体要依据业务数据的状况来决定。
3、申请如何合并？
在 Java 中有 feature 性能能够引入申请。比方，1 秒钟有 100 个申请，引入申请之后能够将其分为 10 份，通过线程池一秒内遍历 10 次。具体能够把申请别离增加至线程池中，而后线程池定时触发调用申请。feature 性能使申请从数据库返回之后，可能找到对应的 request。对于这些问题，JavaSpring 中曾经有比拟成熟的计划。