下岗的老王

> > 举个例子，假设我有某服务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。

> > > > 举个例子，假设我有某服务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

@364988343 已处理

你现在dapr之间相互调用是走的dapr-sdk-java吗。可以尝试直接用resttemplate访问{localhost:darp-port}/v1.0/invoke/{dapr.io/app-id}/method{your-endpoint}发起纯粹的http调用去访问目标服务。如果是通顺的，则不排除是dapr-sdk有bug。至少我之前写系列博客文章时dapr和istio集成没有此问题

那确实没遇到过了。既然你使用容器里手动执行curl可能和.net还是java没啥关系了。不知道是不是版本不兼容导致的了

你这个场景。。只有自己多研究了。我这demo也仅限于很简单的hello world。。。

这一块不是很容易实现它，因为我没有对依赖注入容器本身设计抽象接口来实现依赖倒置，在代码里大量使用了autofac的具体实现(比如ilifetimescope)。如果你有兴趣，可以fork分支单独设计依赖注入的抽象从而实现容器的可替换性

理论上是可行的哈，dapr本身并不涉及分布式事务，所以你完全可以在应用层独立的引入第三方框架来实现分布式事务，不冲突的

着什么急，以微软的尿性，一般在小版本号才会稳定。等1.9.1或者1.9.2这种热修补出来再说

在windows下，打开powershell 输入该命令，会弹出一个文本文档，可以修改ingress-nginx-controller暴露的NodePort，修改后你需要你在你的host文件(默认为C:\Windows\System32\drivers\etc)里配置一下该域名 一般格式为： 127.0.0.1 admin.dapreshop.com 这样你在浏览器键入该域名admin.dapreshop.com:30882，就会被指向127.0.0.1:30882 这样你的请求就会被转发到ingess-controller，根据之前配置的ingress rule就会将包含admin.dapreshop.com的请求转发给adminfrontend应用，从而返回admin端网页