当前位置：网站首页>有幸与美团大佬共同探讨单节点连接数超1.5W的问题

有幸与美团大佬共同探讨单节点连接数超1.5W的问题

2022-08-08 20:12:00 【中间件兴趣圈】

大家好，我是威哥，《RocketMQ技术内幕》一书作者，荣获RocketMQ官方社区优秀布道师、CSDN2020博客执之星Top2等荣誉称号。目前担任中通快递技术平台部资深架构师，主要负责全链路压测、消息中间件、数据同步等产品的研发与落地，拥有千亿级消息集群的运维经验，不仅实践经验丰富，而且对其源代码有深入且系统的研究。欢迎大家关注我，一起抱团发展。

在和美团一个大佬从Netty连接复用开始了，最后聊到了微服务架构中单个节点连接数过高的问题，我觉得这个很值得大家探讨，一起来交流探讨一番。

1、抛出问题

例如一个电商的微服务架构如下图所示：
在这里插入图片描述
简单罗列一下这个系统的构成：

网关域
整个微服务的入口网关，集群部署。
优惠券域
主要是用于提供电商系统中的优惠券服务。
积分服务
商场的会员积分服务。
支付服务
提供订单支付相关服务
订单域
订单域，主要提供下单服务，在订单域中需要调用优惠券、积分、支付等服务，包括图中未画出的库存等服务。

上面的架构图非常简单清晰，但如果每一个域中的部署的实例超过5000台，又意味着什么呢？

每一个实例部署5000个可能让大家觉得匪夷所思，认为在现实中基本不会存在，但如果上升到当下一线互联网公司，恐怕都还不止，并且在一线互联网企业通常是多机房双活部署，这里的问题强调在一个机房中就有这么大的规模。

如果上述微服务架构采用阿里开源的Dubbo框架，下单服务进行负载均衡，订单域中的一台机器持有的连接数轻松破1.5万,实际的电商业务非常复杂，需要调用的服务远不止上图中勾勒的这么少，对机器的内存、网络调度带来极大压力，严重时将影响系统的稳定性，很容易出现超时等异常。

2、问题分析与解决方案

本文将限定与微服务框架使用Dubbo，但本文思想的阐述并不局限于Dubbo。

上述造成单个节点轻松破2w连接的原因是负载均衡机制造成的。

优惠券服务部署5000个节点，下单服务作为其消费者，会从注册中心获取到整个服务列表，然后需要调用优惠券服务时会在客户端进行负载均衡，从服务列表中包含的5000个服务提供者中按照负载算法选择一个服务者提供者加以调用，即下单服务需要创建5000个连接。

值得注意的是下单服务并不只是调用优惠券服务，还需要调用其他服务，从而导致一个下单服务会随着其调用的服务数的增多，创建的连接数将非常多。

如何破局呢？

首先我们要理解负载均衡的底层目的：

避免单点故障
由于服务提供者集群部署，客户端在发起调用时可以按照某种算法从集群中选择一个，一个宕机并不会影响客户端的使用，从而提供高可用性保证。
实现高并发
单个节点受限内存、连接数等限制，其服务能力并不足以扛住海量请求，故需要依靠多个节点共同提供服务，从而构成一个服务集群，大厂中单个服务部署5000+节点是非常常见的。

总的来说，负载均衡相对客户端来说，其基本要求：充分将流量平均分配给服务节点，充分利用集群的处理能力。

但必须持有服务提供者的所有连接才能实现负载均衡？我看未必，请看如下示意图：
在这里插入图片描述
其核心思想是对客户端、服务端进行分组。

从单个客户端维度来看，并不需要持有所有服务提供者的列表，从而也就无需创建到所有服务提供者的tcp连接，只需持有部分连接，另外一部分分配给其他客户端。

但从所有客户端维度来看，可以调用所有的服务提供者，实现对所有服务提供者进行负载均衡。

经过上面的分组，单个服务节点（无论是客户端、服务端）端连接数量都能成倍的下降，效果将十分显著。

那在Dubbo中是否可以利用现成的机制来实现呢？

答案是：当然可以，尽管该功能设计的目的并不是本文的目的，但还是有异曲同工之妙。

其具体做法如下所示：
在这里插入图片描述
可以对客户端、服务端打标签，这样的话，订单服务-1被打上标签c1，尽管订单服务-1能从注册中心获取全部打支付服务列表（4台），但由于在负载均衡之前首先会执行路由选择，根据标签路由机制：订单服务-1由于其标签为c1，故只能访问tag为c1的服务提供者，这样就只会创建到tag为c1的支付服务的连接，从而实现降低连接数之目的。