.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执行

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

可是如今也是零星会偶尔冒一下出来（感受并无什么卵用）

进行中的解决方案

基于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