市场部做网站工作职责,晋江论坛网,风铃做的网站能否推广,qq电脑版网页登录入口最近将自己负责的一个核心接口系统从.Net Framework迁移到了.Net Core。整体过程#xff0c;从业务层面说一般般吧(整体还好但还是搞的业务有感#xff0c;没出严重故障#xff09;但是技术层面上感觉其实并没有达到要求#xff0c;不过预期也是应该不会那么顺利#xff0… 最近将自己负责的一个核心接口系统从.Net Framework迁移到了.Net Core。整体过程从业务层面说一般般吧(整体还好但还是搞的业务有感没出严重故障但是技术层面上感觉其实并没有达到要求不过预期也是应该不会那么顺利接下来可能还需要几个小Fix来处理各种奇奇怪怪的问题。回顾下迁移时候遇到的若干个坑希望对后续有此类操作的人所有帮助。 1.NetCore下的路由行为和Web Api的不一致我们回顾下在Web Api里时候的一个路由定义这个配置下可以让Get RootUrl/123 和 Get RootUrl?id123 同时映射到 GetThirdPartyChannel方法里。但是假如在不做改动前提下直接将这个Controller定义变为Core的话Get RootUrl?id123 这个路由将无法正常运作 (而 Get RootUrl/123 则依然可以正常运行。原因是在AspNetCore下他发现了[Route(“{Id}”)]就会认为Id是Path的一部分然后相当于隐式给id这个参数默认了[FromPath],但是[Route(“”)]这里并没有定义id作为Path。会导致一旦调用 Get RootUrl?id123 的时候首先路由是能匹配上 [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, Version1.2.0.0, Cultureneutral, PublicKeyTokennull”的字符串。而我们自己在CI的时候有一个机制是每次TFS编译的时候会自动修改dll的版本号具体可以参考以前写的文章 Azure Devops/Tfs 编译的时候自动修改版本号以前.Net Framework加载一个程序集的时候比如程序集的信息是 “ClassLibrary1.Class1, ClassLibrary1, Version1.2.0.0, Cultureneutral, PublicKeyTokennull” 其中的Version的值他是不认的随便Version是什么他都能加载咱不讨论StrongName模式而到Core之后如果Version不匹配则会报错他会认可Version的值了 解决方案暂时去掉了自动修改版本号机制固定版本号到某个值。 3.NetCore下的Redis有点诡异不稳定具体体现在好像迁移到Core之后连接Redis的链接更不稳定了无论是链接超时还是首次建立链接的成功率都显著下降。也是因为这个问题导致这次发布闹出了不该有的动静。发布那会的临时解决方案Redis的链接字符串加了,abortConnectfalse让连接不上的时候也继续跑着先吧进行中的解决方案根据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?viewnetcore-2.2 先将core2.1引入的SocketHttpHandler禁用了可以直接Powershell执行[sourcecode languagepowershell padlinenumberstrue][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 RuningIdel 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
