.NetCore技术研究-.NET Core迁移前的准备工作

前段时间迁移.NET Core做了大量的试水和评估,今天整理一下分享给大家。大致有以下几个部分:

1. .NET Core的由来

2. 为什么要迁移.NET Core

3. .NET Core3.X主要特性

4. .NET Standard和.NET Core

5. .NET Core Roadmap&版本选择

接下来,我们详细展开说吧。

一、.NET Core的由来

   这个更像是科普的资料,因为团队的小伙伴有半路出家的,对.NET 的光辉历史不是非常了解,所以有必要带着大家看一遍.NETCore的由来:

   说.NET Core,需要先说一下.NET. 当年Java刚刚兴起,如火如荼,微软也非常推崇Java,当时Windows平台的Java虚拟机就是微软按照JVM标准实现的,据说也是当时性能最好的Java虚拟机。但是微软也是有私心的,微软总想搞点Windows平台上的特性,有点想把Java绑定到Windows平台上的味道,另外Sun公司确实有点小心眼,于是Sun公司就跟微软闹掰了,然后微软就推出了 .NET,.NET从出生开始其实就借鉴了Java,然后又一步步在语言特性、窗体开发等方面实现了超越。Java在1.6版本以后发展缓慢,后面Java也在语言特性上借鉴了 .NET。

   .NET虽然一直发展的不错,也有WPF、Unity3D这样具有竞争力框架的出现。但是.NET平台在一些较大的项目,不太受互联网公司的喜爱(虽然京东、当当、携程当年也是.NET技术路线)。但是因为.NET不是开源的框架,也不是可跨平台的框架,那就会带来以下问题:

     成本:选择.NET就要选择Visual Studio,Windows Server,license是不可忽视的成本;

     生态:没有来自于社区的贡献,那.NET没有诞生优秀框架的土壤,技术社区虽然有微软的特殊扶持,但是整体不太理想

     人才:无法吸引一线公司优秀互联网工程师加入,因为他们用Java、Go等,但是.NET Core诞生之后会大为改观,腾讯、网易都有在使用。

    纵使有Mono这么强大的框架,可以让 .NET 跑在Linux上,但是这还不够。毕竟Mono只能发挥.NET部分有限的能力。

    同时,云计算的普及,跨平台需求势不可挡,Linux 作为Server的不二OS,.NET不支持Linux,比较尴尬!

    另外,容器时代已经不可逆转,跟Windows的强依赖,如何上Docker?

    总之,形式所迫,拥抱变化和未来,.NET Core应运而生。

二、为什么要迁移.NET Core

   总结了以下几点,大家可以补充:

  • .NET Core代表着未来.Net的发展方向
  • 产品新特性、重点技术支持微软优先考虑在最新.NET Core版本上支持
  • 更优的代码、更好的性能,社区大家都在贡献、优化代码
  • 跨平台支持,支持部署在Linux,可以降低VM的成本
  • Docker部署支持,更低的成本,更高的资源利用率,未来云原生的核心组成
  • 面向现代互联网应用、微服务架构、和DevOps更好地集成
  • 开源:https://github.com/dotnet/core
  • 更好的生态和社区

三、 .NET Core3.X主要特性

   同时支持Windows和Linux、MacOS,满足不同开发者的需求,对于Web开发提供了ASP.NET Core,对于常用数据库访问,提供了EF Core,对于机器学习,提供了ML.NET。大家可以根据自己业务的需要,选择合适的技术。

四、 .NET Standard和.NET Core

 先说下事情的起源:

 .NET Framework从2002年起,一直在Release新版本,不支持跨平台

 .NET Core是为了支持跨平台产生的,类似的有Mono、Xamarin

  这样,出现了两套代码、两套类库,对于开发者来说,要同时掌握两套SDK,会产生社区和技术的分裂。

  因此,.NET 要统一类库标准,统一所有的API定义,这就是.NET Standard. 如下图:

  

 .NET Standard的统一:

  .NET Standard定义了.NET平台,统一实现的一组API。实现.Net Standard API的平台都与目标.Net Standard库兼容;

  .NET Framework和.NET Core都是.NET Standard的标准实现。 .NET Standard是二者的交集。

   但是.NET Framework和.NET Core存在其个性化、扩展的类库,需要牺牲兼容性,即:

   假如用.NET Framework的个性化SDK。例如注册表、Windows Service、Winform,这样只能部署在Windows中。

   假如用.NET Core的个性化SDK,部署运行时,与Windows环境下.NET Framework不兼容。

   所以,如果应用程序采用.NET Standard,同时支持.NET Framework和.NET Core,则可以实现两者的兼容。一套代码既支持运行在.NET Framework运行时下,又支持运行在.NET Core运行时下。

   同时.NET Standard的版本对应.NET Core、.NET Framework、Mono、Xamarin等的版本,有个对照表:

   

   这张表非常重要。体现了一个规则:

   假如程序的目标框架Targetframework 使用.NET Standard2.0,则支持:

   .NET Core 2.0版本的工程可以引用

   .NET 4.6 版本的工程可以引用

    但是低版本的.NET Core和.NET Framework则无法引用。

五 .NET Core Roadmap&版本选择

 先看一下.NET Core最新的Roadmap:

  

 最新的.NET Core 3.1 将2019年11月发布,同时是LTS版本。如果大家现在开始迁移.NET Core,建议选择一个大版本、LTS版本。我们也将选择这个版本。

 

周国庆

2019/10/03

 

  

   

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


在上文中,我介绍了事件驱动型架构的一种简单的实现,并演示了一个完整的事件派发、订阅和处理的流程。这种实现太简单了,百十行代码就展示了一个基本工作原理。然而,要将这样的解决方案运用到实际生产环境,还有很长的路要走。今天,我们就研究一下在事件处理器中,对象生命周期的管理问题。事实上,不仅仅是在事件处理器
上文已经介绍了Identity Service的实现过程。今天我们继续,实现一个简单的Weather API和一个基于Ocelot的API网关。 回顾 《Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权(一)》 Weather API Weather
最近我为我自己的应用开发框架Apworks设计了一套案例应用程序,并以Apache 2.0开源,开源地址是:https://github.com/daxnet/apworks-examples,目的是为了让大家更为方便地学习和使用.NET Core、最新的前端开发框架Angular,以及Apwork
HAL(Hypertext Application Language,超文本应用语言)是一种RESTful API的数据格式风格,为RESTful API的设计提供了接口规范,同时也降低了客户端与服务端接口的耦合度。很多当今流行的RESTful API开发框架,包括Spring REST,也都默认支
在前面两篇文章中,我详细介绍了基本事件系统的实现,包括事件派发和订阅、通过事件处理器执行上下文来解决对象生命周期问题,以及一个基于RabbitMQ的事件总线的实现。接下来对于事件驱动型架构的讨论,就需要结合一个实际的架构案例来进行分析。在领域驱动设计的讨论范畴,CQRS架构本身就是事件驱动的,因此,
HAL,全称为Hypertext Application Language,它是一种简单的数据格式,它能以一种简单、统一的形式,在API中引入超链接特性,使得API的可发现性(discoverable)更强,并具有自描述的特点。使用了HAL的API会更容易地被第三方开源库所调用,并且使用起来也很方便
何时使用领域驱动设计?其实当你的应用程序架构设计是面向业务的时候,你已经开始使用领域驱动设计了。领域驱动设计既不是架构风格(Architecture Style),也不是架构模式(Architecture Pattern),它也不是一种软件开发方法论,所以,是否应该使用领域驱动设计,以及什么时候使用
《在ASP.NET Core中使用Apworks快速开发数据服务》一文中,我介绍了如何使用Apworks框架的数据服务来快速构建用于查询和管理数据模型的RESTful API,通过该文的介绍,你会看到,使用Apworks框架开发数据服务是何等简单快捷,提供的功能也非常多,比如对Hypermedia的
在上一讲中,我们已经完成了一个完整的案例,在这个案例中,我们可以通过Angular单页面应用(SPA)进行登录,然后通过后端的Ocelot API网关整合IdentityServer4完成身份认证。在本讲中,我们会讨论在当前这种架构的应用程序中,如何完成用户授权。 回顾 《Angular SPA基于
Keycloak是一个功能强大的开源身份和访问管理系统,提供了一整套解决方案,包括用户认证、单点登录(SSO)、身份联合、用户注册、用户管理、角色映射、多因素认证和访问控制等。它广泛应用于企业和云服务,可以简化和统一不同应用程序和服务的安全管理,支持自托管或云部署,适用于需要安全、灵活且易于扩展的用
3月7日,微软发布了Visual Studio 2017 RTM,与之一起发布的还有.NET Core Runtime 1.1.0以及.NET Core SDK 1.0.0,尽管这些并不是最新版,但也已经从preview版本升级到了正式版。所以,在安装Visual Studio 2017时如果启用了
在上文中,我介绍了如何在Ocelot中使用自定义的中间件来修改下游服务的response body。今天,我们再扩展一下设计,让我们自己设计的中间件变得更为通用,使其能够应用在不同的Route上。比如,我们可以设计一个通用的替换response body的中间件,然后将其应用在多个Route上。 O
不少关注我博客的朋友都知道我在2009年左右开发过一个名为Apworks的企业级应用程序开发框架,旨在为分布式企业系统软件开发提供面向领域驱动(DDD)的框架级别的解决方案,并对多种系统架构风格提供支持。这个框架的开发和维护我坚持了很久,一直到2015年,我都一直在不停地重构这个项目。目前这个项目在
好吧,这个题目我也想了很久,不知道如何用最简单的几个字来概括这篇文章,原本打算取名《Angular单页面应用基于Ocelot API网关与IdentityServer4ʺSP.NET Identity实现身份认证与授权》,然而如你所见,这样的名字实在是太长了。所以,我不得不缩写“单页面应用”几个字
在前面两篇文章中,我介绍了基于IdentityServer4的一个Identity Service的实现,并且实现了一个Weather API和基于Ocelot的API网关,然后实现了通过Ocelot API网关整合Identity Service做身份认证的API请求。今天,我们进入前端开发,设计
Ocelot是ASP.NET Core下的API网关的一种实现,在微服务架构领域发挥了非常重要的作用。本文不会从整个微服务架构的角度来介绍Ocelot,而是介绍一下最近在学习过程中遇到的一个问题,以及如何使用中间件(Middleware)来解决这样的问题。 问题描述 在上文中,我介绍了一种在Angu
在大数据处理和人工智能时代,数据工厂(Data Factory)无疑是一个非常重要的大数据处理平台。市面上也有成熟的相关产品,比如Azure Data Factory,不仅功能强大,而且依托微软的云计算平台Azure,为大数据处理提供了强大的计算能力,让大数据处理变得更为稳定高效。由于工作中我的项目
在上文中,我们讨论了事件处理器中对象生命周期的问题,在进入新的讨论之前,首先让我们总结一下,我们已经实现了哪些内容。下面的类图描述了我们已经实现的组件及其之间的关系,貌似系统已经变得越来越复杂了。其中绿色的部分就是上文中新实现的部分,包括一个简单的Event Store,一个事件处理器执行上下文的接
在之前《在ASP.NET Core中使用Apworks快速开发数据服务》一文的评论部分,.NET大神张善友为我提了个建议,可以使用Compile As a Service的Roslyn为语法解析提供支持。在此非常感激友哥给我的建议,也让我了解了一些Roslyn的知识。使用Roslyn的一个很大的好处
很长一段时间以来,我都在思考如何在ASP.NET Core的框架下,实现一套完整的事件驱动型架构。这个问题看上去有点大,其实主要目标是为了实现一个基于ASP.NET Core的微服务,它能够非常简单地订阅来自于某个渠道的事件消息,并对接收到的消息进行处理,于此同时,它还能够向该渠道发送事件消息,以便