基于 DevOps 实践的 .NET Core 给开发者带来了哪些好处？

关键要点

\n
\n
无论你目前使用什么样的技术栈，DevOps都是值得一试的。

\n\n
\n
闭源、专有软件和构建过程与DevOps实践不兼容。

\n\n
\n
.NET Core是开源的，是基于DevOps构思和构建的。

\n\n
\n
.NET Core CLI和Roslyn API让整个交付流程变得更加开放，且具有更强的适应性强。

\n\n
\n
自动化是DevOps的重要组成部分，.NET Core从一开始就支持自动化构建和部署。

\n\n
\n
随着 .NET Core 2.0的发布（最初发布于2016年），微软拥有了一个通用、模块化、跨平台和开源的平台最新主要版本。 .NET Core 在当前版本的 .NET Framework中提供了很多API。它最初是作为下一代ASP.NET解决方案而创建的，但现在成为很多其他场景的基础，包括物联网、云计算和下一代移动解决方案。在这篇文章中，我们将探讨 .NET Core的更多优势，以及它如何在为传统的.NET开发人员带来好处的同时，还能让所有需要为市场带来强大、高性能和经济的解决方案的技术人员受益。

\n\n

从 .NET 1.0推出测试版开始，我就在开发软件。我还记得当时使用.NET感觉就像在作弊一样。我当时想，“这不是应该很难吗？我的malloc在哪里？我不需要转换指针了吗？这个框架类库用来做什么的？”

快进到2018年，我们仍然很乐意在 .NET Framework上编写代码，不必为内存分配问题而烦恼。System.Thread为我们处理线程问题，然后是BackgroundWorker，现在是Task。原先不是线程安全的FCL类现在被标记为线程安全的。想开发一个Web应用程序？它就是一个完整的框架，包含了所有必需的组件。.NET为我们提供了很多原本需要手动完成的东西。作为开发人员，我们把更多的时间花在编写业务逻辑代码上。汇编/C/C++拥护者可能会唏嘘现在的一般开发人员都不需要硬核系统编程知识，但我不会这么抱怨！

从第一个Beta版开始，.NET经历了多次迭代，其中包括了四个主要版本。最近的迭代 .NET Core是最重要的。.NET Core带来了真正的跨平台、现代CLI、构建系统和开源库，等等。这些东西都很重要，但 .NET Core的承诺不止于此，它还涉及了软件的开发和交付方式。

我开发软件已经有二十多年了，所以我还记得源码控制是为“大型”团队而保留的。“自动化”并没有真正出现在我们的词典中——除了我们为客户自动化业务流程。说得具体一点，就是构建/编译软件是由人类完成的。“构建经历”会在她自己的计算机上生成二进制文件（所以生成的文件在她自己的计算机上总能正常运行）！

将软件部署到它要运行的环境中是一个脆弱的拜占庭式过程，因为需要共享驱动器、FTP和进行手动文件复制粘贴。整合开发团队的工作是一场悲惨的死亡游行，一次又一次的回退就像玩打地鼠游戏一样。是否可以投入生产？谁知道呢？

软件正在迅速建立起对世界的兴趣，但开发、部署和运营基于软件的系统的过程却停留在图灵和Hopper时代。2008年左右发生了一场革命，这场革命被称为DevOps。

从那时起到现在，这些年我们已经看到一场运动的兴起。DevOps非常重要，它包含并可能取代之前出现的敏捷运动。我在2014年开始接触DevOps，当时我在一次大会上拿到了《凤凰项目》这本书。当我开始如饥似渴地阅读那本书时，我的会议计划被我抛到脑后。这本书讲的东西太多了。如果你正处在IT行业，即使是很短的时间，你也一定扮演过那些角色。你可以试着自己代入角色。从那以后，DevOps成了我职业生涯的焦点。

DevOps通常被认为有三个主要的“支柱”：文化、流程和技术。本文是关于DevOps的技术部分。具体地说，是关于 .NET Core为现代DevOps实践带来的技术。.NET Core 是在DevOps兴起期间构思出来的。微软显然有明确的目标，就是让 .NET Core成为DevOps时代的平台。本文将介绍 .NET Core和DevOps的三个主要主题：

\n
.NET Core框架和SDK；\n
构建自动化；\n
应用程序监控。\n

.NET Core框架和SDK

DevOps并不是孤立存在的。用于生成和交付基于软件的系统的技术可能可以支持或者阻碍DevOps实践。无论你的技术栈是怎样的，DevOps都是值得一试的。话虽如此，你选择的技术栈将对你的DevOps实践产生重大影响。

闭源、专有构建系统对DevOps来说并不友好。.NET Core是完全开源的，用于表示项目和解决方案的文件格式也有完整的文档化。现代语言和框架（如Node/JavaScript、Ruby和Python）已经具有一些常见特性：

\n
紧凑的开源框架；\n
命令行界面（CLI）；\n
记录良好的开放式构建系统；\n
支持所有主要操作系统。\n

这些特性和其他更多功能在DevOps时代变得越来越流行，因为它们具有很强的适用性和自动化能力。.NET Core 的CLI命令dotnet是 .NET Core应用程序构建过程的单一入口点。无论是什么平台，开发人员都可以在工作站上使用dotnet，用于构建代理。也就是说：我将在后续展示的所有本地开发工作都可以在MacBook Pro上进行。试着想象一下，这在三年前是不可能的事情！

使用 .NET Core的第一步是下载它。你可以在这里下载SDK。在我的MBP上有171MB。安装完毕后，打开你最喜欢的终端窗口（在Windows上我偏爱Powershell，但在Mac上我使用iTerm2）。

如果你已经很熟悉 .NET开发，那么可能已经习惯了安装大型框架。你习惯使用Visual Studio来完成开发工作。如果你是 .NET Core新手，可能会觉得有点奇怪。在使用IDE之前，我们可以使用这171兆字节的东西完成很多事情。

执行：

dotnet\n

这是一个新的CLI命令，用于与 .NET Core SDK发生交互。让我们来看一下。

执行：

dotnet help\n

这将列出CLI支持的所有命令，这个清单并不长，也没必要很长。你可能在查找哪些是与 .NET Core框架构建过程进行交互所需的，从一个新项目到已部署的应用程序。

第一步是创建一个新的应用程序。让我们来看看我们的选项。

执行：

dotnet new\n

输出的信息将列出可用的模板。在Visual Studio中你可以单击File-New Project来创建项目，但在这里我们使用命令行。我们有很多模板可选择。我偏爱Angular，所以让我们从那里开始吧。

执行：

dotnet new angular -o dotnet-angular\n

这将在新目录dotnet-angular中创建一个新的Angular项目。如果你愿意，可以手动创建目录，只是在执行dotnet new之前不要忘记更改目录，否则将在当前目录中创建项目。

如果你已经做过Angular开发，那么可能已经安装了Node。如果没有，请花点时间下载并安装它。如果确实需要安装Node，请在安装后关闭并重新打开终端。

执行：

dotnet run\n

这个命令将编译并运行应用程序（也可以通过执行dotnet build直接完成编译，而无需运行应用程序来）。这可能需要一两分钟时间，然后你将得到一些包含URL的输出：

Content root path: /Users/dswersky/dotnet-angular Now listening on: https://localhost:5001\n

将URL复制到Web浏览器中，然后等一会儿。你现在应该能看到一个在后台运行 ASP .NET Core、在前端运行Angular的简单应用程序。那么，这种体验与昔日的.NET开发体验有何不同？

你在几分钟内就创建并运行了一个 .NET Core应用程序（即使包括安装 .NET Core和Node），你可能会想到这几个问题：

我的IDE呢？

到目前为止，我们还不需要IDE，对吗？很显然，如果你想编辑这段代码，你需要使用某些工具。你可能希望使用与.NET和Angular相关的工具。“没问题”，你可能会想，“我启动Visual Studio Professional就可以了”。你可以这样做…或者你也可以下载Visual Studio Code，它提供了很多功能，而且是免费的。你可以使用Visual Studio Community，它也是免费的。关键在于，不再需要花费数百美元就可以开始基于 .NET Core的开发。

IIS呢？

这是“遗留” .NET Web应用程序开发和ASP .NET Core之间的主要区别。你可以在IIS中运行ASP .NET Core应用程序，但也可不必这么做。.NET Core是跨平台的，所以将ASP .NET Core与IIS分离也是显而易见的。我在这里列出的命令，包括dotnet run，在Windows、Mac和Linux上同样运行良好，且效果完全相同（甚至还有一个可以在Raspberry Pi上运行的ARM构建命令）。这个Angular应用程序是“编写一次，到处运行”的一个很好的示例。

不使用IIS来托管.NET应用程序已经有一段时间了。.NET Open Web Interface（OWIN）多年来一直支持“自托管”ASP.NET应用程序。这是通过代码和基础设施（通常称为“Project Katana”）来实现的。.NET Core使用了一个叫作Kestrel的HTTPS服务器。Kestrel是一款用于.NET应用程序的快速、高性能、开源的HTTPS服务器。Kestrel为ASP .NET Core网站和RESTful服务提供HTTPS，让它们可以运行在任何地方，包括Windows、Linux和容器协调器。Kestrel使ASP .NET Core应用程序变得完全独立，在基于Windows的HTTPS服务器上没有外部依赖性。

这与DevOps有什么关系？

自动化是DevOps的核心原则和实践。.NET Core提供的可移植性、CLI和开源构建系统对于DevOps实践来说至关重要。最重要的是，它们可以轻松实现构建和部署过程的自动化。可以通过编写CLI脚本来实现自动化，也可以通过编程方式直接自动化构建系统。.NET Core的这些功能使其不仅可以实现自动化，而且可以相对轻松地自动执行复杂的构建过程。我们因此能够建立自动化和持续集成。

.NET Core构建自动化

回到Visual SourceSafe时代，团队提交到存储库的代码就在那里，随时准备好进行编译。我的脑海里浮现出一个想法——“为什么我要在我的系统上构建部署，因为构建原本可以在存储库中进行？”我不是唯一一个有这种想法的人，但却没有对此采取什么行动。真正采取行动的是那些开始着手开发持续集成（CI）系统的勇士们。

CI的目标说起来很简单，但实现起来并不那么容易：

始终有一个可部署的构建。

软件开发是一项团队运动。Agile/Scrum团队平均有三到五名全职开发人员负责贡献代码。为了提升效率，他们之间进行了分工。然后他们开发的代码必须作为一个整体进行组合、构建和测试，而且必须使用未安装开发人员工具的系统进行自动化测试。理想情况下，在每次将新代码合并到指定分支时都应该进行构建和测试。CI系统通常直接与源码控制系统集成，每次分支发生变更时触发新构建。

Roslyn是一款开源的.NET编译器，提供了大量可直接访问的API。CI系统开发人员使用这些编译器API来构建插件，从而自动化.NET构建过程。.NET Core构建工具提供了对构建过程的细粒度控制。开发人员可以使用它们来调整和扩展现有的CI系统功能，以涵盖几乎任何可以想象的构建管道用例。你可以不是CI系统开发人员，但你可以构建插件。CI系统的维护者和供应商竭尽全力使他们的系统易于扩展。

现在有很多CI系统。以下是一个简短的示例列表：

\n
Jenkins；\n
TFS/Visual Studio Team Services；\n
CircleCI；\n
TeamCity；\n
GitLab。\n

.NET Core提供的灵活性让它可以与任何CI系统集成，这就像使用CLI脚本或者使用编译器API开发的插件直接自动化构建一样简单。

如果你目前拥有自己喜欢的CI系统，可以尝试一下我的示例项目。这与我们之前使用CLI创建的项目是一样的，只是多了一点东西。存储库包含了一个Dockerfile，我花了大约十分钟来创建一个VSTS构建管道、从Github中拉取代码、构建镜像，然后将其推送到Azure容器注册表。这与AWS或Google Cloud中的Jenkinsfile或GitLab管道一样好用。正如他们所说，一切皆有可能。

使用 .NET Core进行应用程序监控

软件系统的运维是一项全职工作，可以让Ops团队的同事来负责。这些系统就像婴儿一样——它们不断地叫啼，需要获得父母的关注。Ops工作人员通常就像陷入困惑的父母一样，不知道为什么系统会发生这样那样的问题。系统如何引起人们注意？这取决于你是如何照看它们的！

最糟糕的系统监控方式就是不进行监控。无论你是否或者以某种方式进行监控，在它们出现故障时都会被注意到。当你的客户疯狂地打进客服电话或者完全弃用你的服务时，你会发现已经太晚了。应用程序监控的目标是抢在客户或最终用户之前检测出问题。很多公司做出错误的经济判断，他们认为应用程序监控过于昂贵，或者认为“好的系统不需要监控”。

即使是最稳定的系统离灾难性事故也只有一步之遥。DevOps实践尝试在安全性和速度之间做出平衡——同时让公司可以通过快速移动进行创新。我们通过密切关注系统的运行参数来维持这种平衡。

.NET Core的设计和架构非常适用进行应用程序监控。ASP .NET Core是一个很好的例子。我们可以使用HTTP模块自定义在IIS上运行的ASP .NET 3.x/4.x应用程序的内部请求和响应行为。ASP .NET Core使用中间件改进了这种模型，中间件概念类似于HTTP模块，但在实现方面却非常不一样。中间件类通过代码进行集成，并且配置起来要简单得多。它们形成了一个请求/响应管道链。

将中间件注入ASP .NET Core应用程序是非常容易的。我将演示一个Azure Application Insights示例。我在Azure Portal中创建了一个Application Insights资源，然后在我的存储库中编辑了三个文件来启用Application Insights监控：

dotnet-angular.csproj

添加了一行来引用Application Insights资源（之所以需要这个手动步骤，是因为我使用的是Visual Studio for Mac，详细信息请参见这里）。

appsettings.json

添加了我的Application Insights密钥。

Startup.cs

Startup.cs是配置中间件的地方。我在这里添加了Application Insights中间件。

完成这些工作后，我就能够在本地进行调试，并收集来自Application Insights的监控数据。你可以自己尝试一下，只需要用你的密钥替换appsettings.json中的示例密钥即可。

当然，Application Insights并不是监控应用程序的唯一选择。AppMetrics是一个开源监控库，可与Grafana等可视化工具集成。一些供应商也提供了付费选项。

所有这些监控方案都提供了能够在运行时环境中查看应用程序行为的透明度，这对于DevOps实践来说至关重要，因为它可以在不影响系统性能的情况下让你验证对系统所做的更改。然后，你可以添加新功能，并确信快速变更不会破坏已有的东西。

结论

.NET Core是在考虑DevOps实践的情况下构思和开发出来的。CLI和开放式构建系统和库让软件交付过程自动化变得可能。如果你愿意，可以通过CLI脚本或更深入的编程集成来实现构建自动化和持续集成。使用开源或付费企业工具进行应用程序监控可将你的系统从黑匣子转变为透明的玻璃窗格。基于DevOps实践的 .NET Core是现代软件系统的一个非常具有吸引力的平台。

关于作者

Dave Swersky，从事IT工作已超过20年，从支持工程师到软件开发人员，再到企业架构师。他是一个有抱负的多面手，并且对DevOps充满热情。他曾在很多与DevOps相关的大会上做过演讲，包括DevOps企业峰会、CodeMash、Stir Trek以及KC的本地聚会。Dave还写了一本关于DevOps的书：DevOps Katas: Hands-On DevOps。可以通过Twitter账号@dswersky找到Dave。

查看英文原文：.NET Core and DevOps