2016-08-01 21 views
2

首先,我收集有关此问题的信息,以便我可以以更优雅的方式实现此功能。构建代理中心

让我们来看看下面的图片 enter image description here

目标服务器(绿圈)

这是我用它来获取一些数据的API服务器。

特点:

代理控制器(蓝色正方形)

它存储代理的列表的简单服务器;发送和接收一些数据;我想谈谈我将在其上运行的软件。

特点:

  • 代理列表
  • API密钥列表

我认为这应该是一个hashmap如果我想扩展我的应用程序存储IP =>标记列表或数据库表。

工人

只需分析JSON响应和传递数据的分贝。

让我们走近代理服务器。

第一个想法:

  • 创建newFixedThreadPoolExecutor
  • 通网址/令牌工人:server.submit(新工人(URL,令牌,代理))
  • 工人分析数据,并把它传递到db。

但在我看来,这个解决方案相当庞大且难以维护,我想要让端点收集统计信息,杀死或产生新的工作人员等等。

第二个想法:

  1. 工人产生像https://host/user=1&option=1
  2. 它传递给代理控制器
  3. 代理控制器指定给该请求的API密钥和代理服务器
  4. 执行请求的请求
  5. 接受回复
  6. 将它传回工人(我认为最好的想法是在工作人员和代理控制器之间放置负载均衡器)。

这个解决方案对我来说似乎很拗口。例如,如果工作人员死了,代理服务器向死去的工作人员发送一堆请求,并可能导致数据丢失。

第三想法:

同为第二但不是直接将数据发送到工人的代理控制器将它传递给局部总线。我找到了一些关于apache骆驼的信息,可以让我组织这个解决方案。在这种情况下,死亡的工作人员是死的工人,dataloss等于零(也许)。

当然,这三种情况都不会处理错误。通过重新发送请求和其他数据可以解决一些错误。一些错误可以通过重新分配工人来解决。

因此,您认为在这种情况下最好的解决方案是什么?我错过了稍后会出现的一些隐藏问题吗?我应该使用哪些工具?

谢谢

回答

0

什么试图达到? 也许你可以考虑使用这种架构: NGINX(代理+负载平衡) - >工人服务器 - >数据库服务器(可能使用一些NoSQL的像卡珊德拉)

+0

这种情况是好的,如果ngnix可以支持多个代理服务器和标志的要求与代理的主机/端口关联的令牌。 – Ascelhem