非常抱歉，10:00~10:30 左右博客站点出现故障，给您带来麻烦了，请您谅解。
故障原因与博文中谈到的部署变更有关，但背后的问题变得非常复杂，复杂到我们都在怀疑与阿里云服务器 CPU 特性有关。
这篇博文本来准备 9:30 左右发布的，但发布博文时出现了 docker swarm 部署异常情况，切换到 docker-compose 部署后问题依旧，一直到 10:30 左右才恢复正常，继续发布这篇博文，在标题中加上了“翻车记”。
原先的博文正文开始：
周一向大家汇报车况之后，我们的 .NET Core 新车继续以 docker-compose 手动挡的驾驶方式行驶在信息高速公路上，即使昨天驶上了更快的高速（并发量更大的访问高峰），也没有翻车。经过这周3天访问高峰的考验，我们终于可以充满信心地宣布——我们度过了新车上路最艰难的磨合期，开新车的剧情从“翻车记”进入到了“行车记”。
翻车成为历史，行车正在进行时，但离我们的目标“飙车”还有很长的一段距离，“行车记”更多的是修车记，新车改造记。
目前这辆 .NET Core 新车有2个重大问题，一是油耗高（CPU消耗高），有时还会断油（CPU 100% 造成 502），二是手动挡驾驶实在太累。
针对油耗高问题，这两天我们从节能降耗角度对博客系统的 C# 代码进行了优化。
从日志中发现，有些特别长的 url 会造成 ASP.NET Core 内置的 url rewrite 中间件在正则处理时执行超时。
System.Text.RegularExpressions.RegexMatchTimeoutException: The RegEx engine has timed out while trying to match a pattern to an input string. This can occur for many reasons, including very large inputs or excessive backtracking caused by nested quantifiers, back-references and other factors. at System.Text.RegularExpressions.RegexRunner.DoCheckTimeout() at Go64(RegexRunner ) at System.Text.RegularExpressions.RegexRunner.Scan(Regex regex, String text, Int32 textbeg, Int32 textend, Int32 textstart, Int32 prevlen, Boolean quick, TimeSpan timeout) at System.Text.RegularExpressions.Regex.Run(Boolean quick, Int32 prevlen, String input, Int32 beginning, Int32 length, Int32 startat) at System.Text.RegularExpressions.Regex.Match(String input, Int32 startat) at Microsoft.AspNetCore.Rewrite.UrlMatches.RegexMatch.Evaluate(String pattern, RewriteContext context) at Microsoft.AspNetCore.Rewrite.IISUrlRewrite.IISUrlRewriteRule.ApplyRule(RewriteContext context) at Microsoft.AspNetCore.Rewrite.RewriteMiddleware.Invoke(HttpContext context)