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

关键要点

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

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

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

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

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

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

从 .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 的三个主要主题：

• .NET Core框架和SDK；

• 构建自动化；

• 应用程序监控。

.NET Core 框架和 SDK

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

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

• 紧凑的开源框架；

• 命令行界面（CLI）；

• 记录良好的开放式构建系统；

• 支持所有主要操作系统。

这些特性和其他更多功能在 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

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

执行：

dotnet help

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

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

执行：

dotnet new

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

执行：

dotnet new angular -o dotnet-angular

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

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

执行：

dotnet run

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

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

将 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 系统。以下是一个简短的示例列表：

• Jenkins；

• TFS/Visual Studio Team Services；

• CircleCI；

• TeamCity；

• GitLab。

.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