企业应用向ASP.NET Core迁移
<p>有人说.NET在国内的氛围越来越不行了，看博客园文章的浏览量也起不来。是不是要转Java呢？ 没有必要扯起语言的纷争，Java也好C#都只是语言是工具，各有各的利用场景。以前是C#非开源以及不能在Linux上利用，没有被互联网公司思量，但它仍旧有它的用途。这几年国内互联网公司进入发达发展时期，全部才有如许的趋势。但并不代表C#不能做互联网应用，可以说在接下来的一年内.net core将会成为一个很好的趋势，结合容器以及微服务架构会成为互联网公司另一个比较好的选择。</p><p>作为如今在用.NET的公司，假如有机会可以思量与时俱进，在真实项目中将.net core用起来。</p>
<h4 id="magicdomid3"data-author-name="Jesse">我们起首来看看ASP.NET Core有哪些优势？</h4>
<olstart="1">
<li>跨平台：可以部署到Linux服务器上</li>
<li>内置一套对云和部署环境非常友好的设置模块</li>
<li>内置依靠注入</li>
<li>IIS或者Kestrel（或者其它自定义）</li>
<li>轻量级、高性能、模块化的Http处置处罚管线</li>
<li>.NET Core 是开源的，而且基于nuget发布。 这让我们有了更大的空间去改造和扩展它</li>
<li>更易于现代化的项目开发，比如面向容器，微服务架构，对DevOps更友好</li>
</ol>
<p><div align="center"></div></p>
<p id="content_atree"><em>假如你看到这段文字，说明您正利用RSS阅读或转自《一棵树-博客园》，原文地点：https://www.cnblogs.com/atree/p/netcore-transfer.html </em></p>
公司的决议层为什么要做如许的选择？
<olstart="1">
<li>降低本钱，提拔服从</li>
<li>提拔公司的技术品牌</li>
<li>更好的留住和造就现有的开发团队，以及招募到更好的开发者</li>
</ol>
在划一用户规模的环境下，选择 Linux的服务器比Windows Server的性价比更高。在一个产物的整个实现与运营生命周期当中，编码只占了很小的一部分，另有开发与测试环境的初始化与维护，测试与集成，线上环境部署与运维这都会占用不少的时间，通过主动化可以大幅度的淘汰这些时间。而在.NET Core实现跨平台之后，让主动化的门槛降到最低。你不再需要一个资深的架构师或者专业的DevOps才可以实现，一个有经验肯学习的开发者足以应付。
<div align="center"></div>
<h1 id="magicdomid27"data-author-name="Jesse">怎样来做升级和改造 ？</h1>
说到真实产物的技术升级和改造，不伤筋动骨，不大概完成。
<olstart="1">
<li>老系统是 asp.net Web Form</li>
<li>老系统用的是WCF之类的项目</li>
<li>老系统是asp.net MVC或者WEB API</li>
</ol>
<p id="magicdomid32"data-author-name="Jesse">由于对system.web的重依懒，将Web Form迁徙到ASP.NET Core险些是不大概。假如Web Form项目利用了服务器端控件，那已经可以放弃往下走，可以实验开始一个新的项目逐步替换老的项目。假如没有利用服务器端控件，用handller在返回数据，则可以思量先将Web Form的项目进行前后端分离或者API 分离，在视图层逻辑稳固的环境下重写后端逻辑部分。固然这个代价也不小，以是转型和升级需要预备的事变有很多。</p>
<pdata-author-name="Jesse">WCF临时还不能支持.NET Core，固然微软已经启动WCF的开源和并入.NET基金会，但短时间内WCF迁徙到.NET Core另有一段时间。以是假如对WCF依懒比较重，最好临时不要思量升级。一些复杂的MVC和WEB API的项目假如依懒比较多，要升级起来也不是一件轻易的事变 。目前比较可行的方案，照旧在新项目上利用.NET Core来实现 。</p>
<pdata-author-name="Jesse">最符合的步调是先在一些新的项目上接纳ASP.NET Core来开发。就语言特性本身来说ASP.NET Core的变革不大，学习本钱也不高。但是生产环境不是随便玩的，要从无到有，过程比较艰巨，这也是很多小公司到如今还没有在生产上用上.NET Core人缘故原由之一。只有开发人员干发急，我们什么用.NET Core 呢？ </p>
与其等待你的总监做这个决定，不如本身先干起来。假如不能从无到有，那么我们可以在原来的系统上换部件：也就是我们的最小升级方案，将.NET Core部署在IIS上。
<h3 data-author-name="Jesse"> </h3>
<h3 id="magicdomid41"data-author-name="Jesse">最小升级方案：将ASP.NET Core部署在IIS上</h3>
<p id="magicdomid42"data-author-name="Jesse">关于怎样把ASP.NET Core的网站或者API部署到IIS上，网上已经有比较多的先容，可以参考这里。重要是需要先下载一个ASP.NET Core的模块安装之后再进行简单的设置，新手比较轻易忽略。假如你的IIS模块里面没有AspNetCoreModule，说明没有安装这个ASP.NET Core模块，需要进行下载安装。</p>
<div align="center"></div>
ASP.NET Core全部的项目都必须运行在Kestrel或者一个自定义的Web Server上。
<div align="center"></div>
在asp.net core 2.0时，接纳默认的WebHost.CreateDefaultBuilder().Builder() 得到的Host已将将 Kestrel和IISIntegration都添加进来。
public static void Main (string[] args) {
BuildWebHost (args).Run ();
}
public static IWebHost BuildWebHost (string[] args) {
return WebHost.CreateDefaultBuilder (args)
.UseStartup<Startup> ()
.UseKestrel (options => {
options.Listen (IPAddress.Loopback, 5000);
options.Listen (IPAddress.Loopback, 5001, listenOptions => {
listenOptions.UseHttps ("testCert.pfx", "testPassword");
});
})
.UseIISIntegration ()
.Build ()
}
<p> </p>
<p>IISIntegration其实是将IIS做一个反向署理，AspNetCoreModule的任务就是将哀求转发给Kestrel。<br /><div align="center"></div></p>
<p id="magicdomid74"data-author-name="Jesse">固然你也可以选择用Nginx或者 Apache来做反向署理，来实现ASP.NET Core在Linux上的部署。这里有一篇不错的实践贴（将ASP.NET Core应用步调部署至生产环境中（CentOS7）</p>
<p id="magicdomid76"data-author-name="Jesse">在我们的最小升级方案里面，部署到IIS是在生产环境中利用ASP.NET Core是最易实现和本钱最低的一种。剩下的，等开发人员对ASP.NET Core掌握的比较牢固，对Linux的运维也有一些经验之后可以再实验往Linux上迁徙。</p>
<h3 id="magicdomid78"data-author-name="Jesse">新老项目交互的题目</h3>
<p id="magicdomid79"data-author-name="Jesse">除了刚起步没有任何汗青负担的公司，我们大多数地点的公司都处于老系统维护和新系统开发并行的环境。在新系统的开发过程当中，少不了要与老系统打交道。比如最常用的一些其它系统的数据访问，就会面对是重写好，照旧调用老系统中的代码比较好的题目。</p>
<p id="magicdomid81"data-author-name="Jesse">这里没有明确的答案，取绝于当前业务的发展和我们所拥有的时间来决定 。人和时间够整个系统重写都可以，不敷的话我们也只能接纳系统嫁接的方式。</p>
<pdata-author-name="Jesse">根据老系统的布局重要分两种：</p>
<olstart="1">
<li>前后端未分离，就是一个大的网站</li>
<li>前后端已分离，前端和移动端直接调用ASP.NET Web API</li>
</ol>
<p><div align="center"></div></p>
第一种环境会给系统以及开发增长的复杂度是： 本地代码访问变成API访问之后的引发的题目，这也是多数团队在做服务化时起首遇到的题目。
<ul >
<li>增长额外的API访问代码 </li>
<li>增长Debug的复杂度，欠好找缘故原由</li>
</ul>
第二种环境，已经API化只是没有做拆分。那我们新写的ASP.NET Core API 可以直接被访问。这里的题目是要解决认证授权的题目包括（从客户端到Core API，以及从Core API到原来的Web API)
<div align="center"></div>
<p id="magicdomid93"data-author-name="Jesse">注：这种方案应该克制从老的ASP.NET Web API访问 ASP.NET Core的项目。最后应该是停止维护老项目，全部代码在新的ASP.NET Core上进行开发。 Proxy的计划应该按照新的框架来计划，实现可以嫁接老的API，做好被新代码替换掉的预备。</p>
<br><br/><br/><br/><br/><br/>来源：<a href="https://www.cnblogs.com/atree/archive/2019/09/15/netcore-transfer.html" target="_blank">https://www.cnblogs.com/atree/archive/2019/09/15/netcore-transfer.html</a>
页:
[1]