.NET Core 迁移躺坑记
最近將自己負責的一個核心接口系統從.Net Framework遷移到了.Net Core。
整體過程，從業務層面說一般般吧(整體還好但還是搞的業務有感，沒出嚴重故障）但是技術層面上感覺其實并沒有達到要求，不過預期也是應該不會那么順利，接下來可能還需要幾個小Fix來處理各種奇奇怪怪的問題。
回顧下遷移時候遇到的若干個坑，希望對后續有此類操作的人所有幫助。
?
1.NetCore下的路由行為和Web Api的不一致
我們回顧下在Web Api里時候的一個路由定義
這個配置下可以讓
Get RootUrl/123?和?Get RootUrl?id=123 同時映射到 GetThirdPartyChannel方法里。
但是，假如在不做改動前提下直接將這個Controller定義變為Core的話，Get RootUrl?id=123?這個路由將無法正常運作 (而?Get RootUrl/123?則依然可以正常運行）。
原因是在AspNetCore下他發現了[Route(“{Id}”)]就會認為Id是Path的一部分，然后相當于隱式給id這個參數默認了[FromPath],但是[Route(“”)]這里并沒有定義id作為Path。
會導致一旦調用?Get RootUrl?id=123?的時候，首先路由是能匹配上 [Route(“”)]的，但是參數里的id恒定是空(即代碼里獲取到的id字段永遠是null)。
?
解決方案有2種
①強制在方法參數的id里加上[FromQuery],但是這個會有個咖喱是Swagger生成的文檔里會有2個Id字段（Path里有一個，你強制了Query里有一個）但是接口能正常工作；
②將2個路由拆開來分別對應2個方法。
?
總結：
按照我們組內規范，定義Url是不能放Path的，這些都是一些早期設計的，沒有遵照規范將其替換完一直遺留著，規范不嚴格，代碼兩行淚。
?
2.NetCore下加載程序集的時候會識別版本號
我們有使用到部分的類庫會依賴動態程序集加載，目前有：
Hangfire 用于實現Fire-and-Forgot模式異步執行以及延遲任務；
Protobuf-net 用于存儲到Redis的時候轉Protobuf更快更小。
?
這類程序集有個特點是他要將你要執行的東西序列化為某種類型（我不管json還是二進制的信息），然后需要時候在加載程序集。
而他們序列化的時候對程序集的處理統統都是用了Type.AssemblyQualifiedName方法，改方法可能會產生類似“ClassLibrary1.Class1, ClassLibrary1, Version=1.2.0.0, Culture=neutral, PublicKeyToken=null”的字符串。
而我們自己在CI的時候有一個機制是，每次TFS編譯的時候會自動修改dll的版本號，具體可以參考以前寫的文章?Azure Devops/Tfs 編譯的時候自動修改版本號
以前.Net Framework加載一個程序集的時候，比如程序集的信息是 “ClassLibrary1.Class1, ClassLibrary1, Version=1.2.0.0, Culture=neutral, PublicKeyToken=null”?? 其中的Version的值他是不認的，隨便Version是什么他都能加載（咱不討論StrongName模式）
而到Core之后如果Version不匹配，則會報錯（他會認可Version的值了）
?
解決方案：
暫時去掉了自動修改版本號機制，固定版本號到某個值。
?
3.NetCore下的Redis有點詭異（不穩定）
具體體現在好像遷移到Core之后連接Redis的鏈接更不穩定了，無論是鏈接超時還是首次建立鏈接的成功率都顯著下降。
也是因為這個問題導致這次發布鬧出了不該有的動靜。
發布那會的臨時解決方案：
Redis的鏈接字符串加了,abortConnect=false讓連接不上的時候也繼續跑著先吧
進行中的解決方案
根據https://stackoverflow.com/questions/42956377/stackexchange-redis-timeout-exception-in-net-core
試著將代碼內頻繁查詢的Redis讀取轉Async試試。
?
4.NetCore下的Http請求不穩定（時而報SocketException)
到Core之后我們的未知知識庫里又新增了一個全新異常模式
這個異常看起來像如下幾個地址里提到的情況
https://github.com/dotnet/corefx/issues/30691?
https://github.com/dotnet/corefx/pull/32903?
https://github.com/dotnet/corefx/issues/32902
但是要說3.0才fix，等不了那么久……
?
另外已知在小訪問量下好像不容易出現這個（我們之前已經有幾個小站點已經是core里但是都沒發生這個問題），有概率跟請求壓力有關系。
?
目前的臨時解決方案
參考官方文檔?https://docs.microsoft.com/en-us/dotnet/api/system.net.http.socketshttphandler?view=netcore-2.2?先將core2.1引入的SocketHttpHandler禁用了
可以直接Powershell執行
[sourcecode language='powershell' padlinenumbers='true'][environment]::SetEnvironmentvariable("DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER", "false", "Machine")
[/sourcecode]
但是現在也是零星會偶爾冒一下出來（感覺并沒有什么卵用）
進行中的解決方案
基于HttpClientFactory構造HttpClient外加Polly如果失敗就再來一次的模式。
?
5.迷之超時
現在發覺有一部分機器會有超時的現象，而這個現象比較詭異在于IIS日志里是有記錄到這次請求的（超時的請求），而作為我們站點監控的Application Insights是沒收到這個請求的
暫時想法是不是因為現在IIS只是一個Reverse Proxy的角色，而IIS到達真正承載站點的kestrel的時候這個過程有問題
?
因為我們當前是基于Net Core 2.1(因為是LTS），并沒有2.2所引入的進程內托管這種模式，這個問題目前還在定位中
?
另外有人建議（包括網上尋找資料得到的信息）是IIS里調整下
Start Mode 改為Always Runing
Idel Time-out Action改為Suspend
但是這都是Win 2012才引入的功能，而我們家是08R2，兩行淚的羨慕隔壁好多家都是2016的！
?
臨時解決方案：
看到超時的機器就下掉
而且發現這個超時現象主要集中在某幾個服務器上
之后在看看系列的解決方案
后面轉Linux后的話直接kestrel硬扛，IIS一邊去
?
最后
好像在.Net Framework里經常推崇的在異步方法里加ConfigureAwaiter(false)在.Net Core下是沒什么卵用的，參考
http://blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html
原文地址：https://www.cnblogs.com/leolaw/p/10740678.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?
總結
以上是生活随笔為你收集整理的.NET Core 迁移躺坑记的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 解决 VS2019 中.net core
- 下一篇： .NET Framework 4.8发布