歡迎光臨
每天分享高質量文章

.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

已同步到看一看
赞(0)

分享創造快樂