今天我們分析了博客站點的2次故障（故障一、故障二），發現一個巧合的地方，.NET 5.0 正式版的 docker 鏡像是在11月10日提前發布上線的。
而在11月10日下午4點左右，由於 CI 服務器磁盤空間用完，我們進行了磁盤清理，刪除了 CI 服務器上的所有鏡像，清理之前 CI 服務器上 .NET 5.0 鏡像版本對應的是 .NET 5.0 RC 2，所以11月10日晚上發布博客站點時，CI 服務器重新下載了鏡像，這時正好下載了 .NET 5.0 正式版的 docker 鏡像，所以發布時博客系統的鏡像是基於 .NET 5.0 正式版（發布時會在CI服務器上生成應用的生產環境鏡像）。
現在可以進入這2個發布版本的鏡像進行驗證
$ docker run -t blog-web:2.3.101 dotnet --info Host (useful for support): Version: 5.0.0 Commit: cf258a14b7 $ docker run -t blog-web:2.3.102 dotnet --info Host (useful for support): Version: 5.0.0 Commit: cf258a14b7
Commit: cf258a14b7 對應的正是 .NET 5.0 正式版。
對比一下11月10日之前生成的鏡像
$ docker run -t blog-web:2.3.100 dotnet --info Host (useful for support): Version: 5.0.0-rc.2.20475.5 Commit: c5a3f49c88
不僅 Commit 不一樣，而且 Version 中包含 rc.2。
所以這2次故障時用的都是基於 .NET 5.0 正式版的鏡像，而且11月10日至11月12日期間，我們只進行了2次發布，2次都出現了故障。
如果片面地從這個巧合來看，似乎故障與 .NET 5.0 正式版鏡像有關，這時你可能立馬提出疑問，同樣是基於 .NET 5.0 正式版的鏡像，為什么今天早上發布沒有出現故障？
根據我們的分析判斷，故障的觸發與發布時的並發請求量有關，2次故障時的發布時間分別是在 20:30 與 19:30 左右，這2個發布時間點的並發量差不多，而今天早上發布時並發量要小很多，而且我們其他並發量不大的應用升級到 .NET 5.0 沒有出現過這個問題，所以今天早上發布正常很可能是因為沒有到達觸發故障的並發量。
另外，今天早上發布時我們已經將博客項目依賴的下面這些 nuget 包升級到 .NET 5.0 正式版對應的版本，昨天晚上在處理故障時也進行過這個升級發布嘗試，但沒有解決問題，與故障關聯的可能性很小，但從中可以得到的信息是故障時項目代碼是基於 .NET 5.0 RC 2，生產環境部署的 runtime 是基於 .NET 5.0 正式版。
Microsoft.Extensions.Primitives System.Interactive.Async Microsoft.Extensions.Http Microsoft.Extensions.Logging.Abstractions System.ServiceModel.Primitives Microsoft.EntityFrameworkCore.SqlServer Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation System.Text.Encoding.CodePages
雖然正式版 runtime 鏡像造成這個故障的可能性很小，但考慮到問題的詭異性，我們不想放過一個蛛絲馬跡，所以准備今天晚上再次發布試試，計划的發布時間是21:30，但是由於今天是周五，晚上的並發請求量比前2次故障期間小一些，即使沒有出現問題，也不能說明100%沒問題，但至少可以知道在周五晚上的並發量下不會觸發問題。
【更新】這次發布沒有出現故障，下圖是 memcached 服務器 tcp 連接數監控圖
【更新】《.NET 5.0 背鍋案》第2集：碼中的小窟窿，背后的大坑，發現重要嫌犯 EnyimMemcachedCore
附博客項目所使用的 Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
RUN sed -i s@/deb.debian.org/@/mirrors.aliyun.com/@g /etc/apt/sources.list
RUN apt-get update && apt-get install -y curl
FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build
WORKDIR /src
COPY src/*.sln src/*.props src/NuGet.config ./
COPY src/*/*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p ${file%.*}/ && mv $file ${file%.*}/; done
RUN dotnet restore "BlogServerCore.sln"
COPY src/. .
RUN dotnet build "BlogServerCore.sln" -c Release --no-restore
FROM build AS publish
WORKDIR /src/BlogServer.WebApi
RUN dotnet publish "BlogServer.WebApi.csproj" -c Release -o /app/publish --no-build
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
RUN echo "dotnet BlogServer.WebApi.dll" > run.sh
HEALTHCHECK --interval=5s --timeout=20s \
CMD curl -fs -o /dev/null localhost/alive || exit 1