penbox2023-07-02 来自四川在负载均衡和熔断两节课都提到了一个关键点，如何判断一个服务是否处于健康状态，这方面你有什么自己的思考？ 学习了目前这两节课，我感觉服务端节点目前是什么状态，都是靠猜测或试探来得到的。 在负载均衡算法里面，靠连接数或响应时间来判断服务器权重，这两个指标都是客户端对服务端状态的猜测，并不是服务端的真实情况。动态调整权重里面的成加败减，要反复试探多次，才能把权重调整为正确的服务端状态。 在熔断这里，熔断之后到底恢复没有，不管是服务端和客户端都不知道，只能放点流量过去试一试。 目前好像还缺少手段来判断服务端当前的真实情况。有没有可能类似注册中心一样，在微服务框架中引入一个”健康中心“。每个服务端根据若干个指标，对自己打一个分，定时上报给健康中心。不管是客户端还是服务端自己，发现不对劲的时候，去健康中心里找到服务端对应的分数，就能直接判断出这个服务端的真实情况。作者回复: 赞！基本上就是靠猜和试探，试探也是固定套路，你已经总结得很对了。 你考虑得非常深远了。 这种健康中心的想法应该说之前也有人探讨过，后来就是发现监控做得好，不太需要这么一个健康中心。比如说我们的监控都会采集各个机器的 CPU，内存之类的东西。 所以现在其实是缺了一个能够综合运用各种监控指标打分的东西，但是一直以来也没有谁研究出来了通用的打分机制——适合各种业务的打分机制。 早期我还想过，能不能借助 AI 来学习人判断节点是否健康的思路，然后让 AI 来监控、打分、执行容错。还可以进一步整合日志分析、流量预判等，做得非常高级。 当然，这都是吹牛逼，我稍稍尝试过就放弃了。
共 3 条评论6
小手冰凉*^O^*2023-06-21 来自北京老师好，业界好的熔断方案都是怎么做的呢？作者回复: 现在的主流是根据错误率来判断要不要熔断，这个错误可以是业务错误，也可以是系统错误（比如中间件本身的错误）。当错误率比较高的时候就会触发熔断。 我之前就用过这种策略，比较好实现。
共 2 条评论4
Bin2023-06-28 来自广东What : 什么是「熔断」 在微服务架构里面是指当微服务本身出现问题的时候，它会拒绝新的请求，直到微服务恢复。 Why：微服务架构为什么要使用「熔断」 可以给服务端恢复的机会 个人理解： 「熔断」机制就是在系统高负载/ 服务崩溃的时候，拒绝新的请求。相当于提供给服务/系统一段“喘息”时间，“喘息”时间的意义在于： 1. 服务端不再接受新请求，服务的负载可以降低下来，防止服务雪崩 2. 服务端崩溃的情况下，可以重启服恢复务，可以理解为是一种故障转移（failover）手段 3. 上游服务收到「熔断」信息返回，可以进行兜底方案处理：例如业务补偿、请求转发、同步转异步等 When：什么时候进行和结束「熔断」 微服务本身「出现问题」的时候 「熔断」的开始和结束时机判断就在于以下问题的判断： 1. 判断微服务出现问题 2. 判断微服务恢复服务 「熔断」开启：判断出现问题 判断健康状态 1. 选择业务「指标」 每个微服务实际上都是附带着业务属性（微服务的划分是根据业务的职责和边界来划分） 所以可以根据业务来选择「指标」来代表微服务的健康状态。 常见的指标可以是：「响应时间的99线」，「错误率」等 2. 设置合适的「阈值」 这也是根据业务来决定的。 假设我们选择「响应时间」作为指标。 ● 根据业务要求的「指标」阈值设置 ● 观察业务整体的「指标」来设置 3. 设置持续多长时间才触发「熔断」 需要持续一段时间之后才触发「熔断」，因为： ● 防止「指标」 偶发性的突然增长 ● 防止「服务抖动」 「持续时间」的设置，依赖个人经验 「熔断」结束：判断恢复服务 现状：大多数是触发「熔断」后保持「一段时间」，就认为服务已经恢复正常，继续处理新请求 存在的问题：「抖动」 解决方案： 1. 「服务端控制流量」：恢复服务之后，比如说10%，20%逐步递增，不是100%恢复流量 这种做法不够好。依旧有请求因为熔断不会被处理。 2. 「客户端控制流量」：服务端熔断后，客户端不再请求这个节点，而是换一个节点。恢复之后，客户端逐步放开流量 亮点方案：客户端结合「负载均衡」控制流量，解决「抖动」问题 Question 面试中，经常在你讲完一些场景解决方案之后，面试官就会问你有自己实现吗？或者有没有落地在自己的项目中？如果回答有，面试官就会问遇到过什么问题没有？你回答没有，感觉自己给面试官的感觉又只是停留在理论上，没有实践经验。想问老师，对于类似这些问题，应该怎么去破局呢？展开作者回复: 我愿称你为课代表，总结太强了！ Question：其实我在面试的也会有这种困境，毕竟有些业务我确实没有解决过，只是听说过。 这里要分情况讨论： 1. 面试官问的场景是你确实要解决的，不过你用了 A 方案，但是你面试的时候还回答了 B，C 方案。这种，我一般就是先讲自己的 A 方案，讲完之后看情况，要是面试官觉得 A 不符合口味，就接着讲自己了解的 B 方案和 C 方案。正常来说，在做方案选型的时候，我多半比较过 B 和 C，但是最终选了 A。我只需要讲完 B C 之后讲一下自己当初的决策理由就可以。因为本身我落地的是 A，B 和 C 被我放弃了，问题也不太大。 2. 如果是这个场景跟我业务没有关系，比如说我的项目经历是支付方向，问我的场景是订单方向，我也就只能把公司的解决方案拿出来说说。问到一些答不出来的细节很正常，毕竟我项目经历又不是这个地方的。不过一般要避免面试官不按套路出牌，也就是最好别让自己陷入这种境地。 你在面试前，可以提前准备一下各种方案，包括如果真落地可能遇到什么问题，又或者你去搜搜业界落地的技术博客，也能回答上来一些细节性的问题。
3
xyu2023-06-29 来自浙江为什么说客户端利用负载均衡来控制流量相比服务端逐步放开流量是亮点方案？ 我说一下我的理解，不知道对不对： 从整个系统来看，使用客户端控制流量的方案使得整个系统的可用性更好；客户端通过调用返回情况来调整权重，交互的过程实际上也是一个考察对方恢复情况的过程，然后根据你的恢复情况来加大流量，从而避免服务器又再次陷入熔断；如果使用服务端逐步放开流量的方案，机械地按比例的放开很可能会让服务器再次陷入熔断。作者回复: 对的！按比例是偷懒的做法，你讲的这是基于反馈的流量恢复，是更加高级的方案。
共 2 条评论2- TimJuly2023-06-28 来自北京引申一个问题，发现故障时（可能是自身引起，也可能是下游引起），怎么判断是单机故障还是集群故障
作者回复: 严格来说，如果你的异常机制（Go 中的错误机制）设计得好，你是知道的。比如说，你们有严格的错误码机制，每一个业务都有自己的错误码前缀，那么你根据错误码就知道究竟是谁出错了，也就是你能区别是自身、还是下游。 而如果没有这种机制，你基本上判断不出来是自身，还是下游引起的。这时候对你来说已经不重要了，你直接将自身熔断了就可以。 而单机故障还是集群故障，你站在调用者角度永远都是认为下游是单机故障。比如说 A 调用 B，如果 A 调不通，它只会认为是它调用的 B 的那个节点崩了，而不会认为 B 整个集群都崩了。 集群故障是需要第三方来监控的。比如说你有 prometheus 监控，你发现所有的节点都各种超时，或者异常很多，这样你才能判定是整个集群都出问题了。 如果你利用的是负载均衡 fail-over 机制，或者你的客户端会给服务端发送心跳，那么服务端所有节点都调不通，也可以认为是集群崩溃了。
2 
牧童倒拔垂杨柳2023-08-14 来自河北在负载均衡和熔断两节课里面都提到一个关键点，即如何判定一个服务是否处于健康状态，这方面你有什么自己的思考？ 这个关键点是服务端都相对被动，都需要等待客户端或者其他服务来检测状态 在负载均衡中，静态负载均衡算法是不考虑服务端的状态的，算法决定选谁就是谁，所以会出现各个服务端节点负载不可控的情况。动态负载均衡算法会去探测服务端状态，最少连接数是看连接数量，最少活跃请求是客户端看有多少请求还没回来，最短响应时间是客户端观察平均最短响应时间，在几种算法中，服务端都相对被动，不能主动做什么 在熔断这一课中也是这样，在熔断恢复时，不管是服务端控流量，还是客户端控流量，都是服务端基本都是被动等待 所以我在思考是不是可以借鉴负载均衡课程中的亮点方案，在某个服务端节点熔断之后，客户端收到熔断请求，此服务端节点被移出可用列表，此服务端节点在注册中心肯定也是不可用的，那么是不是可以谁都不去探测，等服务端恢复后，主动向注册中心上报自己恢复了。客户端要做的是等待一段时间后，定时向注册中心询问，某个服务端节点是不是恢复了。如果注册中心出问题了，这个时候客户端是一定要根据可用节点列表探测服务端是否可用的，顺带着就可以把触发熔断的服务端节点探测一下展开作者回复: 是的，熔断也可以这么做。应该说，熔断、限流、降级都可以这么做。推而广之，任何原因导致服务端不可用，或者说有性能问题，都可以在负载均衡里面的将它暂时挪出可用列表。
1
小晨2023-07-04 来自江苏是否存在这种场景，通过客户端控制流量，熔断某个服务，将原本应该给这个服务的流量给其他节点，导致其他节点因为流量增加也导致也触发熔断，即原本可能只要熔断一个节点，但因为这个节点熔断了，流量分给了其他节点，其他节点的压力增加，进而触发熔断，造成"雪崩"？作者回复: 会！你已经领悟到了面试另外一个可以提及的亮点。正常来说，你后端的节点处理能力是有冗余的，那么一两个节点熔断，这些冗余的处理能力刚好够用。 但是如果你要是大部分节点都已经快要撑不住流量了，那么你这时候一两台机器熔断，就会导致其它节点也撑不住。 所以这种流量的场景，用限流会更好。
1- Geek_9487402023-06-27 来自浙江同问 这篇文章里的客户端是指什么 app和电脑的话做这些策略成本很高吧
作者回复: 这里的客户端基本上都是指服务调用中的客户端。比如说 A 调用 B 的接口，那么 A 就是客户端。 整个专栏，基本上都是这种语义，如果是APP 之类的，我一般都会直接说 APP，或者用户。
1 
码小呆2023-06-24 来自广东我们是夜莺,上面写一个监控脚本,定时去请求对应服务的接口,一旦有服务请求不通过,就在群里实现告警,不过,如果公司的项目都上了prometheus ,一旦流量请求出现问题,就直接在企微群发送告警,这样子应该也是可以的作者回复: 赞！确实可以的。不过面试的时候你还可以讲讲你们公司有没有什么自动处理告警的机制。因为有些故障是可以通过程序来恢复的。 不过你们的真的是服务一不通就告警吗？还是说会有考虑一分钟多少次调不通才告警？
共 3 条评论1
hurrier2023-06-21 来自广东大明老师 如果请求下流qps很低 比如几分钟才请求一次 按错误率、响应时间熔断感觉都不准确，有更好的方案吗作者回复: 第一种思路是按错误类型。这个可以是跟业务相关的，也可以是跟业务没关的。比如说当你发现返回了某一个特定的错误（或者异常），就认为系统本身出了故障，那么就可以触发熔断。 第二种思路是检测业务关键路径上的依赖。比如说你严重依赖于某一个中间件，例如 Redis，那么当你发现 Redis 连不上，比如说心跳已经 ping 不通了，那么就可以触发熔断（后面学了降级，你就应该考虑应该尽可能先降级）。 QPS 很低的话，你加一个限流会更好，防止突发流量。
共 2 条评论1