为什么选择.NET Core

在开始这个话题之前我们来看下ASP.NET Core的性能表现： https://github.com/aspnet/benchmarks

ASP.NET Core的基准测试，包括（但不限于）TechEmpower Web框架基准测试中的场景 。 ASP.NET 团队的最新的结果参看https://aka.ms/aspnet/benchmarks。

• 如果你是.NET Framework开发人员

.NET Core是为了重写某些.NETFramework组件而为其他人提供跨平台工作的机会。由于.NET Framework主要以托管（C＃）代码为基础构建，因此这些部分不需要更改代码即可迁移到.NET Core。依赖于Windows特定组件的库必须被移除或重构以使用跨平台替代方案。这同样适用于您的应用程序。

• 您的.NET应用程序可以是跨平台的

您现有的.NET Framework应用程序是可以在其他操作系统上工作。对于希望扩大类库的受众平台，或者希望在分布式应用程序的其他领域使用相同代码的开发人员来说，这是非常好的选择。即使你想在MacBook上开发.NET，而无需在MAC上安装双系统来启动到Windows。

• ASP.NETCore胜过ASP.NET框架

ASP.NET Core和ASP.NET之间的性能差异是几个数量级。大部分的ASP.NET被传统的System.Web库所限制。.NET Framework支持旧版本的ASP.NET项目，而且这个约束限制了ASP.NET的发展。微软决定重写整个架构。这意味着打破变化，但结果是值得的。

• .NETCore是创新的焦点

向后兼容性是一把双刃剑。这意味着您的应用程序可以继续得到新版本框架的支持，确保在新版本框架中所做的更改不会破坏现有的应用程序。

所有的努力避免变化都限制了框架的创新。框架的变化需要彻底的理由（通常来自客户），详尽的测试以及来自多个层次产品组的批准。

使用.NET Core，团队可以更容易专注的在.net core上工作。比如核心类库（如System.Collections）的更改仍然需要与.NET Framework相同的活力，但是ASP.NET Core或Entity Framework Core可以更轻松地进行实质性更改，而不受向后兼容性的限制。这允许更大的创新。

.NET Framework作为一个整体产品发布，但是Core被分解成多个部分。现在开发人员可以选择使用哪个版本的库，只要它在.NET标准库之内，.NET Core团队就可以用较少的难度进行创新。这就是为什么在将来你只能看到错误修复的.NET Framwork, 也就是说不会有.NET Framewok 5.0,其实.NET Framewok 5.0就是.NET Core 1.0了; .net core将获得所有新功能。

• 发布周期更快

如果您曾在框架中遇到错误，并将其报告给Microsoft，则您将知道发布修复需要多长时间。这个框架有很长的发布周期，通常至少要测量一年，而且在这些周期中还有很小的窗口用于特性工作。每个代码更改都可能会导致框架中其他位置出现意外的问题。为了给每个团队足够的时间来测试框架，有很多时候代码更改是受限制的或者严格审查的。如果您在.NET中发现了一个错误，最好找到一个解决方法，而不是等待更新。

.NET Core遵循更快的发布步调。开发人员可以使用夜间构建来尽早测试。不属于.NET标准库的库可以按自己的步调发布。因为所有东西都是开源的，如果微软没有足够快的响应，任何开发者都可以提出修补。如果解决方法不被接受，讨论就会公开进行，所有人都可以看到为什么做出这个决定

• 如果你是.NET新手

在Windows平台上，.NET Framework没有太多的竞争。微软可以对从操作系统内核层到高级.NET库的所有内容进行更改。通过将.NET引入其他平台，比如Linux，竞争环境发生了变化。.NET现在必须与其他所有的开发框架竞争。这里有一些东西，促使.NET分开。

• C＃是一个了不起的语言

.NET的旗舰语言C＃具有许多独特的功能，例如LINQ和await/async，这使得它强大且易于使用。C＃也在不断创新。C＃团队公开设计语言，因为他们希望任何人提出建议或参与讨论。编译器（Roslyn）完全是模块化和可扩展的。

• ASP.NET Core性能与顶级Web平台相当

如果您正在编写Web应用程序或服务，那么ASP.NET Core是一个很好的搭建平台。它具有出色的性能和低内存占用。许多功能可以使您的应用程序更容易开发和维护

ASP.NET是2002年发布的第一个.NET Framework版本，并不断发展。尽管ASP.NET取得了成功，但在ASP.NET团队中却感觉到他们正在失去开发人员，因为ASP.NET的性能没有竞争力，只能在Windows平台上运行。

一家名为TechEmpower的公司每隔几个月就会运行一次Web应用程序平台的基准测试，并提供一个分为几类的排名。基准测试在Linux上运行，仅包含Windows平台。对于ASP.NET团队来说，这很麻烦。许多平台都用于编写跨平台的Web应用程序，并且其性能数据令人印象深刻。此外，一些Java框架发布了天文数字，例如每秒570万个明文请求，或者490万个。

在TechEmpower基准测试的第十一轮中，Mono平台上的ASP.NET MVC被纳入测试。结果不好。Mono上的ASP.NET每秒只有2000个明文请求。Mono不是由Microsoft创建的，是开源社区实现，它不会像普通的.NET Framework那样得到相同数量的性能调整。为了获得更公平的比较，ASP.NET团队决定在与TechEmpower相同的硬件上运行.NET 4.6的基准测试。结果是每秒约50,000个请求。仍然没有接近NodeJS（每秒320,000个请求），或TechEmpower列表上的其他任何顶级框架。

可怜的低分并不意外。如前所述，ASP.NET知道改变现状只能通过重写整个架构来清除障碍。这正是发生的事情。

ASP.NET团队着手构建ASP.NET Core，几个月后，该团队庆祝asp.net core每秒超过100万个请求。最新asp.net core 性能已经跨入顶级序列，我们来看最新一期的TechEmpower基准测试第十七轮测试，

17轮的测试使用的是ASP.NET Core 2.1

• .NET Core不是从头开始的

.NET在2000年就已经出现了。.NET Framework代码在过去几年中已经得到了巩固，开发人员也从中受益。已经被移植到.NET Core的大部分.NET Framework代码都没有改变。这使得.NET Core在构建应用程序的可靠框架方面领先一步。.NET Core也完全由Microsoft支持。这降低了为您的应用程序使用.NET Core的风险。

2016年，微软收购了Xamarin并发布了.NET Core 1.0。Xamarin构建于开源的Mono之上，之前Mono已经移植了.NET框架的大部分内容来运行在基于Linux / Unix的操作系统上。.NET Core也受益于Mono 十几年的跨平台经验。

• .NET Core的关键功能

.NET Core借鉴了.NET Framework的最佳实践，并将软件工程的最新进展结合在一起。这些是.NET Core的一些显着特征。

同一个库可以在后台服务“本地”或云中运行，也可以在手机，平板电脑或桌面上运行的客户端应用程序中运行。与其为iOS，Android和Windows构建单独的应用程序，您可以构建一个适用于所有平台的应用程序。.NET Core是小型和完美的容器，可以轻松扩展并缩短开发时间。

.NET Core和.NET Standard Library建立了一个通用平台。过去，当新版本的操作系统或新设备出现时，开发人员有责任重新构建新平台的应用程序或库，并分发更新。使用.NET Core，不需要重建和重新分配。只要新的平台支持你所有的依赖库，它就支持你的应用程序。

• 在任何平台上简单部署

Microsoft产品往往具有复杂的安装过程。COM组件，注册表项，特殊文件夹，GAC - 都是为了利用Windows的特性而设计的。.NET Framework依赖于这些构造，这使得它不适合其他操作系统。

在发布依赖于.NET Framework的应用程序时，安装程序必须足够聪明才能检测是否安装了正确的.NET Framework版本，并为用户提供正确的方法。大多数现代Windows版本都包含.NET Framework。这使得某些应用程序更容易安装，但是如果应用程序使用默认情况下未安装的功能（如ASP.NET与IIS或WCF组件的集成），则可能会导致复杂的问题。

另一个复杂的问题来自补丁。包括错误修复或安全更新的修补程序可以通过Windows更新或通过Microsoft下载中心分发给客户。您测试应用程序的.NET Framework可能与客户使用的补丁程序不同。当您假定.NET Framework对于所有客户都是一样的时候，通常很难确定在应用程序中导致奇怪行为的原因。

.NET Core的模块化设计意味着您只包含所需的依赖关系。所有这些依赖关系与您的应用程序进入相同的文件夹。部署应用程序与复制文件夹一样简单。这种方法的另一个优点是可以有多个版本并行运行。这个策略对于使所有平台的部署体验保持一致至关重要。

• 云和容器

云系统中，用更少的硬件为更高密度的用户提供服务是非常重要的。应用程序的占位面积越小，密度越高。虚拟机已经在云端普遍存在多年，但是它们有几个问题：

• 大小 - 一个典型的虚拟机文件是千兆字节，如果不是几十千兆字节。这使得它们跨网络传输非常耗时，并且对磁盘空间有很大的要求。
• 启动时间 - 启动虚拟机意味着启动操作系统。对于Windows来说，这是一个挑战，因为启动新机器需要花费时间。这可以使处理突发交通困难。
• 内存 - 虚拟机需要将整个操作系统与应用程序一起加载到内存中。这意味着很多主机的内存被浪费了。
• 不一致性 - 相同的虚拟机可以复制到多个主机，主机必须提供相同的虚拟化硬件，这可能依赖于物理硬件。无法保证虚拟机在任何给定的主机上运行相同的操作。

容器通过虚拟化操作系统来解决虚拟机的问题。容器只包含应用程序及其依赖项。文件大小要小很多倍，启动时间以秒为单位，只有应用程序加载到内存中，容器保证在任何主机上工作。

内置于Windows的.NET Framework现在也可以容器上运行，但是镜像文件特别大。鉴于容器的明显优势，.NET Core的设计决定之一就是使其成为模块化。这意味着你的.NET Core应用程序可以被“发布”，使得它和它的所有依赖关系在一个地方，这很容易放入容器。