[Discussion] About add a customized match-action t for RouteRuleContext in RouterRule | 关于在 RouterRule 的 RouteRuleContext 中添加自定义流量匹配执行器的参数 about opensergo-specification HOT 7 OPEN

非社区官方人员，表达一下自己的看法。。

你的想法是流量路由规则在额外的工作负载中进行计算吧，我理解这样做会很影响请求的性能，尤其是在高并发的情况下，且自定义路由工作负载的稳定性会成为一个风险点。

我认为复杂的逻辑不应该放在路由规则这边，如果是复杂的打标逻辑，业务可以自己进行计算并在请求发起时携带自定义header，主动配合路由规则。

最后，在实际流量治理中，我是没遇到过特别复杂的路由规则，不知你遇到的复杂场景具体是什么样的场景，可以分享下，嘿嘿

from opensergo-specification.

关于匹配规则，目前我这边使用到的几种模式

• 等于
• 不等于
• 前缀匹配
• 后缀匹配
• 包含
• 正则匹配

其他能想到的可以扩展的模式的话，可以考虑比较运算，比如

• 大于
• 大等
• 小于
• 小等
• 整除
• 非整除
• ...

from opensergo-specification.

(同非官方 😄 )

• 场景1:
  涉密或涉敏参数作为路由规则，放在 url、header、queryParams 等均不合适。如果进行加解密/编解码可以解决，但需要提供加解密/编解码算法
• 场景2：
  如果需要将body报文通过业务逻辑算法后进行路由，那么通过简单的规则匹配以及脚本模式无法满足。当然这一层可以下沉到后端业务部分，但既然opensergo已经有路由功能，那么我觉得用户可能就不想要自己后端在加一层额外的路由层了。
• 其他场景一时还没想到

关于性能问题，其实我也有想到。我的想法是

1. 应建议用户尽量优先使用match模式，
2. match模式无法满足需求时，采用action模式

毕竟action模式中，无论 script 执行脚本或是workload 工作负载都会影响性能，所以最终是改造应用适应match还是牺牲性能采用action，交由用户自身考量

from opensergo-specification.

from opensergo-specification.

我的想法是这样的，社区或许可以内置一些常见的报文解析能力例如JSON、XML，同时也具备可扩展的能力。

http:
  - name: my-traffic-router-http-rule
    rule:
      match:
        body: 
         - type: json                        #报文取值方式，可扩展
            field: user.idcard             #取值表达式，实现通常可以是jsonpath、xpath
            exact: 12345
         - type: xml
            field: user.idcard
            exact: 12345 
         - type: custom
            field: user.idcard
            exact: 12345

现状：一个系统中的报文格式通常是比较固定的，而业务上将路由要素放在报文中的特定位置，在header、query、method中是没有什么有价值信息可作为路由要素的，需要业务开发者将报文解析并提取相关路由要素传递给路由组件。
预期：业务开发者不需要关心是依据什么业务字段进行路由，对业务开发者来说只是发起一个普通的请求。

from opensergo-specification.

(同非官方)

不建议在路由里面对报文进行解析，这对性能会产生比较明显的损耗。不过基于元数据部分（HTTP Header 等）我觉得是可以的。前面 @DC-ET 提到的一些字符串匹配模式都有必要，不过算数运算会涉及到把字符串数据进行类型转换，可能不太合适。

from opensergo-specification.

from opensergo-specification.