search

fanliang11 / surging

Surging is a micro-service engine that provides a lightweight, high-performance, modular RPC request pipeline. support Event-based Asynchronous Pattern and reactive programming ,The service engine supports http, TCP, WS,Grpc, Thrift,Mqtt, UDP, and DNS protocols. It uses ZooKeeper and Consul as a registry, and integrates it. Hash, random, polling, Fair Polling as a load balancing algorithm, built-in service governance to ensure reliable RPC communication, the engine contains Diagnostic, link tracking for protocol and middleware calls, and integration SkyWalking Distributed APM
MIT License
3.24k stars 924 forks source link

请问surging如何支持全网限流一致性的？ #357

Open sd797994 opened 5 years ago

sd797994 commented 5 years ago

举个例子，假设我有某服务A我设置了限流1000次/秒。当我的服务B调用服务A时，理论上来说当前这一秒内A的全网可访问承载就变成了999，我看了很多针对.net的限流熔断的文章，几乎都是拿着polly的几个基础特性在说，没有涉及到分布式环境下的全网限流。其他的分布式框架，比如dubbo我大概知道它是会实时的将调用情况通过dubbo协议推送到zookeeper，加上zookeeper本身的CP特性，就可以保证全网限流的一致性，其他服务在调用这个限流服务时可以实时获取到真实有效的剩余流量来进行调用/限流。我就想问问surging在这一方面是怎么设计的呢

29360068 commented 5 years ago

举个例子，假设我有某服务A我设置了限流1000次/秒。当我的服务B调用服务A时，理论上来说当前这一秒内A的全网可访问承载就变成了999，我看了很多针对.net的限流熔断的文章，几乎都是拿着polly的几个基础特性在说，没有涉及到分布式环境下的全网限流。其他的分布式框架，比如dubbo我大概知道它是会实时的将调用情况通过dubbo协议推送到zookeeper，加上zookeeper本身的CP特性，就可以保证全网限流的一致性，其他服务在调用这个限流服务时可以实时获取到真实有效的剩余流量来进行调用/限流。我就想问问surging在这一方面是怎么设计的呢

1、可以分享一下全网限流的原因吗？ 2、如果服务A限流1000次/秒，在服务A处，在达到限流条件时，根据规则快速的将额外的调用失效/抛弃/异常掉，就已经实现限流了

fanliang11 commented 5 years ago

你这个属于中心化架构的服务限流，这个也很好实现，使用令牌桶算法就行，但是针对于分布式，去中心化是不能使用这种方式的。限流是限制单台最大的请求。你可以水平扩展加机器，可以水平扩展切分数据库，加服务器

sd797994 commented 5 years ago

举个例子，假设我有某服务A我设置了限流1000次/秒。当我的服务B调用服务A时，理论上来说当前这一秒内A的全网可访问承载就变成了999，我看了很多针对.net的限流熔断的文章，几乎都是拿着polly的几个基础特性在说，没有涉及到分布式环境下的全网限流。其他的分布式框架，比如dubbo我大概知道它是会实时的将调用情况通过dubbo协议推送到zookeeper，加上zookeeper本身的CP特性，就可以保证全网限流的一致性，其他服务在调用这个限流服务时可以实时获取到真实有效的剩余流量来进行调用/限流。我就想问问surging在这一方面是怎么设计的呢

1、可以分享一下全网限流的原因吗？ 2、如果服务A限流1000次/秒，在服务A处，在达到限流条件时，根据规则快速的将额外的调用失效/抛弃/异常掉，就已经实现限流了

主要的问题还是在于数据库层面上，其实就应用本身来讲做无状态的横向扩容很方便也没有什么成本特别是通过容器编排这样的运维架构来讲。但是数据库不一样。大部分服务不管怎么做集群部署，它们本质上还是会连同一个数据库。数据库不管怎么主从分离也好，集群复制也好。或者采用缓存/搜索引擎来作为承载也好，它始终有一个绝对的上限。所以数据层面瓶颈就决定了应用的上限不管应用部署多少个节点。所以反过来又说假设A部署100个节点做成集群。但是A连接的数据层只能提供10W并发。那我100个节点应该是共享这10W并发做限流的。而不是每个节点设计一个值去限流。所以传统的中心化的分布式框架会采用中心化的配置中心来处理限流比如springcloud会依赖eureka、dubbo会依赖zk。

fanliang11 commented 5 years ago

举个例子，假设我有某服务A我设置了限流1000次/秒。当我的服务B调用服务A时，理论上来说当前这一秒内A的全网可访问承载就变成了999，我看了很多针对.net的限流熔断的文章，几乎都是拿着polly的几个基础特性在说，没有涉及到分布式环境下的全网限流。其他的分布式框架，比如dubbo我大概知道它是会实时的将调用情况通过dubbo协议推送到zookeeper，加上zookeeper本身的CP特性，就可以保证全网限流的一致性，其他服务在调用这个限流服务时可以实时获取到真实有效的剩余流量来进行调用/限流。我就想问问surging在这一方面是怎么设计的呢

1、可以分享一下全网限流的原因吗？ 2、如果服务A限流1000次/秒，在服务A处，在达到限流条件时，根据规则快速的将额外的调用失效/抛弃/异常掉，就已经实现限流了

主要的问题还是在于数据库层面上，其实就应用本身来讲做无状态的横向扩容很方便也没有什么成本特别是通过容器编排这样的运维架构来讲。但是数据库不一样。大部分服务不管怎么做集群部署，它们本质上还是会连同一个数据库。数据库不管怎么主从分离也好，集群复制也好。或者采用缓存/搜索引擎来作为承载也好，它始终有一个绝对的上限。所以数据层面瓶颈就决定了应用的上限不管应用部署多少个节点。所以反过来又说假设A部署100个节点做成集群。但是A连接的数据层只能提供10W并发。那我100个节点应该是共享这10W并发做限流的。而不是每个节点设计一个值去限流。所以传统的中心化的分布式框架会采用中心化的配置中心来处理限流比如springcloud会依赖eureka、dubbo会依赖zk。

你这个思路就是有问题的，数据库层面上，如果没有水平扩展切分，只是集群，这就好比一辆三轮车配有跑车马达，在达到80码没有问题，如果达到200码是不是就散架了，每一个环节都应该有可扩展的能力，要不然分布式干嘛？你连同一个数据库，说明并发并不高，垂直应用足够了

sd797994 commented 5 years ago

举个例子，假设我有某服务A我设置了限流1000次/秒。当我的服务B调用服务A时，理论上来说当前这一秒内A的全网可访问承载就变成了999，我看了很多针对.net的限流熔断的文章，几乎都是拿着polly的几个基础特性在说，没有涉及到分布式环境下的全网限流。其他的分布式框架，比如dubbo我大概知道它是会实时的将调用情况通过dubbo协议推送到zookeeper，加上zookeeper本身的CP特性，就可以保证全网限流的一致性，其他服务在调用这个限流服务时可以实时获取到真实有效的剩余流量来进行调用/限流。我就想问问surging在这一方面是怎么设计的呢

1、可以分享一下全网限流的原因吗？ 2、如果服务A限流1000次/秒，在服务A处，在达到限流条件时，根据规则快速的将额外的调用失效/抛弃/异常掉，就已经实现限流了

主要的问题还是在于数据库层面上，其实就应用本身来讲做无状态的横向扩容很方便也没有什么成本特别是通过容器编排这样的运维架构来讲。但是数据库不一样。大部分服务不管怎么做集群部署，它们本质上还是会连同一个数据库。数据库不管怎么主从分离也好，集群复制也好。或者采用缓存/搜索引擎来作为承载也好，它始终有一个绝对的上限。所以数据层面瓶颈就决定了应用的上限不管应用部署多少个节点。所以反过来又说假设A部署100个节点做成集群。但是A连接的数据层只能提供10W并发。那我100个节点应该是共享这10W并发做限流的。而不是每个节点设计一个值去限流。所以传统的中心化的分布式框架会采用中心化的配置中心来处理限流比如springcloud会依赖eureka、dubbo会依赖zk。

你这个思路就是有问题的，数据库层面上，如果没有水平扩展切分，只是集群，这就好比一辆三轮车配有跑车马达，在达到80码没有问题，如果达到200码是不是就散架了，每一个环节都应该有可扩展的能力，要不然分布式干嘛？你连同一个数据库，说明并发并不高，垂直应用足够了

对，其实我也在想这个问题。如果数据层面如何做到类似于应用层面这种无状态的扩容机制，最开始是单库，当读写压力来了之后开始选择读写分离。当数据量上去后又开始考虑数据分片，对于热点请求会选择引入缓存抗压。但是无论是何种机制。它始终有一个数据访问IO层面的压力存在，而且这个压力的阈值是远远低于web请求处理压力的。就像surging可以把rpc做到微秒级。但是面向数据层，很难做到这种层级的qps

29360068 commented 5 years ago

举个例子，假设我有某服务A我设置了限流1000次/秒。当我的服务B调用服务A时，理论上来说当前这一秒内A的全网可访问承载就变成了999，我看了很多针对.net的限流熔断的文章，几乎都是拿着polly的几个基础特性在说，没有涉及到分布式环境下的全网限流。其他的分布式框架，比如dubbo我大概知道它是会实时的将调用情况通过dubbo协议推送到zookeeper，加上zookeeper本身的CP特性，就可以保证全网限流的一致性，其他服务在调用这个限流服务时可以实时获取到真实有效的剩余流量来进行调用/限流。我就想问问surging在这一方面是怎么设计的呢

1、可以分享一下全网限流的原因吗？ 2、如果服务A限流1000次/秒，在服务A处，在达到限流条件时，根据规则快速的将额外的调用失效/抛弃/异常掉，就已经实现限流了

主要的问题还是在于数据库层面上，其实就应用本身来讲做无状态的横向扩容很方便也没有什么成本特别是通过容器编排这样的运维架构来讲。但是数据库不一样。大部分服务不管怎么做集群部署，它们本质上还是会连同一个数据库。数据库不管怎么主从分离也好，集群复制也好。或者采用缓存/搜索引擎来作为承载也好，它始终有一个绝对的上限。所以数据层面瓶颈就决定了应用的上限不管应用部署多少个节点。所以反过来又说假设A部署100个节点做成集群。但是A连接的数据层只能提供10W并发。那我100个节点应该是共享这10W并发做限流的。而不是每个节点设计一个值去限流。所以传统的中心化的分布式框架会采用中心化的配置中心来处理限流比如springcloud会依赖eureka、dubbo会依赖zk。

你这个思路就是有问题的，数据库层面上，如果没有水平扩展切分，只是集群，这就好比一辆三轮车配有跑车马达，在达到80码没有问题，如果达到200码是不是就散架了，每一个环节都应该有可扩展的能力，要不然分布式干嘛？你连同一个数据库，说明并发并不高，垂直应用足够了

对，其实我也在想这个问题。如果数据层面如何做到类似于应用层面这种无状态的扩容机制，最开始是单库，当读写压力来了之后开始选择读写分离。当数据量上去后又开始考虑数据分片，对于热点请求会选择引入缓存抗压。但是无论是何种机制。它始终有一个数据访问IO层面的压力存在，而且这个压力的阈值是远远低于web请求处理压力的。就像surging可以把rpc做到微秒级。但是面向数据层，很难做到这种层级的qps

我觉得你真正想的是如何保证数据库层面的高可用？而你提到的限流、扩容都是手段 1、如果业务真到了这个地步，考虑分布式数据库也是一个方向 2、垂直拆分、水平拆分都是要做的，届时数据库的业务应该也会相对单一，那么考虑nosql+关系数据库结合 3、通过消息队列来削峰填谷 4、改造业务实现 其实以上都是提高可用性的办法，不一定非要从限流的角度去考虑，所以我觉得依然是要结合业务去考虑这个事情

sxlvalue commented 5 years ago

主要是大家应用层用微服务，底层的DB其实没有跟上微服务的设计，服务最终在底层又有了相同的依赖这与微服务的设计是背离的，这种模式相当于只要数据库一挂，什么微服务都扯淡。不过这种方式也有可取之处，起码服务的更新迭代比较方便。

sxlvalue commented 5 years ago

只能说这个情况，很符合我们现在的国情和组织结构，因为大部分的公司的组织结构并没有和微服务开发模式相匹配。