Jiangnan Jia
Jiangnan Jia
(同非官方 😄 ) > - 场景1: > 涉密或涉敏参数作为路由规则，放在 url、header、queryParams 等均不合适。如果进行`加解密/编解码`可以解决，但需要提供`加解密/编解码`算法 > - 场景2： > 如果需要将`body报文`通过业务逻辑算法后进行路由，那么通过简单的`规则匹配`以及`脚本`模式无法满足。当然这一层可以下沉到后端业务部分，但既然`opensergo`已经有路由功能，那么我觉得用户可能就不想要自己后端在加一层额外的路由层了。 > - 其他场景一时还没想到 > > > 关于性能问题，其实我也有想到。我的想法是 > 1. 应建议用户尽量优先使用`match`模式， > 2. `match`模式无法满足需求时，采用`action`模式 > >...
> Could you please reformat your code with goimports? fixed ! thanks for your review ~
关于 client 模型 的设计，需要关注以下几点： 1、shared 模型下，同一应用不同框架所引入的 OpenSergo SDK 对接的是否为同一个 OpenSergo Control Plane。 2、用户是否希望使用 share 模型 从这几点出发，share 模型 大致需要如下功能： 1、实例化 OpenSergoClient 实例的时候，需要辨别所要实例化的 OpenSergoClient 是否已存在(根据实例化参数判断)，如果存在，则进行复用，不存在则进行实例化。 2、添加 `client 模型` 的可选配置项，供用户自行选择是否启用 share 模型。（资源开销角度我们建议 shared...
你说的资源客户端，我理解的是在 OpenSergoClient 内部维护一个类似于缓存的结构，将不同数据面的订阅信息( SubscribeTarget 与 ConfigSubscriber )按数据面分组保存，与控制面交互的时候，将订阅信息遍历出来，但还是沿用原先的订阅通道进行交互，是这样吗？
嗯。我们 的 SDK 目前在 OpenSergoClient 内部本身已经维护了一个 SubscribeTarget 与 ConfigSubscriber 的缓存，在与 控制面交互的时候，也确实是 将其逐个来订阅的。只是这个模式其实只要做个简单改进：把 OpenSergoClient 做成单例 即 `shared模式`，就可以简单实现 单 OpenSergoClient 的复用了，但这样又会产生另一个问题，尽管`shared模式`性能表现良好，但并不是所有接入方都希望使用`shared模式`的 OpenSergoClient。 因此我们现在考虑的是： - `OpenSergoClient 模式多样化`。如果同个应用中的不同接入方有自己的需求，用户不希望与某个接入方与其他接入方共用一个 OpenSergoClient 时，怎么去实现。因此我们后续的规划是，默认采用并且也推荐用户使用`shared`模式，同时也提供`individual `模式。 - `OpenSergoClient 模式`引出的`如何提高...
> @FillZpp > > So we just have to wait for a new release tag of client-go, and then it can be used in c-r. > Yeah. I also has...
In most scenes, RouterTraffic CRs were defined in a certain application scope, so we have a convention that, the label `app` in CR is required. So in current version you...
LGTM, nice fix. cc @binbin0325
> Great !
> > What if the provided port is invalid? :) has improved, both host and port of endpoint will be checked