从微服务概念，电商项目举例，引入测试服务稳定性，思考①重试机制 ②限流 ③熔断机制 ④负载均衡 ⑤降级（本地缓存）_微服务重试场景
赞
踩
一、微服务
本文开场
先了解下微服务架构https://www.cnblogs.com/imyalost/p/6792724.html
总结：微服务就是将一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，从而降低系统的耦合性。
1.一个后端应用程序根据业务拆分为多个服务。举例：商品-订单-库存-营销-用户
2.前后端调用，一个前端同时调用N个后端服务。引入API Gateway
3.每个服务之间的通信，引入springboot原生https协议、dubbo、kafka/meteQ
4.单个服务的负载,引入zookeeper
二、电商项目微服务架构
https://blog.csdn.net/qq_44891295/article/details/108894864
- 首先我们的项目是前后端分离开发，我们分为内网部署和外网部署，外网就是面向公众访问的来部署前端项目可以由手机，电脑网站访问；内网部署的是我们整个后台集群；
- 公众使用客户端来完成我们相应的功能，比如登录，注册等都要向后台的服务来发送请求，但是请求都不是直接过来的；
- 我们发送请求的完整的流程应该是这样的，首先通过任意客户端来发送请求，请求先通过nginx集群，nginx把请求，先转交给API网关（Spring Cloud Gateway）网关可以根据当前请求，动态的路由到指定服务，看当前请求是想调用商品服务，还是购物车服务，还是检索服务，如果我们路由过来查询商品，但是商品服务很多，那么我们网关还可以负载均衡的来调用商品服务，例如当某个服务出现问题，我们还可以在网关这个级别来执行熔断和降级（SpingCloud Sentinel），我们网关还有认证授权，和令牌限流（限制我们的流量，比如有一百万个请求过来了，我们就可以只先放一万个过去）等功能；
- 当我们的请求通过网关到达服务的时候，我们的服务就进行处理（服务都是用Spring Boot写的）；服务与服务之间会互相调用，比如下订单的时候订单服务会调用商品服务，我们使用的是SpringCloud Feign组件；而且有些请求，我们需要登录以后才可以处理，所以我们还有一个基于OAuth2.0的认证中心，我们除了一般登录，还有社交登录（如微信），整个应用的安全和权限我们都使用里面的SpringSecurity进行控制；
- 我们这些服务需要保存一些数据，或者需要使用缓存等等，我们缓存使用的是Redis（分片集群和哨兵集群）；持久化存储数据，我们使用的是MySQL集群（可以做读写分离，或者分库分表）；我们还会使用消息队列，来完成异步解耦和分布式事务的最终一致性（使用RabitMQ消息队列）；我们有些服务需要检索商品信息就用到了ES；我们还要保存一些商品信息，我们就要用到aliyun的OSS；
- 包括在项目上线以后，我们为了快速定位我们出现的一些问题，我们就会使用ELK来对日志进行相关处理，也就是使用LogStash来收集各种日志，然后放入到ES中，在用Kibana可视化界面来从ES检索出相关的日志信息，来进行快速定位问题的所在。
服务都可以部署在很多台机器，而且服务与服务之间都会进行调用，那么我们就得知道服务彼此都在那里，我们推荐将所有的服务都要注册到注册中心，别的服务可以从注册中心中发现其他服务所在位置（使用SpringCloud Alibaba来作为注册中心和配置中心）； - 调用服务可呢会出现一个问题，比如下订单服务调用商品服务，商品服务在调用库存服务，可呢某一个链路出现了问题，我们就要追踪整个服务调用链，看下哪里出现了问题，我们可以使用服务追踪（SpringCloud Sleuth+Zipkin)把我们的服务的每一个信息来交给开源的Prometheus来进行聚合分析，再由Grafana进行可视化展示，通过Prometheus提供的Aitermansger得到我们服务的一些告警信息，这些告警信息可以以邮件，手机等方式告诉我们的开发运维人员；
- 我们还提供了持续集成和持续部署，由于我们的电商项目微服务众多，每一个都打包太麻烦了，有了持续集成，我们开发人员可以将修改后的代码提交给GitHub，运维人员可以通过Jenkins，从GitHub中获取到代码，将它打包成Docker镜像，最终我们使用Kuberneters，来集成整个Docker服务（以Docker容器的方式来运行）；以上就是我们整个微服务架构图的解释
通过电商项目举例微服务架构中，各服务间的依赖关系，手绘粗糙版
https://blog.csdn.net/qq_44891295/article/details/108894864
对整个分布式应用系统而言，一共分为两种调用，一种是同步调用，一种是异步调用。同步调用就是基于RPC，异步调用下单场景使用RocketMQ
三、服务稳定性
服务挂了，如何解决
前面提到，Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，
不过如果没有特别的保障，结局肯定是噩梦。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：
1. 重试机制
超时：
在微服务中，平常网络请求，或者与第三方系统进行交互都需要设置超时时间
设置超时的两个理由：
1. 系统自我保护： 快速失败，在业务最大允许等待时间内未收到返回数据，主动放弃等待，释放占用资源，避免请求不断累积带来的客户端雪崩效应
2. 成功率：服务处理超时原因有很多，但常见的超时都是短暂的，主要是GC，或者有网络抖动等。这些短时间影响服务端状态的情况而造成请求成功率下降，需要补救措施。简单的补救有超时重试操作：当前请求超时后，将会重试到非当前服务器，降低重试超时的机率
重试模式: 因某个服务实例短暂状态不佳而造成的超时，使用重试处理可以让请求转向其他服务实例的做法可以很好改善非集中式问题的成功率。
对于重试是有场景限制的，不是什么场景都适合重试，比如参数校验不合法、写操作等（要考虑写是否幂等）都不适合重试。
远程调用超时、网络突然中断可以重试。在微服务治理框架中，通常都有自己的重试与超时配置，比如dubbo可以设置retries=1，timeout=500调用失败只重试1次，超过500ms调用仍未返回则调用失败。
比如外部 RPC 调用，或者数据入库等操作，如果一次操作失败，可以进行多次重试，提高调用成功的可能性。
2. 限流
1)服务的入口的限流，在流量激增的情况下对流量进行控制；（上面提到过的网关层做处理）
使用限流例子：
- 突发热点事件（例如微博热搜）
- 爬虫
- 恶意攻击
- 恶意刷单（如12306）
2)当然还有一个情况就是，服务A在调用B，下游服务B只能抗住100的qps，在B服务不可用的情况下，需要限流，并进行熔断和降级（A调用B的出口返回默认的值）；（服务通信做处理）
场景的限流算法可以关注下：计数器算法、漏桶算法和令牌桶算法。
3. 熔断
设置服务的超时，当被调用的服务经常失败，到达某个阈值，我们可以开启断路保护机制，后来的请求不再去调用这个服务。本地直接返回默认的数据。
在微服务架构中，微服务之间是通过网络进行通信，存在相互依赖，当其中一个服务不可用时，就可能造成雪崩效应。要防止这样的情况，必须有容错机制来保护服务。
举个例子：在一个商品的系统中，有三个服务相互独立，并且存在三台不同的主机之上，分别为订单服务（A），商品服务(B)，库存服务(C ) 。当A接到一个下单的请求时，需要调B，而B此刻需要调C。然而C此时突然宕机了，引起了B的等待，B的等待同时引起了A的等待。如果此时等待的时间过长，在等待期间又会来其他的请求，这时候就会导致整个服务器的资源耗尽，进而导致雪崩。
5. 降级：
当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。
参考地址：https://blog.csdn.net/ityouknow/article/details/81230412
举个例子：假如目前有很多人想要给我付钱，但我的服务器除了正在运行支付的服务之外，还有一些其它的服务在运行，比如搜索、定时任务和详情等等。然而这些不重要的服务就占用了JVM的不少内存与CPU资源，为了能把钱都收下来（钱才是目标），我设计了一个动态开关，把这些不重要的服务直接在最外层拒掉，这样处理后的后端处理收钱的服务就有更多的资源来收钱了（收钱速度更快了），这就是一个简单的服务降级的使用场景。
