【故障公告】发布 .NET Core 版博客站点引起大量 500 错误

  • 时间:
  • 浏览:0
  • 来源:大发uu快3_uu快3平台_大发uu快3平台

非常抱歉,今天上午的博客站点故障给大伙带来了很大的麻烦,请大伙谅解。这次故障是大伙发布 .NET Core 版博客站点引起的,其实大伙进行了充分的准备,但还是低估了高并发下的冗杂什么的问題。

以下是故障背景与大致经过:

在你这一炎炎夏日,大伙正热火朝天地忙着整个 .NET Core 迁移工程的收官 —— 发布 .NET Core 版博客站点与博客后台。大伙的或者 系统都早已迁移至 .NET Core 并已在线上工作一番时日,只剩下最难啃的硬骨头 —— 博客系统,到你这一月这根钢铁般坚硬的硬骨头也被啃得差很多了,它的发布上线将为大伙整个 .NET Core 迁移工程画上完美的句号,并顺带以此里程碑迎接 .NET Core 3.0 正式版的发布。

什么都,发布 .NET Core 版博客站点与博客后台成为大伙8月份最重要的工作。.NET Core 版博客站点7月份可是我意味着完成开发,这段时间一边进行更进一步的内测,一边进行灰度发布,接入或者 生产流量以发现大伙测试中未能发现的什么的问題并进行修复,在上个周末接入更多生产流量进行测试与修复后,大伙是意味着很有信心,评估后认为已具备正式发布条件,除了大伙无法在测试环境中模拟的博客系统发生的冗杂高并发场景。

于是一边带着信心,一边带着对高并发什么的问題的担心,大伙决定在今天一大早进行发布。

发布时的部署场景是另一一两个 的,博客系统基于 .NET Core 3.0 Preview 7 (EF Core 用的还是 3.0 Preview 5),7台阿里云 centos 服务器组建了 docker swarm 集群,6台4核8G服务器作为 worker 节点跑博客站点的应用容器,1台2核4G的服务器作为 manager 节点(不部署任何容器),每个 worker 节点都部署 1 个 nginx 与 .net core 博客应用容器,所有请求都由阿里云均衡转发到 nginx 容器,再由 nginx 容器转发给 .net core 应用容器,nginx 通过端口映射的土法律法律依据监听 worker 节点服务器的 80 端口。

另一一两个 的部署环境也是大伙经过长期验证的,唯一这样 经过验证的什么都博客系统这样 高的并发。

顶着另一一两个 高并发什么的问題的风险(docker swarm 与 .net core ),大伙在今天早上 5:80 左右进行了发布。

现在现在刚开始 访问量小,并发低,没跳出 什么的问題,但到 8:80 左右跳出 什么的问題了,打开什么都博客页面要1秒多(正常状态是几十毫秒),而在容器内用 curl 命令请求有的是到10毫秒。

$ docker exec -t $(docker ps -f name=blog_web -q) curl -H 'X-Forwarded-Proto:https' -w %{time_total} -o /dev/null -s localhost 
0.002876

怀疑是 nginx 的什么的问題,准备重新创建另一一两个 docker 集群,无需  nginx 直接用 kestrel 监听 80 端口。

以后同事指出,有的是 nginx 的什么的问題,是 docker swarm 端口映射在高并发下的性能什么的问題,才能了将端口映射改为 host 网络模式才能防止你这一什么的问題。

9:80 左右,随着并发这样 高,nginx 容器现在现在刚开始 报 800 错误,现在现在刚开始 以为是集群中的服务器负载缺乏,于是向 docker swarm 集群中加进服务器,但于事无补,800 错误很多。

跳出 800 错误时,有时刷新一次就会好,有需要刷新好多少,怀疑是集群中或者 服务器不稳定,于是一台一台登录集群中的服务器进入容器用 curl 命令进行测试,除了1台服务器不稳定,或者 服务器 curl 命令测试时响应时延都正常,将那台不太稳定的服务器下线,什么的问題依旧,随着并发量继续增大,800 错误也继续增多。

进一步分析后,怀疑 800 错误是是意味着高并发下 nginx 容器与 .net core 应用容器之间的网络通信跳出 什么的问題,于是 10:80 左右决定放弃这次发布,回退至跑在 Windows 上的 .net framework 版本博客站点,恢复了正常。