Azure Service Bus消息过滤能否自定义实现RuleFilter规则

你当前自定义RuleFilter实现Lambda过滤的方案完全不可行，从Azure Service Bus的运行机制上就走不通。

核心原因 #

Azure Service Bus的订阅过滤规则是在服务端Broker节点执行的，不是在你的客户端应用进程里执行：

• 内置的SqlRuleFilter、CorrelationRuleFilter会被SDK序列化成服务端可识别的标准规则格式，随创建订阅/规则的请求发送给服务端，消息到达topic后，服务端直接在本地完成规则匹配，只会把匹配通过的消息投递给对应订阅。
• 你自定义的ConditionalFilter里存储的是C#内存中的委托对象，这个委托既不能跨进程序列化传输到Service Bus服务端，服务端也没有执行你自定义C#逻辑的运行环境，SDK在提交规则请求时遇到未知的过滤器类型会直接抛出序列化异常，规则根本创建不成功。

你当前实现代码里的显性问题 #

就算不考虑服务端不支持的核心问题，代码本身也有明显错误：

• 泛型委托定义写反了：Func<bool, T>代表入参是bool类型、返回值是T类型，和你要做「传入消息对象返回是否匹配的布尔值」的需求完全相反，正确的委托类型应该是Func<T, bool>。
• 你没有重写GetHashCode方法，两个逻辑等价的自定义过滤器实例会被判断为不相等，后续做规则更新、查重的时候会出现异常。

可行的替代方案 #

如果你想保留Lambda编写过滤规则的开发体验，有两种可落地的路径：

1. 做表达式树转译（推荐）
   不要自定义RuleFilter子类，写一层工具方法接收Expression<Func<T, bool>>类型的Lambda表达式树（注意是表达式树不是普通委托），在客户端侧把表达式树解析转换成SqlRuleFilter支持的SQL过滤语法，最终生成SDK内置的SqlRuleFilter实例提交给服务端。
   比如你写的prod => prod.Price > 1000.00m，解析后可以直接生成等价的new SqlRuleFilter("Price > 1000")，既保留了Lambda的强类型编写体验，又完全兼容服务端的过滤执行逻辑，没有额外的性能和成本损耗。
2. 客户端侧二次过滤（不推荐大流量场景用）
   给订阅配置默认的TrueRuleFilter，让服务端把所有消息都投递到当前订阅，客户端收到消息反序列化为对应类型后，再执行你写的Lambda判断，不符合条件的消息直接放弃处理。
   这种方案实现简单，但会拉取所有不相关的消息到本地，会产生额外的消息吞吐费用、占用网络带宽，消息量大的时候性能和成本损耗非常明显。

内容的提问来源于stack exchange，提问作者user2896152