你公司的系统性能方案是否只是流于形式？

功用计划在功用项目中是重要文档之一，它辅导整个项意图履行进程，也约束项目鸿沟，界说相关人员功用。但如今变得“微不足道”。

许多常见的功用项目中，功用计划便是个文档，且是个静态文档。里面写的东西是啥，项目后续会不会按这内容做，没人关心。它就成了形式，只需评定计划时才拿出看看。乃至一些第三方测验项目中，有些甲方连计划内容都不看，直接问有没有？有，就过去了。一个必需的交付物无人关心。

功用计划是个重量级文档。功用项目中被叫成“功用测验计划”。在我这，我把“测验”二字拿掉，由于这取决于我功用工程理念，我期望把整个项意图进程都描绘在计划。

0 我的功用计划 V.S 那些常见功用计划

常常看到有这样目录的功用测验计划：

这样的目录纲要组成

• 惯例项目信息：如测验布景、测验范围、测验原则、测验环境、施行准备、安排结构、项目危险、里程碑。
• 功用施行信息：如测验模型、测验战略、监控战略。
• 项目输出：如测验脚本、测验用例/测验场景、监控收集数据，测验陈述、调优陈述。

从功用测验计划的视点来说，这些内容似乎够。但若抛弃“测验”视角，从一个完好的功用项意图视点来看，这些内容还不行。

以前常常有人问我要一个功用项目计划模板，我一向不了解，就这么一个目录，为什么还非得要？自己一个字一个字也照样写得出来吧。后来我慢慢了解，他们要的其实不是纲要目录，而是一个完好的功用计划内容。

项目施行的功用计划根本不或许直接发出来，即便脱敏，一些内容也能够看出是归于某些企业。所以网上看不到完好的功用计划。尽管网上计划不完好，在功用商场上，仍是看到有太多功用计划抄来抄去，全体结构迥然不同。这也就导致功用项目中，许多计划都只流于形式。

由于咱们需求依据一个完好的项目来编写，所以，我把这个项目全体的计划写在这儿。你将看到，我认为的实在完好而且有含义的功用计划是啥样。

由于功用计划的内容比较多，而且相对琐碎，收拾了一张功用计划的目录表格，你能够对应这张表格，学习详细内容。

来看实在的功用项目施行计划：

1 布景

1.1 项目布景

由于各企业的商业软件有限制，只能挑选一个开源项目，而且这个项目最好能够覆盖常见的技能栈，以便能给你供给更多可借鉴内容。因而建立了一套电商项目：

• 这个项目是较为完好的
• 当时电商的体系比较典型，而且这个项目彻底开源，便于改造

不过，也由于这是一个开源的项目，功用和功用都不知道会有什么样的问题，咱们只需在功用施行的进程中一步步去开掘，所以这是一个非常符合咱们当时方针的项目。

1.2 功用方针

0. 依据经典的电商下单流程，测验当时体系的单接口最大容量。
1. 依据事务份额规划容量场景，充分利用当时资源，找到当时体系的功用瓶颈，并优化，以到达体系的最佳运转状况。
2. 依据安稳性场景，判别当时体系可支撑的体系最大累加容量。
3. 依据反常场景，判别当时体系中的反常对功用产生的影响。

在每一个功用项目中，功用方针都会影响项意图整个进程。因而，对方针的掌握将决议一个功用项意图走向。

某项目，客户要求做到支撑1000万人在线，项目不算小，开发团队有300人左右。到那一看只需两个功用测验人员，其中一个还刚毕业。于是，我就过去找他们科技部老迈，说这项目我做不了。由于依据这个方针和这样的人员装备，这坑不是我能填上的，得赶紧认怂。后来，那个科技部的老迈问，需求什么样资源才能做下去？于是我提几个必需条件，直到这些条件都满意，才接这项目。

功用方针在上下级眼中根本不一样，而我这样的处理，是期望把功用方针在上下级的脑袋中变得共同。这很重要。

2 测验范围

2.1 需求测验的特性

电商干流程：

2.2 不需求测验的特性

批量事务。

3 原则

3.1 发动原则

0. 确定体系逻辑架构和布置架构和出产共同。
1. 确定根底数据和出产共同或按模型缩放。
2. 确定事务模型能够模仿出产实在事务。
3. 环境准备完毕，包含： 4.1. 功用验证经过。 4.2. 各组件根底参数梳理并装备正确。 4.3. 压力机到位，并布置完毕。 4.4. 网络装备正确，衔接通畅，能够满意压力测验需求。
4. 测验计划、计划评定完毕。
5. 架构组、运维组、开发组、测验组及相关专家人员到位。

3.2 完毕原则

0. 到达项目要求的功用需求方针。
1. 要害功用瓶颈已处理。
2. 完结功用测验陈述和功用调优陈述。

3.3 暂停/再发动原则

1. 暂停原则

• 体系环境改变：举例：体系主机硬件损坏、网络传输时刻超长、压力发生器呈现损坏、体系主机因其他原因需升级暂停等。
• 测验环境受到搅扰，比方服务器被临时征用，或服务器的其他运用会对测验作用造成搅扰。
• 需求调整测验环境资源，如操作体系、数据库参数等。
• 该测验机型无法到达规划方针要求。
• 呈现测验危险中列出的问题。

2. 再发动原则

• 测验中发现问题得以处理。
• 测验环境康复正常。
• 测验危险中呈现的问题已处理。
• 环境调整完毕。

4 事务模型和功用方针

4.1 事务模型/测验模型

这个模型是直接从出产环境中获得的事务份额，经过核算日志就能做到。

有些企业的出产数据都在运维手里，功用团队怎样也得不到，由于没有权限，就连做事务模型的数据都没有。那功用项目可直接终止，由于做了也没多大含义，最多也便是找那些瞎吹牛的架构师和乱写代码的开发人员，犯的一些错罢了。

事务模型一般还能够由项目组供给出产上的事务报表，依据事务报表检查事务频频的买卖进行按份额，规划测验模型

事务方针/功用方针

在不清楚项目方针TPS的情况下，我暂定方针TPS为1000。依据经历来说，在这样的硬件环境下，定为1000并不算高，除非是没有合理的软件架构。

5 体系架构图

架构图的重要性：便利测验人员依据架构判别是否存在危险及问题扫除

5.1 体系技能栈

体系技能栈是让咱们知道整个架构中用了哪些技能组件。而这些技能组件中有哪些常见的功用瓶颈点，有哪些功用参数，咱们都能够在检查技能栈时得到一些相关信息。而在后续的作业中，咱们也要收拾出相应的要害功用参数装备。

下面这张表格，便是咱们在后续事例剖析中，会用到的技能栈。我在建立这个体系时，考虑的是尽量覆盖当时技能商场中的干流技能组件。

5.2 体系逻辑架构图

为后续功用剖析的时分，脑子里能有一个事务途径。做功用剖析时，要做呼应时刻的拆分，只需了解逻辑架构图才知道从哪拆到哪。

5.3 体系布置架构图

画布置架构图是为让咱们知道有多少节点、多少机器。在履行容量场景时，要有概念，这样的布置架构最大应该能够支撑多少的容量上限。

对一些无理的功用需求，你看了布置架构后，就可拒绝。比方说前段时刻有个人跟我说，他们有一个CRM体系，在做功用的时分，说要到达1万的并发用户。而实际上，那个体系就算是上线了，总用户数或许都不到1万。

体系布置架构图是不是便是体系各个层用了那些东西，这些是不是都要知道？是的。便是要知道各个层面用了哪些技能组件。一起还要知道事务途径是从哪里到哪里。

依据体系布置架构图，咋就能知道支撑多少容量上限？有啥评判办法吗？这个问题，动手实践即知道。对你测验的体系，验证单节点的容量上限是多少，就能大约判别整个架构能支撑多少，当然这进程中要有模型的创建进程。如在一个2C 4G机器，我直接用一个post接口做一个insert动作，在我的经历中，大约便是在500-600TPS左右。

6 功用施行前提条件

6.1 硬件环境

经过对全体硬件资源的收拾，依据经历知道容量大约能支撑多少的事务量级，而不至于随便定无理的方针。

如当看到下面表格中这样的硬件装备，没有人会把方针定为10000TPS。由于即使是关于最根底的接口层来说，这样的硬件也支撑不了这么大的TPS。

当时服务器总共运用在运用中的资源是：64C的CPU资源，128G的内存资源。NFS服务器不必在运用中，故不核算在内。由于单台机器的硬件资源相对较多，所以在后续的作业中，咱们能够将这些物理机化为虚拟机运用，以便利运用的办理。

在本钱上，所有物理机加在一起大约8万左右的费用，这其中还包含交换机、机柜、网线等各类杂七杂八的费用。

对硬件的本钱进行一个阐明，主要是由于在当时的功用职业中，很少有功用工程师做本钱核算。功用项意图方针是让线上的体系运转得更好，也要知道运用了多少本钱在运转事务体系。

在当时的功用职业中，有许多的线上主机处于高本钱低运用率的状况当中，这是极大资源糟蹋和本钱耗费。常常在功用项目看到一台256C512G的硬件服务器里，只运转个4G JVM的Tomcat，功用工程的价值彻底没有在这样的项目中运用。因而，我时常会痛心疾首地慨叹功用职业不景气：

• 企业中没有意识到功用的价值，觉得摆个高装备的硬件服务器，事务体系的功用就能好起来
• 功用商场从业人员彻底没有把功用的价值，透明化地表现出来。而且许多功用人员自身的技能才能不足，这也让一个企业彻底看不到功用本该有的价值

鉴于此，作为功用从业人员，咱们有必要要了解硬件装备和全体事务容量之间的联系。

6.2 东西准备

6.2.1 测验东西

在测验进程中，咱们将运用JMeter的backend Listener把数据直接发到InfluxDB中，然后再由Grafana来展现。咱们不运用JMeter的分布式履行功用或本地搜集数据的功用，由于这样会耗费本地的IO。

可是，现在仍是有许多功用人员，仍然在项目中频频地运用那些功用东西的低功用操作手法，一起还在不断诉苦功用这么差。沉着运用东西，不要觉得一个功用测验东西拿起来就能够用。

6.2.2 监控东西

依据RESAR功用工程中的大局-定向的监控思路，咱们在挑选第一层监控东西时，要收集全量的大局计数器，收集的计数器包含各个层级，这儿请参阅前面的架构图。

可是，请你留意，在大局监控中，咱们要尽量防止运用定向的监控手法，比方说java运用中的办法级监控、数据库中的SQL监控等。由于在项目开始之初，咱们不能确定到底在哪个层面会呈现问题，所以不适合运用定向监控思路。

那大局监控怎样来做才最合理呢？这儿咱们能够参阅线上运维的监控手法。留意，咱们在功用监控进程中，尽量不要自己臆想，随意建立监控东西。

有时咱们或许为了能监控得更多，会在测验环境中用许多监控手法。但实际上，线上运维时并不必那些手法，这就导致了监控对资源的耗费大于出产环境的资源耗费，咱们也就得不到正常有效的作用。

前面咱们说到在挑选第一层监控东西时，需求收集全量的大局计数器。在咱们收集好大局的计数器后，还需求剖析并发现功用问题，然后再经过查找依据链的思路，来找功用瓶颈的根本原因。

6.3 数据准备

6.3.1 根底数据

在功用工程中，根底数据要满意：

0. 满意出产环境的实在数据分布：最合理方法是脱敏出产数据。假如你要自己造数据的话，也必定要先剖析事务逻辑。在咱们这个体系中，我造了243万条用户数据和250万条地址数据。
1. 参数化数据必定要运用根底数据来覆盖实在用户：许多人都在运用少数数据做大压力，这种逻辑彻底不对。比方用相同的恳求body去压测某个接口吗？为什么彻底不对？恳求在不同的用户下参数是不同的，假如用相同的参数去做压力，对后端的压力是不同的。在功用脚本中必定要用根底数据来做参数化，而用多少数据取决于功用场景的规划。参数化数据便是压力东西中用来做参数化的数据，这些数据有些是用户自动输入的，有些是要和后台DB对应。

7 功用规划

7.1 场景履行战略

7.1.1 场景递加战略

功用场景须满意：

• 接连
• 递加

不接连递加能咋样？如下图：

红框便是递加带来的功用问题表现。由于在递加进程中，被测体系的资源要动态分配。体系会不会在这个时分颤动，彻底能够从这样的图中看出来，而这样的场景才是实在的线上场景。

若不接连递加，就不会有图中红框这样的部分。要是不接连递加，也就不能模仿出线上实在场景。

要模仿出产场景，接连递加必定要做到的，不容踌躇。 而不同东西，设置接连递加的方法不同。

LoadRunner规划：

JMeter规划如下：

规划场景中，必定要做到上面这种接连递加的样子。

7.1.2 事务场景

在RESAR功用工程中，功用场景只需求这四类即可：

履行次序先后为：基准场景、容量场景、安稳性场景、反常场景。

除这四类功用场景外，再没有其他类型场景。在每一个场景分类中，都可规划多个详细场景覆盖完好事务。

① 基准场景

用脚本加上三五个线程跑上多少次迭代，就算基准场景。这场景含义安在？它仅能验证一下脚本和场景是正确的。所以，我不把这样的进程称为基准场景。

RESAR功用工程理念中，基准场景须是容量场景的前奏。

详细怎样做？在基准场景中，也经过递加接连的场景做到最大TPS。即要把单接口或单事务压到最大TPS，然后剖析单接口或单事务的瓶颈点。

基准场景中有必要做调优动作？应先判别当时单接口或单事务的最大TPS，有无超过方针TPS：

• 超过，而且呼应时刻也在事务可接受的范围之内，不必调优
• 没有超过，须调优

别的，依据RESAR功用工程理论，功用履行的第一阶段方针便是把资源用光，第二阶段的方针是将体系优化到满意事务容量。任一体系要调优都是无止境，而方针是要确保体系正常运转。

咱们先做接口级的，然后把接口拼装成完好的事务量，并完成事务模型，然后再在容量场景中履行。咱们将履行测验范围中接口的基准场景。

基准场景，混合场景的线程数怎样确定？递加接连的方法不需求确定压力东西中的线程数。只需确定事务份额就能够了。最大的线程数或许经过二分法确定。

二分法确定线程数

先依据资源和自己的经历判别一个体系的最大上限TPS，然后依据单线程的TPS，来核算需求多少线程。 若一个体系经过资源和经历判别出大约能到达1000TPS，而单线程的TPS是100，那大约能判别出需求10个线程就够了。这时直接上10个压力线程递加加压，看下。若把资源用完了或许有了瓶颈，这时就能剖析优化。 假如没有用完或许呈现瓶颈，那就直接上20个压力线程递加再来判别。 假如资源用得过多或许瓶颈有多个，那就能够降到5个线程再来判别。 依此类推。

基准测验中，接连递加50个线程数到达最大TPS，还有没有必要继续加线程数吗？到达多少线程数才不加？（需求没有线程数的要求）看你的方针是什么。假如是想到达体系最大TPS，关于容量场景来说那就没必要加了，要是体系还有问题，想把呼应时刻拖长一点以便剖析，就能够再加。

事务有11个，要怎样组合这11个事务进行基准场景的测验？基准场景是拿单事务跑的，不必组合。

② 容量场景

有了基准场景的作用之后，进入容量场景的阶段。秉承“接连、递加”的履行思路，要完成事务模型，来实在模仿线上的事务场景。

• 许多的功用项目里，大部分功用需求都提得不是很详细，从而导致功用场景的模型和出产场景不共同
• 即便事务模型和出产共同了，也会由于功用工程师在履行进程中没有严厉模仿事务模型中的份额，功用场景的作用变得毫无含义。履行进程中，呼应时刻会随着压力的添加而添加，仅用线程数来操控份额很不沉着，由于在履行的进程中会呈现事务份额失衡

如何操控这份额联系？JMeter的话，可用Throughput Controller操控事务份额：

总归，场景履行完毕后，要把事务份额做核算，而且要和事务份额比照，当份额共同时，才算合理场景。

什么是最大TPS？看图，你觉得最大TPS多少？

容量场景的最大TPS是指最大的安稳TPS。 你看，上面这张图现已颤动了，现已不安稳了，再去找它的最大TPS还有什么含义？你敢让一个出产体系运转在这样颤动的状况中？所以，关于上图中这样的TPS曲线，我会把最大的安稳TPS定为第三个阶梯，即600左右，而不定在700。

功用场景中，特别是在容量场景中，常常有人说到“功用拐点”，而且把功用拐点称作是判别功用瓶颈的要害常识。

拐点，又称反曲点，在数学上指改变曲线向上或向下方向的点。直观地说，拐点是使切线穿越曲线的点（即接连曲线的凹弧与凸弧的分界点）。

那么在TPS曲线中，你真的能找到这样的点吗？反正我找不到。就以咱们上面那张图为例，图中哪里是拐点？或许有人会说这个曲线没有拐点。可见，功用拐点其实是一个在详细履行进程中非常有误导性的概念。请你今后尽量不要再用“功用拐点”这个词来测验描绘功用的曲线，除非你真看到拐点。

③ 安稳性场景

功用商场中，还没人给出安稳性场景应运转多长时刻的确切定论。依据事务属性不同，安稳性场景也有不同规划思路。

安稳性场景中，只需两个要害点：

第一个要害点：安稳性场景的时长。

一个体系上线之后，运维人员肯定运维巡检，发现有问题就处理：

• 有的体系是有固定的运维周期，比方说会设定固定的Job来做归档之类的动作
• 有的体系是依据巡检的作用做相应的动作

安稳性要做的便是确保在运维周期之内事务能正常。 所以，在功用的安稳性场景中，要彻底覆盖事务容量。

如下图：

运维周期内，有1亿笔事务容量。依据上面容量场景中的测验作用，假定最大安稳TPS 500，安稳性场景的履行时长便是：

$安稳性时长=100000000÷500÷3600÷24\approx 2.3(天)$

经过这样的核算，就能知道安稳性场景应跑多久，这也是仅有合理方法。

第二个要害点：用多大TPS履行。

有人说用最大TPS的80%来运转安稳性场景。why？凭啥不必最大的来运转？有人说之所以用最大TPS 80%，是由于在履行安稳性场景时不能给体系太大压力，否则易导致体系问题。这说法就怪了。既然容量场景都能得出最大TPS，为什么安稳性就不能用？若用最大的TPS履行安稳性场景会呈现问题，那这些问题不正是咱们期望测验出来的功用问题吗？为什么要用低TPS来防止功用问题的呈现？所以，用最大TPS 80%做安稳性场景是错误思路。

履行安稳性场景时，彻底能够用最大的安稳TPS来运转，只需覆盖了运维周期之内的事务容量即可。若你不必最大的安稳TPS来运转，而是用低TPS来运转，也有必要要覆盖运维周期之内的事务容量。

④ 反常场景

关于反常场景，有些企业是把它放到非功用场景分类中的，这个我倒觉得无所谓。不论放在哪里都是要有人履行的。我之所以把反常场景放在功用部分，是由于这些反常场景需求在有压力的情况下履行。

关于惯例的反常场景，咱们常常做的便是：

• 宕主机
• 宕网卡
• 宕运用

除此之外，在现在微服务盛行的年代，还有新招——宕容器。也可用一些所谓的“混沌工程“东西完成对容器的随机删除、网络丢包、模仿CPU高级操作。

功用计划中四种场景中需求添加各场景的功用用例吗？是的，要规划详细的每个类型下有多少要履行的功用场景。一般我不必“用例”这个词，由于这个词过小了。

7.2 监控规划

7.2.1 大局监控

有前面监控东西部分，监控规划就已呈现在写计划人的脑里。体系大局监控：

运用Prometheus/Grafana/Spring Boot Admin/SkyWalking/Weave Scope/ELK/EFK就能够完成具有大局视角的第一层监控。对东西中没有覆盖的第一层计数器，只能在履行场景时再履行命令弥补。

7.2.2 定向监控

在有问题时才运用：

功用剖析中，除表格中的这三东西，还有许多东西在查找功用瓶颈依据链时运用，这儿无法全部罗列，只能依据体系运用到的技能组件，罗列常用东西。

8 项目安排架构

功用计划必定要画出项意图安排架构图，写明各安排人员的作业范围和职责，防止扯皮。常见安排架构：

这是按事区分，而非职场的作业职位：

• 功用脚本工程师所担任其实是现在大部分功用从业人员都在做且仅在做的。功用剖析工程师在许多功用项目中几乎无，也没这样的固定职位。其实，功用剖析工程师很有必要存在
• 架构师、开发、运维都要在支撑功用剖析的状况。“支撑”不是指站在旁边看，而是在有问题后，详细给出支撑，而非推诿
• 事务方，功用的事务需求来历，必定要有。若事务方提不出合理的功用需求，这项目根本稀碎
• 老板，在功用项目中，常常看到老板都不明白啥是功用，只会叫着要支撑XXX并发用户数，支撑XXX在线用户数。这样的老板交流起来也简单，拿作用给他。功用项意图履行进程中，当资源不足时，要让老板知道，一起降低老板预期，要不然在后续交流很费力

9 作用输出

9.1 进程性输出

0. 脚本
1. 场景履行作用
2. 监控作用
3. 问题记录

功用项目中有这些内容就够，不必更多，也不能更少。许多功用项目在履行完之后，除了有一份功用测验陈述，啥进程性输出都没。这样的企业是怎样堆集功用经历的？在功用项目中，多做一些归档收拾，以备后面项目查阅，并完成技能堆集。

9.2 作用输出

• 功用场景履行作用记录的陈述（功用测验陈述）
• 功用调优陈述

9.2.1 功用项目测验陈述

0. 陈述必定要有定论，而不是给出一堆“资源运用率多少”、“TPS多少”、“呼应时刻多少”这种描绘类总结语。功用作用都在这个陈述中了，谁还看不见？还要你复述？要给出“当时体系可支撑XXX并发用户数，XXX在线用户数”这样的定论
1. 不要用“或许”、“或许”、“理应”这种模棱两可词，否则便是在耍流氓
2. 要有对运维作业的主张，也要给出要害功用参数的装备主张，如线程池、队列、超时等
3. 功用作用陈述中要有对后续功用作业的主张

9.2.2 功用调优陈述

调优陈述才是整个功用项意图精华，调优陈述中必定要记录下每一个功用问题的问题现象、剖析进程、处理计划和处理作用。调优陈述彻底是一个团队技能才能的表现。

10 项目危险剖析

常见危险：

0. 事务层的功用需求不明确
1. 环境问题
2. 数据问题
3. 事务模型不准确
4. 团队间和谐交流困难
5. 瓶颈剖析不到位，影响进展
6. ……

在咱们这项目中，比较大的危险便是：

0. 硬件资源有限。
1. 项目时刻不可控，由于出问题，没人支撑，只能自己搞

11 总结

功用计划是一个功用项意图重要输出。若你在项目中做快速迭代，或许并不需求写如此复杂而且重量级的文档。由于文档里描绘的许多作业都现已做过了，你或许只需求跟着版本去做迭代比对。

但对一个完好项目，功用计划很重要。由于它辅导这项意图整个进程。功用计划中：事务模型、功用方针、体系架构图、场景规划、监控规划等都对整个项意图质量起到要害作用。

12 FAQ

微服务电商项目介绍：mp.weixin.qq.com/s/a8nDBbkuv…

看到物理机器2它的available才几百M，这会不会影响压测，要不要调大一点再压测？这个值是看还有多少可用的，可是要不要调大，取决于有没有hard faults产生。