1背景在武术中，“天下功夫出少林”是指中国所有的武术都与少林武术有一定的关系，其技术是少林武术。相同。技术最终体现在计算机知识的基本技能上。这些基本功就是技术的易筋经和“内功”。一些年轻的攻城狮更热衷于追逐高大上的框架。以前炒SSH，现在炒SpringCloud，对框架的掌握程度体现在“刀法”上。我建议每一位技术研发人员在修炼内功的基础上修炼“刀法”。回顾IT行业的发展，先有传统行业，后有互联网。传统产业和互联网是少林和武当的关系。他们的技术相互补充。他们有自己的重点。传统行业更倾向于企业级发展。项目具有业务复杂、流程丰富、集中管理、企业级抽象程度高、业务复用率高等特点，而互联网则倾向于开展复杂的业务。拆分为单一职责，并极大优化单一职责模块的非功能性质量，包括高可用、高性能、可扩展性、可扩展性、安全性、稳定性、可维护性、健壮性等。本文提供了互联网技术的基本方法论审查。主要探讨互联网行业如何在完成产品功能的前提下，更好地满足非功能性质量的要求。这是所有架构师都应该掌握的基本技能。这篇文章的目的是为刚接触互联网或者有意愿进入互联网的研发人员做一个介绍。如果想全面了解互联网非功能性质量设计的方方面面，可以参考美国互联网方法论ArchitectureTradeoffAnalysisMethod。2目标2.1非功能质量要求概述参考技术评审指标，确保系统架构设计满足用户和系统对非功能质量的要求：核心非功能质量：其他非功能质量：2.2具体指标非功能性质量需求要点分为4个部分：应用服务器、数据库、缓存和消息队列。2.2.1应用服务器应用服务器是服务的入口，请求流量从这里进入系统。数据库、缓存和消息队列的访问量取决于应用服务器的访问量。评估应用服务器的访问量非常重要。应用服务器主要关注的是每秒请求的峰值、请求响应时间等指标，通过这些指标可以评估需要多少应用服务器资源。充分考虑以下指标：2.2.2数据库根据应用层的访问量和峰值，计算出所需数据库资源的QPS、TPS、日数据量，从而评估所需的数量和配置数据库资源。部署结构等综合考虑以下指标：2.2.3缓存根据应用层访问量和访问峰值，评估热点数据占比计算出的缓存资源大小，访问缓存峰值resources用于计算所需的缓存资源。数量和配置、部署结构等综合考虑以下指标：序号/指标分类、部署结构容量和性能、其他1、复制模型缓存内容大小、冷热比例data,2.failover缓存内容的数量，是否可以缓存穿透。3.缓存内容过期时间是否大Object4淘汰策略缓存数据结构是否使用缓存实现分布式锁5线程模型每秒读取峰值是否使用支持缓存的脚本6预热方式写入峰值persecond是否避免RaceCondition7FragmentationHashstrategy缓存分片方式（Clients,agents,clusters）2.2.4消息队列计算消息队列需要传递的数据内容和数据量，计算的消息队列个数和配置根据应用层的访问量和峰值，资源、部署结构等。综合考虑以下指标：3.技术审查大纲业务项目差异较大。没有统一的方法论来完成架构设计和技术审查。架构设计只需要从某些关键点来表达系统。大纲是用来帮助大家做architecturereview的工具，是帮助大家梳理思路，形成可实施方案的工具。因此，在进行系统设计时，可以根据业务特点，有选择地参考这个大纲，完成一个可实现的、有效的架构设计。3.1现状项目名称业务背景业务描述技术背景架构描述当前系统容量（系统调用平均值）当前系统调用峰值3.2需求业务需求待改造内容新需求待实现性能需求系统容量预估（Estimatedsystem调用量的平均值)系统调用量峰值的预估其他非功能性质量，如：安全性、可扩展性等表、扩展、归档等。详细解释计划的具体描述。如果文字描述不清楚，可以用图的形式解释（任何图：UML、概念图、框图等）。如果是改造方案最突出的变化，下面列出几个描述角度：中间件架构（应用服务器、数据库、缓存、消息队列等）逻辑架构（模块划分、模块通信、信息流、时序等）.)数据架构（数据结构、数据分布、拆分策略、缓存策略、读写分离策略、查询策略、数据一致性策略）异常处理、容灾策略、灰度发布性能评估给出方案的基准数据，以及根据性能要求评估要使用的资源数量。单机并发和单机容量是基于预估的性能需求和预估的资源数量（应用服务器、缓存、存储、队列等）。“风险”的描述是要量化的。方案2整个方案需要参考技术评审指标提出的各项指标来考虑满足系统的非功能性质量要求。......3.4方案比较和备选方案比较，并给出选择该方案的理由，选择首选方案，3.5风险评估识别所选方案的风险，并提出应对策略以解决该风险时出现，如：上线失败时的回滚策略。3.6工作量评估描述使用所选解决方案时需要完成的具体工作，评估开发、测试等详细任务所需的时间，形成可实施的任务进度表。任务计划表建议采用简单的形式，以减少工具的使用和学习成本。4绩效与能力评价经典案例4.1背景物流系统包括以下两个质量优先级需求：维护会员常用地址，下单时提供会员地址列表。下订单时异步生成物流订单。物流系统后台任务依次从第三方物流拉取物流状态。已下单的用户查询该订单的物流单及物流记录。由于会员多，可能会有更快的增长速度，订单量就更大了。促销期间的高峰订单生成可能非常高。这两个业务模块的数据存储需要分库分表，并借助消息队列和Cache反读写流量，因此本方案主要涉及这两个服务的容量评估。4.2目标数据量级选取行业一线电商平台量级为目标：会员数量2亿，平均每天增加5万。平时订单量400万/天，所有订单的下单时间集中在9:00-23:00之间，促销日订单量1400万/天，50%的订单时间集中在9:00-23:00之间晚上7:30-8:30和晚上22:00-23:00。4.3量级评价标准一般标准容量按5倍峰值冗余计算。会员常用地址容量按30年计算，物流订单时效按3年计算。第三方查询接口5000QPS。Mysql单口读：1000QPS单口写：700TPS单表容量：5000万Redis单口读：40000QPS单口写：40000TPS单口内存容量：32GKafka单机读：30000QPS单机写：5000TPS应用服务器每秒请求量峰值：5000QPS4.4解决方案1.***性能方案由于整个电商网站刚刚上线，数据量级无法明确。我们基于行业内知名电商企业目前的数据量高阶设计了最佳性能方案，该方案可以应对行业内电商巨头各种促销带来的服务请求高峰，并以最快的响应时间达到最佳的服务性能。需求1、会员常用地址的整体流程：提供Restful服务，增加会员常用地址。提供一个Restful服务，获取会员常用地址列表。数据库资源评价：读取QPS：会员每次下单，会员地址列表拉取一次。按照每天1400万的促销日订单量，50%的订单时间集中在两小时内：（1400万×0.5）/（2×60×60）=1000/sec容量评估按5计算倍冗余，读取QPS峰值1000/sec*5=5000/sec，读取需要5口数据库服务。写TPS：假设每天增加的所有会员添加一次公共地址，20%的会员在高峰期下单时会添加一个公共地址：（1400万×0.2+5万）/（2×60×60)=400/sec容量评估是按5倍冗余计算的，400/sec*5=2000/sec，需要3端口数据库服务写入。数据容量：现有会员2亿，每天新增会员5万。平均每个成员有5个共同地址。30年会员公用地址表数量计算：（2亿+5万×365×30年）×5=35亿容量评估按5倍冗余计算，35亿*5=175亿,这需要350张桌子才能容纳。根据上面读QPS和写TPS的评估，如果读写混合，我们一共需要8个端口，可以使用8主8备。如果读写分离，我们需要做主从部署，需要3主6从。4主8从就够了。根据表容量，需要350张表，对齐索引2，选择512张表。以上计算要求主库端口为4，考虑到以后端口扩展不需要分库，尽量多设计库，使用32库。.设计结果：4端口×32库×4表4主8从缓存资源评价：为了提升用户下单的体验，需要使用Redis缓存活跃用户的常用地址。定义当天下单的会员为活跃会员，活跃会员地址24小时缓存。假设每天下单的会员都是不同的会员，每个会员有5个共同地址。缓存大小计算如下：1400万×5×1k=70G容量评估按5倍冗余计算，70G×5=350G，按每个Redis32G内存计算，需要11台机器，根据数据库的设计数据访问QPS/TPS，11台机器完全可以满足5000/秒的读QPS和2000/秒的写TPS。设计结果：11、主从应用服务器资源评估：根据数据库读QPS（5000/s）和写TPS（2000/s）的峰值计算，单应用服务器就够了，选择2避免一个点。设计结果：2套需求2.物流订单及物流记录的整体流程：订单提交后，通过消息队列生成物流订单，并将消息传递给物流系统。物流系统消费物流订单消息，入库。后台任务轮转未完成的物流订单，查询第三方物流接口状态，填写物流记录信息。按照每天1400万单，订单平均3天到，第三方查询接口5000QPS。每次状态查询所需时间计算如下：1400万×3/5000=8400/60/60=2小时，定时任务为2小时查看。提供REST服务获取物流订单信息。提供REST服务获取物流记录信息。提供REST服务获取物流订单和物流记录信息。数据库资源评价：阅读QPS：会员三天内下单，三天内50%的客户会查询物流订单和物流记录。计算如下：（1400万×3×0.5）/（24×60×60）=250次/秒容量评估是按5倍冗余计算的，2×250次/秒×5次=2500次/秒，即需要3端口数据库服务读取。写TPS：会员每次下单，都会生成一个物流单。按照每日促销订单量1400万/天，50%的下单时间集中在两小时内：（1400万×0.5）/（2×60×60）=1000/秒按照每天1400万订单，订单平均3天到达，每个物流订单生成8条物流记录，三天内平均生成8条物流记录。物流记录的TPS计算如下：1400万×3×8/3/(24×60×60)=1200/sec容量评估按5倍冗余计算，(1000/sec+1200/sec)*5=11000/sec，写入需要15口数据库服务。数据容量：目前累计2亿个物流订单，每天新增400万个订单。30年订单数计算：2亿+400万×365天×3年=46亿。容量评估按照5倍冗余计算，46亿*5=230亿，需要460张表来容纳，物流记录表是物流订单的8倍，460×8=3680张表。根据上面的读QPS和写TPS，如果读写混合，我们一共需要18个端口，18个master，18个backup。如果读写分离，我们需要16个master和16个slave。根据表容量，需要3680张表，对齐索引2，选择4096张表。上面的计算需要主库的端口为16，考虑到以后端口扩展不需要拆分库，尽量多设计库，使用32库。.设计结果：16端口×32库×8表，16主16从消息队列资源评价：为了使系统能够应对突增的峰值，使用消息队列Kafka接收物流订单。根据上面写TPS的计算，考虑5倍冗余后，峰值为5000/s，单Kafka单处理器即可处理。如果峰值突然增加，可以增加Kafaka集群的节点来抵抗写流量，处理器根据后端存储的性能来定。比如写入峰值提升10倍到每秒5万条，需要10个Kafka。每个Kafka最多可以读取QPS30000。理论上，需要两个处理器。但是处理器的瓶颈是后端存储的写入TPS，根据上面的计算，写入仓库的峰值TPS是按照5000/秒设计的。因此，单个处理器就足够了。这种场景下，消息会堆积起来，但最终会被处理，达到消峰的效果。设计结果：1个Kafka，主从，1个处理器应用服务器资源评估：根据数据库读QPS（2500/s）和写TPS（11000/s）峰值，3台应用服务器足够。用于查询第三方接口的后台任务服务器受限于第三方接口的QPS为5000/s。一台机器就够了。为了避免单点，两个处理器就够了。设计结果：2套方案2.极简资源方案由于当前系统在线数据量不大，增长也不大，单机完全可以搞定读QPS和写TPS，暂时不考虑使用缓存和消息队列，但是保留了使用缓存和消息队列的接口，如果缓存和消息队列的资源可用，可以通过开关切换。当前的数据量可以用单个数据库和单个表来处理。但是考虑到以后扩展方便，暂时使用了一个数据库端口，但是保留了我们最佳性能方案中数据库的分库分表。当读QPS和写TPS突然增加时，DBA可以重新将库拆分成多个端口来抵抗请求流量。因此，方案如下：成员常用地址设计结果：1个港口×32个仓库×16个表，1主从物流订单和物流记录设计结果：1个港口×128个仓库×32个表，1个主从and1slave4.5总结倾向于采用Minimumresourceplan：目前线上流量不大，为了节省成本，采用了minimumresourceplan。最小资源方案充分考虑了数据库的分库和分表。当读QPS和写TPS突然变大的时候，DBA可以把数据库拆分到不同的端口，也就是增加端口来应对。最小资源方案在应用层设计了一个开关。如果性能突然提升，可以临时申请启用缓存和消息队列。5性能评测参考标准以下标准是使用PCX86机器的经验值，仅供参考，评测时应根据不同机器进行调整。普通标准容量按5倍峰值冗余计算。分库分表的容量一般可以存储30年的数据。第三方查询接口5000QPS。一条数据库记录大约占用1K空间。Mysql单口读：1000QPS单口写：700TPS单表容量：5000万Redis单口读：40000QPS单口写：40000TPS单口内存容量：32GKafka单机读：30000QPS单机写入：5000TPSDB2单机读峰值：20000单机写峰值：20000单表容量：1亿条数据6总结资源列出了不同的非功能性质量需求，帮助读者梳理思路在技??术审查的过程中，尽量详尽地列出审查中应该注意的审查点，然后提供一个简单有效的审查大纲，最终实现一个基于大纲的互联网能力和性能评估的经典案例，在里面可以了解到一个高并发的互联网系统是怎么拆分的，拆分是用什么数据的。由于本文数据完全基于笔者在互联网平台上的经验，并不代表可以直接适用于任何企业或平台。在这里，我们将重点介绍容量和性能评估的方法论，帮助您梳理并实现高并发。互联网系统的想法。根据本文的容量评估，我们需要分布式中间件来支持数据库、缓存和消息队列的水平扩展和分片。点击《互联网性能与容量评估的方法论和典型案例》阅读原文。【本文为专栏作家“李彦鹏”原创稿件。转载可通过作者简书号（李彦鹏）或专栏取得联系】点此查看该作者更多好文
