.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让连接不上的时候也继续跑着先吧

进行中的解决方案

根据

试着将代码内频繁查询的redis读取转async试试。

 

4.netcore下的http请求不稳定（时而报socketexception)

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

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

 

 

但是要说3.0才fix，等不了那么久……

 

另外已知在小访问量下好像不容易出现这个（我们之前已经有几个小站点已经是core里但是都没发生这个问题），有概率跟请求压力有关系。

 

目前的临时解决方案

参考官方文档 先将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下是没什么卵用的，参考