避免负载均衡器后面的服务器出现故障

环境

我们有一个与Twitter API交互的解决scheme。 Twitter API端点是:

api.twitter.com 

我们对端点进行了很多调用,但是我们很less碰到任何由Twitter定义的API限制。

我认为Twitter有一个负载均衡器设置在该url,并在内部redirect到不同的机器。

该解决scheme是一个.Net应用程序,部分是一个执行数据轮询的可执行程序和一个用于回复和发布推文的Web应用程序。

问题

一个星期(有时更多)几个小时之后,我们会在我们的可执行文件和Web应用程序的日志文件中logging以下exception。

 Inner Exception : System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 185.45.5.33:443 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.GetResponse() at Hammock.Web.WebQuery.ExecuteGetDeleteHeadOptions(WebRequest request, WebException& exception) in f:\src\hammock\src\net35\Hammock\Web\WebQuery.cs:line 1021 ... Ommited rest of exception ... 

当我从服务器本身做一个NSLOOKUP ,我有以下结果

 >nslookup api.twitter.com Server: 4201082000200000000g00g021.ip.ssc.net Address: 2001:820:2::9:218 Non-authoritative answer: Name: api.twitter.com Addresses: 185.45.5.33 185.45.5.44 

每次我做这个查找错误的185.45.5.33服务器列出,并且只有一个替代的IP地址存在。

注意:我们只有来自我们的生产服务器的这两个IP地址,从其他机器(在不同的国家), nslookup在199. *范围内返回至less4个IP地址。

 >nslookup api.twitter.com Server: kdns1.task.gda.pl Address: 213.192.64.1 Non-authoritative answer: Name: api.twitter.com Addresses: 199.16.156.104 199.16.156.72 199.16.156.231 199.16.156.8 

解决scheme ?

我已经尝试在这些故障期间编辑C:\Windows\System32\Drivers\etc\hosts文件与此行

 # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost 185.45.5.44 api.twitter.com 

但这似乎并不奏效,问题仍在继续。 虽然这个问题可能是在他们的Twitter服务器上,但它确实打破了我们的function,完全停止工作。 所以我们需要更积极主动,而不是等到Twitter解决问题。

这可能不是解决这个问题的最好方法,但我们现在已经有了。 我们招募了一些熟练操作这些操作问题的人,但他不会在十二月之前开始工作。 因此,对有经验的有限人士提供任何build议,都将非常感激,暂时解决这个问题。

那么有没有人有一个build议或一个领导,可以帮助我们以最好的方式解决这个问题?

我不介意跳进阅读文章,但是向正确的方向领导或推动将是一个很大的帮助。

感谢您的时间

简短的回答:不。

您可以做的很less,以减轻第三方提供商的问题,除了通知您的用户存在上游问题。

您可能会显示描述性的错误消息,例如“与Twitter通信时出现问题,请稍等。”,或者默默丢弃错误并在一段时间后重试。

对于较长时间的停机,我build议在应用程序中向全球用户显示通知。

除此之外,我严重怀疑Twitter的API有许多问题 – 您可能会以某种方式限制速度。 我强烈build议你联系Twitter并提出支持案例。