如何打造一个适合现代企业的完美业务模型？

标签：26 14 完美模型 13 业务 2020 打造 Oct

容量场景中，每个业务比例都要符合真实业务场景的比例。不符合，那场景的执行结果也没意义。

但很多性能人员因为对业务模型的抽取过程不了解或拿不到具体数据，导致业务模型和生产业务场景不匹配，整个性能项目都变得无意义
也有大量项目，并没有拿历史业务数据做统计，直接非常笼统地拍脑袋，给出相应业务模型，也不合理
也有人为让业务模型和真实业务场景尽可能匹配，直接拿生产环境的请求进行回放。可是，即便我们拿生产环境的请求录制回放了，也不能保证业务模型和未来的业务场景一致，因为未来的业务场景会随着业务推广而变化

做场景时首先要明白，当前场景是要模拟历史业务场景，还是未来业务场景。

未来业务场景，就要靠业务团队给出评估，而非性能团队。当前性能市场中，经常有企业要求性能团队给出业务模型，这不理智:

性能团队的业务背景不如业务团队更熟悉
他们对业务市场的把握也不够专业

真实工作场景中，业务模型的确认从来都不应由一个团队，而应由业务团队、架构团队、开发团队、运维团队和性能团队共同确定，并最终由项目最上层领导确认。

若一个系统有历史业务数据，那我们获得业务模型就有背景数据。这时，性能团队应从历史业务数据中抽取出各场景的业务模型。如果系统没有历史数据，那就应该像对未来业务模型评估一样，需要各团队协作给出当前的业务模型。

那到底如何从历史业务数据中抽取出业务模型？两大步：

抽取生产业务日志。可通过多种手段实现。本文展示两种常见手段。一种是当没有日志统计系统时，使用awk命令抽取；另一种是使用ELFK抽取
梳理业务逻辑

第一步，抽取生产业务日志是为得到对应的业务比例。

1 使用命令抽取生产业务日志

以少量Nginx日志举例。

Nginx中日志格式通常如下：

120.220.184.157 - - [26/Oct/2020:14:13:05 +0800] "GET /shopping/static/skin/green/green.css HTTP/1.1" 200 4448 0.004  0.004 "https://www.xxx.cn/shopping/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" "124.127.161.254"
 120.220.184.203 - - [26/Oct/2020:14:13:05 +0800] "GET /shopping/static/js/manifest.0e5e4fd8f66f2b389f6a.js HTTP/1.1" 200 2019 0.003  0.003 "https://www.xxx.cn/shopping/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" "124.127.161.254"
 120.220.184.149 - - [26/Oct/2020:14:13:05 +0800] "GET /shopping/static/js/app.cadc2ee9c15a5c1b9eb4.js HTTP/1.1" 200 138296 0.100  0.005 "https://www.xxx.cn/shopping/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" "124.127.161.254"

以上数据内容及顺序可在Nginx配置文件中配置。

目标：抽取其中某个时间内的每秒的访问量。只要把对应时间取出来统计：

cat 20201026141300.nginx.log|awk '{print $4}' |uniq -c

得到：

5 [26/Oct/2020:14:13:05
    3 [26/Oct/2020:14:13:06
   14 [26/Oct/2020:14:13:07
    4 [26/Oct/2020:14:13:08
    1 [26/Oct/2020:14:13:09
    2 [26/Oct/2020:14:13:10
    1 [26/Oct/2020:14:13:12
    2 [26/Oct/2020:14:13:20
   14 [26/Oct/2020:14:13:23
    1 [26/Oct/2020:14:13:24
    2 [26/Oct/2020:14:13:26
    2 [26/Oct/2020:14:13:29
    9 [26/Oct/2020:14:13:30
    9 [26/Oct/2020:14:13:31
    1 [26/Oct/2020:14:13:32
   13 [26/Oct/2020:14:13:35
    2 [26/Oct/2020:14:13:37
   20 [26/Oct/2020:14:13:38
    2 [26/Oct/2020:14:13:39
   33 [26/Oct/2020:14:13:44
   17 [26/Oct/2020:14:13:46
    5 [26/Oct/2020:14:13:47
   23 [26/Oct/2020:14:13:48
   29 [26/Oct/2020:14:13:49
    4 [26/Oct/2020:14:13:50
   29 [26/Oct/2020:14:13:51
   26 [26/Oct/2020:14:13:52
   22 [26/Oct/2020:14:13:53
   57 [26/Oct/2020:14:13:59
    1 [26/Oct/2020:14:14:02

就知道哪段时间里的访问量最高。如你只想取到分钟、某小时、某天，都可做相应命令调整。如想取到分钟级，只要加上相应的截取命令：

cat 20201026141300.nginx.log|awk '{print $4}' |cut -c 2-18|uniq -c

对应结果：

352 26/Oct/2020:14:13
    1 26/Oct/2020:14:14

即在我这个日志中有两分钟内的数据：

第一分钟中有352个请求
第二分钟中只有一个请求

若你想请求URL来做统计，可修改命令：

cat 20201026141300.nginx.log|awk '{print $7}' |cut -c 1-50|uniq -c

结果如下：

................
    1 /shopping/checkLogin
    1 /shopping/home/floor
    1 /sso/loginOut
    1 /shopping/home/navigation
    6 /shopping/home/floor
    2 /shopping/home/floorGoods
    1 /shopping/home/sysConfig
    4 /shopping/home/floorGoods
    1 /shopping/home/floor
    1 /sso/loginOut
 ................

此时我们取日志中的第七个数据，然后截取统计。这样我们就可以知道，每个时间段内每个请求的数量，也就可以得到相应的业务比例了。

这些命令灵活运用，处理数据量不太大的文件没问题。

2 使用ELFK抽取生产业务日志

如果你想使用ELFK抽取日志，具体可以按如下步骤来做：

安装ELFK。这里的ELFK是指ElasticSearch/Logstash/FileBeat/Kibana的组合。具体安装方法可以搜索一下，网上的教程多如牛毛。
配置好ELFK后，在Kibana的Discover界面就能看到收集的信息。注意，一条日志对应的就是一次命中。
通过选择时间段就可以看到有多少请求在这个时间段内。
要想得到接口请求的百分比，可以点击“Dashboard”中的“可视化”，创建一个Lens可视化面板，选择相应的URL字段就可以看到各个接口的百分比了。

总体来说，用ELFK抽取生产日志得到业务模型，可以分为两个阶段。

第一个阶段是统计大时间段的日志信息，然后逐渐缩小范围，比如说按年、月、天、时、分的顺序。这一步是为了将系统的峰值请求覆盖住。

第二个阶段是细化所选择的时间段。虽然我们在第一个阶段已经把时间段细化到分了，但由于我们的场景得到的结果是按秒来统计TPS的，所以我们要再细化到生产环境的TPS级别。这样就可以把生产的业务场景和测试中的场景进行对比了。

下面我通过实例给你详细讲一讲这两个阶段。

第一个阶段：统计大时间段的日志。

在查看ELFK中的数据时，建议你尽可能选择覆盖全部业务场景的时间段。比如说，我们要选择峰值时间段，一开始要选择时间段的范围设置大一些，这样才不会漏掉数据。然后再通过柱状图的高低做范围缩小。

通过这样的操作就可以知道生产环境中各业务接口的总体百分比了。

其实，实时将相应的日志输出到ELFK中，是很多企业对日志处理的常用方法。这样不仅可以实现对日志的灵活查找，也可以实现对日志的长时间存储，并且也可以做更多的后续处理，生成可视化图形之类的。在这里，我们来实际操作一下。

如何打造一个适合现代企业的完美业务模型？_生产环境

如上图所示，我们在Kibana中截取了一段时间的日志，这段日志总共有6,624,578次请求。你可以用Kibana直接生成下面这样的表格视图：

如何打造一个适合现代企业的完美业务模型？_生产环境_02

这样你就可以知道哪些请求比较靠前。为什么我没有显示总数呢？因为在一段时间之内的每个请求，我们要生成相应的柱状图，如果看到它们的集中时间段是相同的，那就做一个场景即可；如果不同，则要做多个场景。下面我们来搜索一下。

/mall-member/sso/login

如何打造一个适合现代企业的完美业务模型？_数据_03

/mall-portal/home/content

如何打造一个适合现代企业的完美业务模型？_生产环境_04

/mall-member/member/address/list

如何打造一个适合现代企业的完美业务模型？_生产环境_05

看图上的数据时间点，在我这个例子中，所有的请求量级的时间点都是相同的，所以我们只需要做一个场景即可全部覆盖。请你务必要注意，在你的实际项目中，并不见得会是这样。如果出现某个请求的高并发时间点和其他的请求不在同一时间点，就一定要做多个场景来模拟，因为场景中的业务模型会发生变化。

在我这个示例中，我们把数据量也列在表格中，同时求出比例关系，也就是拿某请求的数量除以总请求数，如下所示：

如何打造一个适合现代企业的完美业务模型？_生产环境_06

这是在这一个时间段的业务平均比例。

通过第一阶段，我们已经可以知道哪个时间段的请求高了。但是这个时间段范围是5分钟，这对于任何一个系统来说，都算是比较集中的时间段了。但是我们的动作还没有结束，因为我们不仅要知道哪一段的用户操作比较集中，还要知道的是生产上能达到的TPS有多高。所以还需要细化，只有细化了我们才能知道具体生产的TPS。

第二个阶段：细化时间段

通过主面图中的Timestamp，可以看到是时间间隔是5分钟，我们选择最高请求的时间段，点进去。

如何打造一个适合现代企业的完美业务模型？_数据_07

这样我们就得到时间间隔为5秒的图了：

如何打造一个适合现代企业的完美业务模型？_时间段_08

然后按命中次数来计算TPS，就可以得到如下结果：

$生产TPS = 9278 \div 5 = 1,855.6$

再细化得到毫秒级图：

如何打造一个适合现代企业的完美业务模型？_时间段_09

通过这种方式，我们就可以得知一个系统在生产环境中的峰值TPS。1855.6这个值是我们要定的测试环境中总的TPS。如果达不到这个值，那就要接着优化，或者增加硬件资源。

通常情况下，得到总TPS之后，我们要根据测试目标，分三种方式处理这个总TPS，而这三种方式都是以业务目标为前提的。

业务无变化，应用版本有小变化（通常只是小的功能变化或修改Bug）：在这种情况下，我们只要将计算出来的TPS做为性能场景总的TPS指标即可。
业务无变化，应用版本有大变化（比如说架构变更）：在这种情况下，我们只要将计算出来的TPS做为性能场景总的TPS指标即可。
业务有变化，应用版本有大变化：在这种情况下，我们要根据业务估算的增量来做相应的TPS增量计算。如果根据业务变化趋势预估会增加20%，那你就可以在上面计算的总TPS的基础上，再加上对应的20%即可。

3 梳理业务逻辑

在上面的接口得到业务模型之后，我们就可以根据接口的量级梳理业务逻辑，以便更真实地模拟生产业务场景。其实在上面的步骤中，我们已经按顺序做了排列，你可以看一下前面的表格。

所以在这个示例中，大概有58%的用户会完整地走完流程。为什么是58%呢？因为登录的业务比例是12%，而后面下单比例是7%。所以是： $ 7\%\div12\% \approx 58\% $

整体流程说明

最后我们来梳理一下整体的流程：

如何打造一个适合现代企业的完美业务模型？_生产环境_10

请注意，上面的业务场景在实际的项目业务统计过程中可以有多个。这个思路可以解决任何性能场景和生产场景不一致的问题。

4 总结

业务模型抽取时注意：

抽取时间：抽取时间一定要能覆盖生产系统的峰值时间点；
抽取范围：抽取的范围要足够大，因为在一些场景中，即便不是峰值，但由于某个业务量较大，也会出现资源消耗大的情况；
业务比例在场景中的实现：得到业务模型之后，我们在性能场景中一定要配置出对应的业务比例，不能有大的偏差。

做到这几点，性能场景基本上就不会和真实业务场景有大差异。

5 FAQ

为什么性能场景中要模拟出真实业务比例？
抽取生产数据并最终得到业务模型的步骤是什么？

示例中，大概有 58% 的用户会完整地走完流程。为什么是 58% 呢？因为登录的业务比例是 12%，而后面下单比例是 7%。所以是：7%/12%=58%，真没懂。

仔细想想就明白了。在做脚本时要考虑完整业务流的，而只有一部分走完了，只有把所有线程的58%请求应用到完整业务流才能实现7%的下单覆盖，12%的登录覆盖。

ELFK系统里有办法截取url统计不？url里带的有id之类的，希望能把这部分模糊掉来统计汇总

可以在取日志时用logstash截取。

我再最上面看了一些东西不过都是抽取接口级的请求比例，直到看到梳理业务逻辑的讲解，我才放了心；哈哈，可见我们只将请求的数据抽取出来还是不行的，我们还得分析业务场景，只有做完梳理业务逻辑后这个比例才能真的用；

那是肯定的。性能的最大价值是为了业务稳定服务的，如果没有用户级的业务覆盖，就成了过场和摆设。

抽取线上的请求比例比较容易，把它们转成场景中可用的线程似乎不是太容易。比如总TPS:35，浏览商品目录页17%，浏览商品详情页32%，查询商品20%，加购物车6% ，查看购物车5%，完成下单3%，登录1%。脚本针对以上都有单独线程组在同一个jmx中，但是加购包含详情页，查看购物车包含以上，下单包含所有。像这样的如何设置各线程组的线程数来达到总TPS是35且符合以上业务比例？

把请求单独列出来。如果有包含关系，就把相应的请求在独立的请求中减掉。

首次请求接口后，在服务器端可能会产生缓存，那么做压力测试时，服务器端的缓存功能需要关掉吗

如果考虑的是模拟真实的线上环境，不需要关掉。

细化时间段里算出的生产TPS是整个系统总的TPS还是单接口的TPS，如果是单接口，每个接口都同样的方式计算一遍。

对于梳理业务逻辑这一步从字面看懂了，但不明白得到的结果【58%用户走完全流程】这个结论，对于性能业务场景分析有什么用，最终定各个接口的TPS也没有用到这个58%？用到了呀。在后面的容量场景中用。

做性能的目的就是要解决生产环境真实业务可能遇到的问题。

标签：26,14,完美,模型,13,业务,2020,打造,Oct
From： https://blog.51cto.com/u_11440114/6179270