背景： 本文主要就是一篇学习笔记，总结一下学到的东西。

作用：依据系统架构，梳理性能点，这样定位问题的时候才不会遗漏

一、系统架构

如下图，简单的一个分布式+微服务的系统架构。这个应该目前大部分采用的这种。

1.1一个请求的完整流程：

1、客户端或者jmeter压测工具发出请求

2、请求通过网络传输，到达nginx服务

3、nginx接收并分发请求

3.1 nginx接收请求：

nginx最大tcp连接数65535，超过这个数，请求要排队。

3.2 nginx对请求进行转发：

需要转发的请求过多时，转发请求需要排队

4、请求通过网络传输，到达后端服务集群。集群下，每个server节点的代码是一样的。

5、请求到达容器tomcat：

maxThreads（最大线程数默认200）：每一次HTTP请求到达Web服务，tomcat都会创建一个线程来处理该请求，那么最大线程数决定了Web服务可以同时处理多少个请求，当超过最大线程数时，请求开始排队了。

6、tomcat线程分配到CPU时间片段后，开始工作。

7、代码层对请求的逻辑处理，执行业务代码。在内存里创建对象

8、不同服务之间的通讯，消息服务器。如用户下单的请求，这个请求要先经过商品集群，再经过订单集群

mq 或者Kafka等

9、服务与数据库的交互，请求通过网络达到数据库服务，操作数据库。

请求数量超过数据库连接池大小限制，请求排队

10、数据库对请求进行处理，得到数据后，再将数据返回给后端服务器

11、数据库主从读写分离。主库负责写数据，然后将变动，通过binlog同步到从库，从库负责查询数据。

二、系统架构中的节点介绍

2.1  服务器的缓存：

2.1.1、应用服务器本地缓存：

将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，

2.1.2分布式缓存：

可以缓存海量的数据，并且容易扩展，常用的分布式缓存是Redis。

2.1.3 CDN:

CDN基于内容的转发网络。

网络归根结底还是通过光纤或者电缆传播，距离越近，对应的时延肯定越小。

假如一个上海的主机想要访问北京的主机的一些数据，那么数据肯定要走几百公里的路程。能不能在上海设置一个代理主机来缓存北京的主机对应的数据，这样的话，上海的主机直接访问上海的代理主机而不用在访问源服务器了，大大的减少了时延。

这就是CDN，基于内容的转发网络，通过设置边缘代理服务器来大大的减少了客户端请求的网络时延。
CDN中的边缘节点是无法将互联网上的所有内容都缓存起来的，只能选择性的缓存那些热点内容。
资源分为动态资源和静态资源。

静态资源，比如说图片、视频等每次获取都不会改变的资源，可以使用CDN进行代理缓存。

动态资源是服务器会根据不同的参数来返回不同的资源结果，是一个动态的，比如实时点击率等动态数据。CDN是无法直接进行缓存的。

2.2数据库主从读写分离：

分担数据库的压力，主库负责写，从库负责读。主库写完数据后，会将数据同步到从库。

读取数据做了分流，从库1与从库2。

保持数据的的一致性，主库将数据同步到从库，通过binlog文件实现。

binlog指二进制日志，它记录了数据库上的所有改变，并以二进制的形式保存在磁盘中，同步的是sql语句。

主从同步，存在延迟，当延迟高时，会导致我们写完数据后，去查数据，查不到该数据。过一会才会查到该数据。延迟问题，需要dba来解决。

binlog有三种格式：

statement：基于SQL语句的复制（statement-based replication，SBR）
row：基于行的复制（row-based replication，RBR）
mixed：混合模式复制（mixed-based replication，MBR）

2.3消息服务器

常用的消息服务器RabbitMQ、KafKa等。

应用场景：

服务的解耦，服务的解耦是基于两个服务之间进行调用的时候，出现的问题，A产生数据而服务BCD都需要，那么我可以直接在A中调用BCD，从而实现数据的传递，但当在微服务的时候，服务不会像这个例子这么少，成千上百的服务，这样服务间的耦合性太高，维护成本过高，引入Rabbitmq中间商后，A把数据交给Rabbitmq，然后BCD等服务，需要就去rabbitmq拿就可以了

异步调用：

 生成者生产消息，消费者消费消息是异步进行的。

在电商平台下单的例子，我们购买商品，点击下单。后会同时进行以下三个动作

1、商品库存数量减一

2、商家进行发货处理

3、后台生成订单

点击下单的时候，请求发送到消息服务器，然后消息服务器直接返回一个200的状态。

将消息下发到不同的服务是异步进行的。三个点必须保证同时成功或者同时失败，消息队列，必须保持顺序性和一致性。

在请求链路中：

如果一个请求，通过消息服务器，消息服务器是直接返回一个状态的，是没有处理逻辑的，逻辑处理是异步进行的。

所以这种情况，定位性能问题，需要分成2段来分析

 一段就是我们正常的请求链路，另一段就是消息服务下发消息和其他服务的逻辑处理。

流量削峰：
举个栗子，当我们的服务器只有一台的时候，瞬间qps达到了3000那么这个服务器的压力就会剧增，也就是瞬时压力爆棚，那么通过Rabbitmq的消息队列，拉长战线（处理时长），通过rabbitmq的请求慢慢发给服务器进行处理，例如qps从每秒3000通过rabbitmq后变成qps300而其他的在rabbitmq队列中排队等待处理，这样虽说把时间拉长，但可以减轻瞬时压力

三、性能瓶颈点

根据系统架构图画出被测请求的数据流图，分析性能瓶颈

1、客户端或者jmeter压测工具发出请求（负载机性能&网络带宽问题）

在压测过程中，使用负载机jmeter发送请求。负载机的性能与网络带宽限制了请求的发送。

负载机的性能：一般并发超过300（或者500），就需要做分布式了

网络带宽：比如现在本地带宽为2M，请求一次需要5kb，那每秒只能发送400个请求；但是如果本地现在带宽为4M，那每秒就能800个请求；在本地网络环境测试中，由于网络不稳定所以可能会导致高并发比低并发的吞吐率低，为了规避这些不可控因素建议大家将测试环境放到云服务器上，这样网络会较为稳定，而且带宽也可以按需调整。

当网络不稳定时，可能会导致接口响应时间过长。我们可以通过ping来看看网络状态

2、请求通过网络传输，到达nginx服务（网络问题）

3、nginx接收并分发请求（nginx配置问题）

接收请求：

nginx最大tcp连接数65535，超过这个数，请求要排队。

对请求进行转发：

需要转发的请求过多时，转发请求需要排队

4、请求通过网络传输，到达后端服务集群。（网络问题）

nginx与后端服务之间的网络，会影响性能

5、请求到达容器tomcat（tomcat硬件问题）

每一次HTTP请求到达Web服务，tomcat都会创建一个线程来处理该请求，那么最大线程数决定了Web服务可以同时处理多少个请求，当超过最大线程数时，请求开始排队了。

6、tomcat线程分配到CPU时间片段后，开始工作。（cpu硬件问题）

需要观察cpu的利用率：

1、用户进程消耗的cpu，一般小于70%/80%是正常的

2、系统内核进程消耗的cpu（操作系统的底层资源是在内核完成的，比如读写磁盘。超过10%就很高了，可能是IO、中断、上下文切换导致的

8、业务代码对请求的逻辑处理。（JVM&GC）

java项目，需要先在内存里创建对象，才可以进行后续的逻辑处理。我们需要关注JVM的内存状态包括GC等。

java进程是否内存溢出。

YGC与FGC。FGC是非常消耗系统性能的，且FGC时，进程是不工作的。

9、不同服务之间的通讯（消息服务器）

如用户下单的请求，这个请求要先经过商品集群，再经过订单集群，mq 或者Kafka等。需要关注消息服务器的排队情况等。

10、服务与数据库的交互（数据库连接池）

请求通过网络达到数据库服务，操作数据库。请求数量超过数据库连接池大小限制，请求排队

11、数据库对请求进行处理

redis缓存：失效时间、命中率、缓存穿透、缓存击穿等。

mysql缓存：mysql也是可以设置缓存的。命中缓存，则快速返回结果，否则去磁盘查询数据。

数据库主从读写分离：主库负责写数据，然后将变动，通过binlog同步到从库，从库负责查询数据。可能会同步延迟等问题

sql是否合理，执行时间&性能是否优秀

数据库表结构等设计是否合理。

四、定位性能问题方法

先排查最简单的，比如网络等问题，或者依据自己的经验，定位问题。

定位性能问题的整体思路：

1、画出系统架构图

2、根据系统架构图画出被测请求的数据流图

3、标记出数据流图中每个节点可能存在的性能瓶颈点

4、通过排除法排查

5、通过一系列埋点，快速定位问题的范围。

参考：

CDN详解_张孟浩_jay的博客-CSDN博客_cdn协议

tomcat最大线程数、最大等待数和最大连接数_卖栗的博客-CSDN博客_tomcat最大线程数

Rabbit mq 消息服务器（分布式中非常重要的服务器）_Mamba举个栗子的博客-CSDN博客_消息服务器

 https://www.jianshu.com/p/35878d4ec130

你真的会使用Jmeter吗（二）网络带宽影响测试数据_Garbage12的博客-CSDN博客