负载均衡 dubbo

1 自定义负载均衡 dubbo

在 Dubbo 中，用户可以自定义负载均衡策略以满足特定场景的需求。Dubbo 提供了扩展接口 com.alibaba.dubbo.rpc.cluster.LoadBalance 来支持自定义负载均衡算法。

要实现自定义的负载均衡策略，需要完成以下步骤：

1. 创建一个新的类，实现 LoadBalance 接口：

   Java

   1public class CustomLoadBalance implements LoadBalance {
   2    // 实现 choose 方法，该方法负责从 List<Invoker> 中选择一个 Invoker
   3    @Override
   4    public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException {
   5        // 在这里编写自定义的选择逻辑，根据 invokers 列表和调用信息来决定选择哪个服务提供者 Invoker。
   6        // ...
   7        return chosenInvoker;  // 返回选定的服务提供者 Invoker
   8    }
   9}
   

2. 配置自定义负载均衡器： 在 Dubbo 的消费者配置中，通过 loadbalance 参数指定自定义负载均衡策略：

   Xml

   1<dubbo:reference interface="com.example.YourService" id="yourService" loadbalance="custom"/>
   

   或在全局配置中设置：

   Xml

   1<dubbo:consumer loadbalance="custom"/>
   

3. 注册自定义的 LoadBalance 实现到 SPI (Service Provider Interface) 系统中：

   • 创建 META-INF/dubbo/com.alibaba.dubbo.rpc.cluster.LoadBalance 文件，并在其中写入你的自定义负载均衡器类名。
   • 文件内容示例：
     Code

     1custom=com.yourcompany.dubbo.CustomLoadBalance
     

4. 最后确保自定义的 CustomLoadBalance 类被打包并在客户端和服务端（如果需要的话）都可用。

这样，在运行时，Dubbo 将会根据配置使用你自定义的负载均衡策略进行服务提供者的选取。

https://blog.51cto.com/c959c/5332475

2 规则引擎设计方案

规则引擎是一种软件系统，它允许非程序员用户通过高级别、易于理解的语义定义和管理业务规则，并将这些规则应用于复杂的数据处理中。设计一个规则引擎方案通常涉及以下几个核心组成部分：

1. 规则定义与存储：

   • 规则需要以一种结构化的方式编写和存储，这可以是基于XML、JSON或特定DSL（领域特定语言）。
   • 规则库用于存放所有有效的业务规则，支持版本控制和生命周期管理。

2. 规则解析与执行引擎：

   • 解析器负责读取并解释规则定义，将其转化为可执行的形式。
   • 执行引擎根据事实数据集和触发条件执行匹配的规则，并决定规则执行顺序（例如，优先级或冲突解决策略）。
   • 引擎能够处理简单规则（如IF-THEN）到复杂的决策表、决策树甚至基于逻辑推理的规则。

3. 事实对象与工作内存：

   • 事实对象是应用规则的对象实例，它们的状态变化会被规则引擎检测到并据此执行规则。
   • 工作内存作为规则引擎运行时的一个临时区域，存储当前要处理的事实对象集合。

4. 事件驱动机制：

   • 规则引擎通常设计为事件驱动，当业务系统的状态发生变化时，会触发规则引擎检查相关规则是否满足执行条件。

5. 决策服务接口：

   • 提供对外暴露的API，使得业务系统可以通过调用接口来触发规则执行，获取执行结果或者更新业务状态。

6. 监控与日志记录：

   • 实现对规则执行过程的跟踪、审计和性能监控，便于排查问题及优化规则体系。

7. 集成与扩展性：

   • 考虑如何将规则引擎无缝地嵌入现有IT架构中，包括与其他系统和服务的交互，以及对新类型规则的支持和扩展能力。

8. 安全性与权限管理：

   • 确保只有授权用户能够创建、修改或删除规则，并对规则操作进行记录和审核。

在具体实施过程中，可以选择开源的规则引擎产品（如Drools、JBoss Rules、Apache JEXL等），也可以根据需求自研规则引擎组件。同时，设计时还要充分考虑性能、可维护性和易用性等因素。

3 限流 熔断 降级的区别

限流、熔断和降级是分布式系统中用来保护服务稳定性、防止雪崩效应以及优化用户体验的几种关键策略，它们在不同层面上针对不同的问题，有着各自的侧重点：

1. 限流（Rate Limiting）：

   • 作用：主要为了控制请求流量，防止短时间内涌入过多请求导致系统资源耗尽。例如，当系统的处理能力达到阈值时，通过限制单位时间内能够处理的请求数量来保证系统的稳定运行。
   • 实现方式：常见的限流算法有令牌桶算法、漏桶算法等，可以通过中间件如API Gateway或者服务端内部逻辑来实施。

2. 熔断（Circuit Breaker）：

   • 作用：当依赖的服务出现故障或者响应时间过长时，为避免连锁故障及大量资源浪费，熔断机制会暂时阻止对故障服务的所有后续调用，并快速失败，从而保护整个系统不受影响。
   • 工作流程：当某个服务连续多次失败或超时后，熔断器切换到“开路”状态，这时所有对该服务的请求都会被立即拒绝或返回默认结果；在一段时间窗口过后，熔断器会进入半开状态尝试恢复调用以检查服务是否已经恢复正常，如果成功则关闭熔断，否则继续保持开路状态。

3. 降级（Degradation）：

   • 作用：在系统压力过大或者部分功能不可用的情况下，牺牲掉一些非核心功能或降低服务质量，优先保证核心业务的正常运行。降级可以是对用户可见的，比如只提供基本功能，隐藏高级特性；也可以是内部的，比如将原本依赖于其他服务的功能简化处理或采用备选方案。
   • 策略：降级策略可能包括缓存替代实时计算、不加载部分静态资源、使用本地数据而非远程服务等。降级可以在设计之初就进行预案设定，在特定条件下自动触发执行。

总结来说，三者的主要区别在于：

• 限流侧重于预防系统过载，通过对请求流量的控制来维护整体性能；
• 熔断是一种服务间故障隔离手段，目的是防止因依赖服务故障导致主服务跟着崩溃；
• 降级则是面对资源紧张或故障时的一种妥协措施，旨在保证核心业务不受影响的同时，暂时牺牲非关键功能的质量或可用性。