一、稳定性 - 保障策略
- 熔断：
-
- 熔断机制的工作原理：当检测到对某个服务的调用失败率达到一定阈值（比如连续多次失败）时，熔断开关打开，后续的请求将不再发送到该服务，而是直接返回一个预设的默认值或者执行降级逻辑。例如，在电商系统中，如果支付服务出现故障，可立即熔断对支付服务的调用，返回 “支付系统繁忙，请稍后重试” 的提示，同时引导用户使用其他支付方式或稍后再试。
-
- 熔断的恢复机制：不能一直处于熔断状态，需要在适当的时候进行恢复尝试。可以通过定期探测被熔断的服务是否恢复正常，当探测到连续多次成功的响应时，逐渐恢复对该服务的调用。比如每隔一段时间发送一个测试请求，如果连续几次测试请求都成功，就将熔断开关关闭，恢复正常的服务调用。
- 限流：
-
- 限流算法：常见的限流算法有令牌桶算法和漏桶算法。令牌桶算法是按一定的速率往桶里放入令牌，请求到来时如果桶中有令牌则可以通过，否则被拒绝。漏桶算法则是将请求放入一个固定容量的桶中，以固定的速率从桶中取出请求进行处理，超出桶容量的请求会被拒绝。例如，一个 API 接口每分钟只能处理 100 个请求，可以使用令牌桶算法，每秒放入 1.67 个令牌，当请求到来时如果有令牌则允许通过，没有令牌则拒绝。
-
- 限流的应用场景：可以对整个系统进行限流，防止系统因突发流量而崩溃；也可以对单个服务、接口甚至特定用户进行限流，以保证系统的公平性和稳定性。比如，对于一些恶意刷接口的用户，可以对其进行限流，限制其每秒只能发送少量请求。
- 超时控制：
-
- 超时时间的设置：超时时间需要根据具体的业务场景和服务性能来合理设置。如果设置得太短，可能会导致一些本来可以成功的请求被误判为超时；如果设置得太长，又会浪费资源在长时间等待不可用的节点上。可以通过对服务的历史响应时间进行统计分析，来确定一个合理的超时时间。例如，对于一个通常在 1 秒内响应的服务，可以设置超时时间为 2 秒，以应对一些偶尔的延迟。
-
- 超时后的处理策略：当请求超时时，可以选择立即返回错误信息给调用方，或者进行重试。如果选择重试，需要考虑重试的次数和间隔时间，避免因频繁重试而加重系统负担。比如，第一次超时后可以等待 100 毫秒后重试，第二次超时后等待 200 毫秒后重试，最多重试三次。
二、稳定性 - 请求成功率
- 负载均衡：
-
- 负载均衡算法：常见的负载均衡算法有轮询法、随机法、加权轮询法、加权随机法、最小连接数法等。轮询法是依次将请求分配到各个服务器上；随机法是随机选择一个服务器处理请求；加权轮询法和加权随机法是根据服务器的性能为服务器分配不同的权重，权重高的服务器被选中的概率更大；最小连接数法是将请求分配到连接数最少的服务器上。例如，有三个服务器 A、B、C，性能比为 1:2:3，可以使用加权轮询法，按照 1:2:3 的比例将请求分配到这三个服务器上。
-
- 软件负载均衡和硬件负载均衡：软件负载均衡可以通过在服务器上安装负载均衡软件来实现，如 Nginx、HAProxy 等；硬件负载均衡则是使用专门的硬件设备来实现，如 F5 负载均衡器。软件负载均衡成本较低，灵活性高，但性能可能不如硬件负载均衡；硬件负载均衡性能高，可靠性强，但价格昂贵。
- 重试：
-
- 重试的触发条件：可以根据错误类型、错误码或者连续失败次数等条件来触发重试。例如，如果是网络连接超时错误，可以立即触发重试；如果是业务逻辑错误，可能就不适合重试。
-
- 重试的间隔时间和次数：重试间隔时间可以采用指数退避算法，即每次重试的间隔时间逐渐增加，避免连续重试对系统造成过大压力。重试次数需要根据具体情况进行设置，不能无限重试。比如，第一次重试间隔 1 秒，第二次重试间隔 2 秒，第三次重试间隔 4 秒，最多重试三次。
三、稳定性 - 长尾请求
- Backup Request：
-
- 原理：当发现某个请求的响应时间过长时，启动一个备份请求发送到另一个相同服务的实例或者备份服务上。如果备份请求先返回结果，则使用备份请求的结果，丢弃原来的请求。这样可以避免用户长时间等待，提高系统的响应速度。
-
- 实现方式：可以通过在客户端或者中间件中实现 Backup Request 机制。在客户端实现时，需要在发送请求后启动一个定时器，当定时器超时后如果还没有收到响应，就发送备份请求。在中间件实现时，可以在请求经过中间件时进行监测，如果发现长尾请求就自动启动备份请求。
