☰

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

tag-icon • tag-icon windows-server-2012 hosts-file
避免负载均衡器后面的服务器出现故障

环境

我们有一个正在运行的解决方案，它与 Twitter API 交互。Twitter API 端点是：

api.twitter.com

我们对端点进行了多次调用，但很少达到 Twitter 定义的任何 API 限制。

我推测 Twitter 在该 URL 上设置了负载均衡器并将其内部重定向到不同的机器。

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

问题

每周一次（有时更多），持续几个小时，我们会在可执行文件和 Web 应用程序的日志文件中记录以下异常。

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 地址，从其他机器（在不同国家/地区）返回nslookup199.* 范围内的至少 4 个 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

解决方案 ？

我曾尝试在这些故障期间编辑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 的服务器上，但它确实破坏了我们的功能，使我们完全无法工作。所以我们需要更积极主动，而不是等到 Twitter 解决这个问题。

这可能不是解决这个问题的最佳方法，但我们已经目前。我们招募了一位熟练解决这些操作问题的人员，但他要到 12 月才会上任。因此，对于经验有限的人，任何关于这个问题的临时解决方案的建议都将不胜感激。

那么，有谁能给出建议或线索来帮助我们以最佳方式解决这个问题？

我不介意阅读文章，但正确的引导或推动将会有很大帮助。

感谢您的时间

答案1

简短的回答：不。

除了通知用户存在上游问题之外，您几乎无法采取任何措施来缓解第三方提供商问题。

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

对于较长的停机时间，我建议在应用程序内向全局用户显示通知。

除此之外，我非常怀疑 Twitter 的 API 是否存在那么多问题 - 您的使用率可能受到某种限制。我强烈建议您联系 Twitter 并提出支持案例。

相关内容