SpringCloud参数优化以及高可用优化

一、SpringCloud参数优化

场景：

压测一个原先⼀个服务 A 的实例⾥，专⻔调⽤服务 B 的那个线程池⾥的线 程，总共可能就⼏⼗个。每个线程调⽤服务 B 都会卡住 5 秒钟。如果每秒钟过来⼏百个请求这个服务实例呢？⼀下⼦B服务那个线程池⾥的线程就全部 卡死没法再响应任何请求了。

优化步骤：

（1）优化核⼼服务 B 的性能。不要⽤上百⾏的⼤ SQL，多表关联，那样单表⼏百万⾏数据量的话，会导致⼀下执⾏好⼏ 公众号：石杉的架构笔记秒。 其实最佳的⽅式，就是对数据库就执⾏简单的单表查询和更新，然后复杂的业务逻辑全部放在 java 系统中来执⾏，⽐如⼀些关联，或者是计算之类的⼯作。

（2）如果⼀个接⼝响应时间达到 1 秒 以上，考虑⽤缓存、索引、NoSQL 等各种你能想到的技术⼿ 段，优化⼀下性能。通过设置ribbon 和 hystrix 的超时时间设置治标不治本，到这一步，不会出现 hystrix 线程池频繁卡死的情况了。

（3）如果超时时间设置成了 1 秒，如果就是因为偶然发⽣的⽹络抖动，导致接⼝某次调⽤就 是在 1.5 秒呢？这个是经常发⽣的，因为⽹络的问题，接⼝调⽤偶然超时，所以此时配合着超时时间，⼀般都会设置⼀个合理的重试。设置重试之后，Spring Cloud 中的 Feign + Ribbon 的组合，在进⾏服务调⽤的时候，如果发 现某台机器超时请求失败，会⾃动重试这台机器，如果还是不⾏会换另外⼀台机器重试。 这样由于偶尔的⽹络请求造成的超时，不也可以通过⾃动重试避免了。

（4）设置了重试，需要考虑接⼝的幂等性保障，比如接⼝重试了好⼏次，结果复插⼊了多条数据就业务错误了。幂等性保证有以下几种方式：

• 可以在数据库⾥建⼀个唯⼀索引，插⼊数据的时候如果唯⼀索引冲突了就不会插⼊重复数 据 或者是通过；
• redis ⾥放⼀个唯⼀ id 值，然后每次要插⼊数据，都通过 redis 判断⼀下，那个 值如果已经存在了，那么就不要插⼊重复数据了。

 

二、SpringCloud高可用优化

2.1、保障⾼可⽤的措施，就是两点

• ⼀个是基于 Hystrix 做资源隔离以及熔断；
• 另⼀个是做备⽤降级⽅案

场景：

核⼼服务 A 调⽤了核⼼服务 B 和 C，在核⼼服务 B 响应过慢时，会导致核⼼服务 A 的 某个线程池全部卡死。但是此时因为⽤了 hystrix 做了资源隔离，所以核⼼服务 A 是可以正常调⽤服务 C 的，那么就 可以保证⽤户起码是可以使⽤ APP 的部分功能的，只不过跟服务 B 关联的⻚⾯刷不出来，功能 ⽆法使⽤罢了。

如何优化：

• 要保证⼀个 hystrix 线程池可以轻松处理每秒钟的请求；
• 同时还有合理的超时时间设置，避免请求太慢卡死线程

2.2、如何设置hystrix线程池大小

场景：

假设服务 A，每秒钟会接收 30 个请求，同时会向服务 B 发起 30 个请求，然后每个请求的 响应时⻓经验值⼤概在 200ms，那么 hystrix 线程池需要多少个线程呢？

计算公式是：30（每秒请求数量） * 0.2（每个请求的处理秒数） + 4（给点缓冲buffer) = 10（线程数）

为什么 10 个线程可以轻松抗住每秒 30 个请 求？：

⼀个线程 200 毫秒可以执⾏完⼀个请求，那么⼀个线程 1 秒可以执⾏ 5 个请求，理论上，只要 6 个线程，每秒就可以执⾏ 30 个请求。 也就是说，线程⾥的 10 个线程中，就 6 个线程⾜以抗住每秒 30 个请求了。剩下 4 个线程都在 玩⼉，空闲着。 那为啥要多搞 4 个线程呢？很简单，因为要留⼀点buffer空间。

万⼀在系统⾼峰期，系统性能略有下降，此时不少请求都耗费了 300 多毫秒才执⾏完，那么⼀ 个线程每秒只能处理 3 个请求了，10 个线程刚刚好勉强可以 hold 住每秒 30 个请求。所以你必 须多考虑留⼏个线程。

2.3、服务降级

1. 如果你的某个服务挂了，那么你的 hystrix 会⾛熔断器，然后就会降级，需要考虑到各个服务 的降级逻辑
2. 如果写⼊数据的服务挂了，你可以先把这个写⼊操作记录⽇志到⽐如 mysql ⾥，或者写⼊ MQ ⾥，后⾯再慢慢恢复；
3. 如果 redis 挂了，你可以查 mysql；
4. 如果 mysql 挂了，你可以把操作⽇志记录到 es ⾥去，后⾯再慢慢恢复数据；
5. 最后，给个友好提示。