SA实战 ·《SpringCloud Alibaba实战》第9章（一）

大家好，我是冰河~~

在《SpringCloud Alibaba实战》专栏前面的文章中，我们实现了用户微服务、商品微服务和订单微服务之间的远程调用，并且实现了服务调用的负载均衡。但是，现在系统中存在着一个很明显的问题，那就是如果系统的并发量上来后，系统并没有容错的能力，这可能会导致系统不可用或者直接宕机，所以，我们的系统需要支持容错的能力。

本文主要内容如下所示。

并发对系统的影响
当一个系统的架构设计采用微服务架构模式时，会将庞大而复杂的业务拆分成一个个小的微服务，各个微服务之间以接口或者RPC的形式进行互相调用。在调用的过程中，就会涉及到网路的问题，再加上微服务自身的原因，例如很难做到100%的高可用等。如果众多微服务当中的某个或某些微服务出现问题，不可用或者宕机了，那么其他微服务调用这些微服务的接口时就会出现延迟。如果此时有大量请求进入系统，就会造成请求任务的大量堆积，甚至会造成整体服务的瘫痪。

压测说明
为了更加直观的说明当系统没有容错能力时，高并发、大流量场景对于系统的影响，我们在这里模拟一个并发的场景。在订单微服务shop-order的io.binghe.shop.order.controller.OrderController类中新增一个concurrentRequest()方法，源码如下所示。

@GetMapping(value = "/concurrent_request")
public String concurrentRequest(){
    log.info("测试业务在高并发场景下是否存在问题");
    return "binghe";
}

接下来，为了更好的演示效果，我们限制下Tomcat处理请求的最大并发数，在订单微服务shop-order的resources目录下的application.yml文件中添加如下配置。

server:
  port: 8080
  tomcat:
    max-threads: 20

限制Tomcat一次最多只能处理20个请求。接下来，我们就使用JMeter对 http://localhost:8080/order/submit_order 接口进行压测，由于订单微服务中没有做任何的容错处理，当对 http://localhost:8080/order/submit_order 接口的请求压力过大时，我们再访问http://localhost:8080/order/concurrent_request 接口时，会发现http://localhost:8080/order/concurrent_request 接口会受到并发请求的影响，访问很慢甚至根本访问不到。

压测实战
使用JMeter对 http://localhost:8080/order/submit_order 接口进行压测，JMeter的配置过程如下所示。

（1）打开JMeter的主界面，如下所示。

（2）在JMeter中右键测试计划添加线程组，如下所示。

（3）在JMeter中的线程组中配置并发线程数，如下所示。

如上图所示，将线程数配置成50，Ramp-Up时间配置成0，循环次数为100。表示JMeter每次会在同一时刻向系统发送50个请求，发送100次为止。

（4）在JMeter中右键线程组添加HTTP请求，如下所示。

（5）在JMeter中配置HTTP请求，如下所示。

具体配置如下所示。

• 协议：http
• 服务器名称或IP：localhost
• 端口号：8080
• 方法：GET
• 路径：/order/submit_order?userId=1001&productId=1001&count=1
• 内容编码：UTF-8
  （6）配置好JMeter后，点击JMeter上的绿色小三角开始压测，如下所示。

点击后会弹出需要保存JMeter脚本的弹出框，根据实际需要点击保存即可。

点击保存后，开始对 http://localhost:8080/order/submit_order 接口进行压测，在压测的过程中会发现订单微服务打印日志时，会比较卡顿，同时在浏览器或其他工具中访问http://localhost:8080/order/concurrent_request 接口会卡顿，甚至根本访问不到。

说明订单微服务中的某个接口一旦访问的并发量过高，其他接口也会受到影响，进而导致订单微服务整体不可用。为了说明这个问题，我们再来看看服务雪崩是个什么鬼。

文章转自公众号：冰河技术