Implement Envoy global rate limiting gRPC service with Sentinel cluster flow control

[sczyh30]

Issue Description

Type: feature request

Describe what feature you want

Envoy provides a global rate limiting gRPC service definition. We can implement the RLS with Sentinel cluster flow control (in Java) so service mesh that uses Envoy as data plane could take advantage of Sentinel.

Some design and refactor of cluster module might need be taken to adapt to service mesh and cloud native infrastructure. Discussions are welcomed.

Related to #200

[fg546300040]

目前同步请求ClusterTokenServer申请token，虚拟机会有C10K的瓶颈，只能适用于少量并发的场景。在高并发的场景应该采用起异步线程跟ClusterTokenServer通信（每隔100ms同步一次），在保证高性能的条件下实现集群流控。

总之，在原有的基础上，增加异步跟ClusterTokenServer通信（每隔100ms同步一次）可以满足高性能的集群流控了。

[sczyh30]

目前同步请求ClusterTokenServer申请token，虚拟机会有C10K的瓶颈，只能适用于少量并发的场景。在高并发的场景应该采用起异步线程跟ClusterTokenServer通信，在保证高性能的条件下实现集群流控。

总之，在原有的基础上，增加异步跟ClusterTokenServer通信可以满足高性能的集群流控了。

Token client 和 token server 的通信过程是异步的，只不过由于上层 SphU.entry(xxx) 调用模型是同步的所以在上层转成同步的了，这种情况下具体的吞吐量取决于通信的 RT 和调用端的并发线程数。

PS: we can discuss it in #200. This issue is for Envoy RLS integration :)

[fg546300040]

目前同步请求ClusterTokenServer申请token，虚拟机会有C10K的瓶颈，只能适用于少量并发的场景。在高并发的场景应该采用起异步线程跟ClusterTokenServer通信，在保证高性能的条件下实现集群流控。
总之，在原有的基础上，增加异步跟ClusterTokenServer通信可以满足高性能的集群流控了。

Token client 和 token server 的通信过程是异步的，只不过由于上层 SphU.entry(xxx) 调用模型是同步的所以在上层转成同步的了，这种情况下具体的吞吐量取决于通信的 RT 和调用端的并发线程数。

PS: we can discuss it in #200. This issue is for Envoy RLS integration :)

@sczyh30 嗯嗯， 每隔一个周期（比如100ms）跟server通信就基本满足高并发的集群流控的场景了。当然 如果有protocol序列化会更好。所以，我觉得重点是要周期性的跟server通信。

另外，我觉得采用P2P无中心的方式，即每个成员都有成为server的机会，每个成员定时的心跳，然后通过一致性hash的算法，计算各个资源集群流控的master。 提高系统的可靠性。 比如资源A的server可能是节点IP1，资源的server的server可能是节点IP2。

[rohanjulka19]

Hi, I want to work on this issue, I have already read about sentinel flow control, service mesh and envoy. I am still unable to understand how will this be implemented can you help me better understand it. Thank you

[sczyh30]

Architecture overview:

The initial version will include the Envoy RLS gRPC server implementation using the existing token server module. The RLS service implementation will leverage the existing flow rule managing and checking logic. To adapt to Envoy's "rate limit action", we propose the EnvoyRlsRule representation like this:

domain: example1
descriptors:
  - resources:
    - key: "destination_cluster"
      value: "svc-foo"
    count: 10

The domain and descriptor will match the counterpart in RateLimitRequest of RLS. Note that the first version can only support the exact "key-value" pair (i.e. exact resource name without params). We'll add support for "key-matching" scheme (i.e. parameter flow control) in next versions.

We need a converter to convert the EnvoyRlsRule to FlowRule. For cluster flow rule, we need to generate the ruleId for each FlowRule, which should be unique and consistent. We may use the hash code + offset by default.

As for configuration, we could support dynamic configuration from YAML file first. In the future, we could design K8S CRDs for rules so that we could update the rules via kubectl or other dashboards.