.NET Core 迁移躺坑记

悠悠 2021-09-19 18:32 295阅读 0赞

最近将自己负责的一个核心接口系统从.Net Framework迁移到了.Net Core。

整体过程，从业务层面说一般般吧(整体还好但还是搞的业务有感，没出严重故障）但是技术层面上感觉其实并没有达到要求，不过预期也是应该不会那么顺利，接下来可能还需要几个小Fix来处理各种奇奇怪怪的问题。

回顾下迁移时候遇到的若干个坑，希望对后续有此类操作的人所有帮助。

## 1.NetCore下的路由行为和Web Api的不一致 ##

我们回顾下在Web Api里时候的一个路由定义

[![image][]][image 1]

这个配置下可以让

**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 编译的时候自动修改版本号][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][https_stackoverflow.com_questions_42956377_stackexchange-redis-timeout-exception-in-net-core]

试着将代码内频繁查询的Redis读取转Async试试。

## 4.NetCore下的Http请求不稳定（时而报SocketException) ##

到Core之后我们的未知知识库里又新增了一个全新异常模式

[![image][image 2]][image_image 2]

这个异常看起来像如下几个地址里提到的情况

[https://github.com/dotnet/corefx/issues/30691][https_github.com_dotnet_corefx_issues_30691]

[https://github.com/dotnet/corefx/pull/32903][https_github.com_dotnet_corefx_pull_32903]

[https://github.com/dotnet/corefx/issues/32902][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][https_docs.microsoft.com_en-us_dotnet_api_system.net.http.socketshttphandler_view_netcore-2.2] 先将core2.1引入的SocketHttpHandler禁用了

可以直接Powershell执行

[environment]::SetEnvironmentvariable("DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER", "false", "Machine")

但是现在也是零星会偶尔冒一下出来（感觉并没有什么卵用）

### 进行中的解决方案 ###

基于HttpClientFactory构造HttpClient外加Polly如果失败就再来一次的模式。

## 5.迷之超时 ##

现在发觉有一部分机器会有超时的现象，而这个现象比较诡异在于IIS日志里是有记录到这次请求的（超时的请求），而作为我们站点监控的Application Insights是没收到这个请求的

暂时想法是不是因为现在IIS只是一个Reverse Proxy的角色，而IIS到达真正承载站点的kestrel的时候这个过程有问题

[![image][image 3]][image_image 3]

因为我们当前是基于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][http_blog.stephencleary.com_2017_03_aspnetcore-synchronization-context.html]

如果你对编程感兴趣或者想往编程方向发展，可以关注微信公众号【筑梦编程】，大家一起交流讨论！小编也会每天定时更新既有趣又有用的编程知识！

[image]: /images/20210812/0b60c4ad2bb847b3888f938b42ef2c4e.png
[image 1]: https://img2018.cnblogs.com/blog/658343/201904/658343-20190420132240142-2088271074.png
[Azure Devops_Tfs]: https://www.cnblogs.com/leolaw/p/10468393.html
[https_stackoverflow.com_questions_42956377_stackexchange-redis-timeout-exception-in-net-core]: https://stackoverflow.com/questions/42956377/stackexchange-redis-timeout-exception-in-net-core
[image 2]: https://img2018.cnblogs.com/blog/658343/201904/658343-20190420132240794-153919628.png
[image_image 2]: /images/20210812/35f52f9599a249af8fce61a01e24d4d4.png
[https_github.com_dotnet_corefx_issues_30691]: https://github.com/dotnet/corefx/issues/30691
[https_github.com_dotnet_corefx_pull_32903]: https://github.com/dotnet/corefx/pull/32903
[https_github.com_dotnet_corefx_issues_32902]: https://github.com/dotnet/corefx/issues/32902
[https_docs.microsoft.com_en-us_dotnet_api_system.net.http.socketshttphandler_view_netcore-2.2]: https://docs.microsoft.com/en-us/dotnet/api/system.net.http.socketshttphandler?view=netcore-2.2
[image 3]: https://img2018.cnblogs.com/blog/658343/201904/658343-20190420132241308-245165073.png
[image_image 3]: /images/20210812/1a6b22ae27f54b67b4effef2771e62b4.png
[http_blog.stephencleary.com_2017_03_aspnetcore-synchronization-context.html]: http://blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html