ip在线代理联合早报_私域流量技术超大并发IP代理技术

上一篇文章，我们着重讲了关于私域流量机房的基础硬件建设方案以及如何解决WIFI干扰的问题，并着重介绍了M24安卓手机服务器集群的产品，我想能够给大家一些启发，能让小伙伴们少填一些坑。

我们服务私域流量客户这几年以来，经历了各种形形色色的应用场景，过程中经历了多次紧贴客户业务的协议级定制开发；今天我想通过一个服务客户的案例，跟大家探讨，如果业务并非部署在移动终端上，而是部署在X86服务器上的情况下，如何实现大并发高性能的IP代理技术架构，从而最大程度上提升业务效率，减少基础建设的投入。

我们先介绍下业务背景,客户是一个占据私域流量领域的领导地位的公司，有较强的软件开发能力，高峰时期，并发业务流达到数十万级，每一条业务流承载一个客户的营销业务，受限于公共流量平台的技术规则，每10条业务流要使用一个独立的远端IP地址，在使用我们定制的IP代理服务之前，客户的技术架构经历了几次迭代：

第一阶段：串行架构，业务流轮询模式

客户业务流架构上采用串行架构，基于业务流会话保持的技术限制，只能在单台服务器上承载数百条业务流，为满足几十万的并发业务流，客户投入了数百台的硬件服务器来支撑，即便如此还是不能有效满足业务发展的产能需要，而且，由于受限于串行架构缺陷，很难保证每一条业务流都实时在线。

第二阶段：并行架构+IP代理能力与业务逻辑耦合

客户把串行业务流架构改造为并发业务流架构，每一条业务流内部独立封装IP代理协议包头，通过这次改造，用户成功把硬件投入降低了一半，业务流在线率也有较大提升。但是IP代理协议头封装仍然占用了较高的算力，在这个基础上我们为客户实施了第三阶段的技术改造。

第三阶段：并行架构，IP代理能力与业务逻辑解耦

先上图：

方案说明：

1：业务服务器与BlueX之间千兆以太网连接。

2：每个业务服务器上通过多线程的技术，并发N条业务流(N=5000),每个业务线程预先定义城市与ADSL线路IP归属，这个归属关系定义存储在BlueX平台的转发规则数据库中，BlueX网关每次启动时从云端数据库中拉取到本地内存。

3：业务服务器与BlueX网关在开展业务之前协商约定每一条业务流的源IP与原端口范围，端口范围可以是一个可变的配置值，上图例中，每一个业务流占用5个源端口。

业务流1 源IP 为 192.168.0.1 ，所有的TCP/IP报文通过1000至1005源端口发送给BlueX网关，业务流2源IP为192.168.0.1,源端口为1006至1010.以此类推。

3：BlueX网关内置了流量识别与流量调度引擎，引擎收到业务服务器的报文时：根据源IP+源端口识别每一条业务流量，并根据ADSL线路归属关系进行流量转发至IP代理节点(ADSL).

实施效果：

1：业务服务器不再处理任何的关于IP代理的报文封装，业务逻辑与通信逻辑解耦，CPU利用率快速下降，并发线程承载能力提升10倍以上。

2：每一条业务流锁定在一个ADSL线路上(这个锁定并不是必须的，可以视业务需求而定)。

3：客户的硬件设备投入由原来的数百台服务器缩减至数十台，机房场地缩小到原来的1/5，能耗亦显著下降。

4：所有业务流实时在线。

5：业务流端的软件逻辑有所简化。

总结，通过这种协议级的贴身定制开发，业务和通信逻辑的解耦，极大提升了用户效率，显著降低了业务开展的成本，这种架构非常适合有较强软件开发能力，较大并发业务规模用户场景。

关于我们

我们是一群通信技术领域出身的技术型创业者，我们团队成员在通信技术领域的软硬件方向上平均从业10年以上，这几年以来，我们始终考虑的如何贴近用户场景，创造新品类，在细分领域成为有竞争力的团队，只有紧贴用户场景方能创造用户价值，与其更好，不如不同。核心能力从来就不是一蹴而就的，多年以来，我们始终在这个赛道上发力，我们相信的是，结硬寨，打呆仗，日拱一卒，功不唐捐 ！