中心化的RscoketBrocker会不会因为承载了大量的流量而出现瓶颈

[zhongjunzzz]

如标题，Brocker下如果注册了过多的服务，且服务之前的流量传输较大时，会不会成为性能瓶颈
例： Brocker 部署在云端，而其他服务因为某种原因只能使用互联网地址注册进来，那Brocker的带宽是否必须是下面所有应用的和？

[linux-china]

这个有可能。 如果你使用API Gateway，K8S Ingress等，请求的入口都可能是瓶颈，所以大多数这种网关类的系统都是全异步化设计的，基本都是使用Nginx，其他诸如Spring Cloud Gateway也都是全异步化的架构。 网关或者Broker通常性能都非常高的，如RSocket Broker，使用binary routing，协议中的元信息解析都不涉及，而HTTP网关基本都涉及到HTTP协议解析等，此外RSocket Broker采用Zero Copy技术，请求基本上是无修改地转发出去，所以性能比较高。 通常你只需要控制好请求类型就可以，如涉及文件上传和请求的场景，如文件、图片视频等，走单独的系统，而不要让RSocket Broker来转发这种类型请求就可以，主要是请求过大，会占用很大的网络带宽。 此外如果两个系统之间调用量非常大的场景，也支持应用之间直接连接，而且完全是透明的，这个在RSocket Broker 1.1.0中已经实现啦。

最后总结一下：

• RSocket Broker的性能非常高，而且支持横向扩展
• 将文件类的请求独立出去，不要消耗过多的RSocket Broker带宽，当然采用服务直连的方式也可以。
• 如果两个系统之间调用量非常大，可以调整为直接互连，跳过RSocket Broker，这个在1.1.0中已经支持，而且是完全透明的。 如果电商中的商品详情页调用商品中心获取商品详情，调用量非常大，就可以使用直连方式。 而调用相对比较小的，如CRM到商品中心，走RSocket Broker通讯就可以啦。

RSocket Broker点对点通讯，请参考： https://github.com/alibaba/alibaba-rsocket-broker/wiki/RSocket-P2P

[pc859107393]

中心节点在大规模流量下无论如何都是流量瓶颈，但是去中心化的时候，容易导致服务治理麻烦，所以这种取舍还是比较麻烦，，，建议根据自身业务需求因地制宜。