上周五下午，咱们在博客中部署了推荐系统，在博文下方显示“最新IT新闻”的地方显示自动推荐的关联博文。咱们用的推荐系统是第四范式的推荐服务，咱们本身只是搭建了一个推荐系统中转站（基于 ASP.NET Core），接收来自博客前端的请求，而后将请求转发给第四范式的推荐服务，并将响应内容转发给博客前端。html
这个中转站的功能很是简单，就是一个 http 请求/响应搬运工，简单到让咱们忽视了它会给服务器带来的潜在压力 —— 一边与博客前端的请求/响应会产生大量 TCP 链接，一边与推荐服务的请求/响应会产生大量 TCP 链接，并且因为推荐数据的动态变化特色而没法使用缓存。在一样的负载下，这个搬运工会比其余应用消耗更多的 TCP 链接。前端
从上周五发布到昨天，因为访问量没有达到特别高的高峰，因此问题没有暴露。今天上午访问量达到更高峰时，问题出现了。部署在 docker swarm 集群上的不少站点时不时地出现 500 错误，日志中频繁出数据库或 memcached 服务器网络链接失败的错误。开始咱们还觉得是以前屡次遇到过的节点服务器不稳定问题引发的，因而将集群中的服务器一台一台下线、重启、上线，但这样操做以后问题依旧。接着把怀疑对象放到了 memcached 服务器，是否是 memcached 服务器不稳定引发，因而重启 memcached 服务器，但问题依然。git
在用完以前的招式、百思不得其解之时忽然想到多是集群中某些服务器的 TCP 链接过多达到了限制（Linux 的限制或者阿里云的限制），若是站在这个角度分析，无论故障的表现仍是日志中的错误均可以获得合理的诠释。因而立马锁定了缘由，而后天然就想到了咱们上周五部署的推荐系统中转站，赶忙将其下线，500 错误即刻消失，集群上的全部应用都会恢复正常。github
很是抱歉，此次故障给你们带来麻烦了，请你们谅解。咱们会吸收此次上线推荐系统时不够深思熟虑、过于轻敌的教训，认真反思，努力改进本身的工做。docker
更新：后来升级至 .NET Core 2.2 Preview 3 ，并将 System.Net.Http 升级至 4.3.4 以后没出现这个问题，问题与 https://github.com/dotnet/corefx/pull/32568 有关。数据库