当前位置：首页 > 云 & 计算 > 正文

【微软】微软眼里的云原生技术

云 & 计算
2022-11-17
941
更新：2022-11-17 16:50:26

停下你正在做的事情，让你的同事给“云原生”这个词下个定义。您很有可能会得到几个不同的答案。

让我们从一个简单的定义开始：

> *云原生架构和技术是一种设计、构建和操作在云中构建并充分利用云计算模型的工作负载的方法。*

[云原生计算基金会](https://www.cncf.io/)给出了[官方定义](https://github.com/cncf/foundation/blob/master/charter.md)：

> 云原生技术使组织能够在公有云、私有云和混合云等现代动态环境中构建和运行可扩展的应用程序。容器、服务网格、微服务、不可变基础设施和声明式 API 就是这种方法的例证。

> 这些技术使松散耦合的系统具有弹性、可管理和可观察性。结合强大的自动化，它们使工程师能够以最少的工作量频繁且可预测地进行高效率的更改。

云原生是关于**速度**和**敏捷性**的。业务系统正在从支持业务能力演变为加速业务速度和增长的战略转型武器。立即将新想法推向市场势在必行。

同时，业务系统也变得越来越复杂，用户要求越来越高。他们期望快速响应、创新功能和零停机时间。性能问题、反复出现的错误和无法快速行动不再是可以接受的。您的用户将访问您的竞争对手。云原生系统旨在拥抱快速变化、大规模和弹性。

以下是一些已实施云原生技术的公司。想想他们已经实现的速度、敏捷性和可扩展性。

如您所见，Netflix、Uber 和微信公开了由许多独立服务组成的云原生系统。这种架构风格使他们能够快速响应市场状况。他们可以即时更新实时、复杂应用程序的小区域，而无需完全重新部署。他们根据需要单独扩展服务。

## 云原生的支柱

云原生的速度和敏捷性源于许多因素。最重要的是**云基础设施**。但不仅如此：图 1-3 中显示的其他五个基础支柱也为云原生系统提供了基石。

<center>图 1-3 云原生基础支柱
</center>

让我们花些时间来更好地理解每个支柱的重要性。

## 云端

云原生系统充分利用了云服务模型。

这些系统旨在在动态的虚拟化云环境中蓬勃发展，广泛使用[平台即服务 (PaaS)](https://azure.microsoft.com/overview/what-is-paas/)计算基础架构和托管服务。他们将底层基础设施视为**一次性**的——通过自动化在几分钟内提供并按需调整大小、缩放或销毁。

考虑一下[宠物与牛/Pets vs Cattle](https://medium.com/@Joachim8675309/devops-concepts-pets-vs-cattle-2380b5aab313)中的被广泛接受的 DevOps 概念。在传统的数据中心，服务器被视为**宠物**：一台物理机器，被赋予一个有意义的名字，并受到**照顾**。您可以通过向同一台机器添加更多资源（向上扩展）来扩展。如果服务器生病了，您可以通过护理使其恢复健康。如果服务器不可用，每个人都会注意到。

**Cattle**服务模型不同。您将每个实例配置为虚拟机或容器。它们是相同的，并分配了一个系统标识符，例如 Service-01、Service-02 等。您可以通过创建更多它们（向外扩展）来扩展。当一个变得不可用时，没有人会注意到。

Cattle模型包含**不可变的基础设施**。服务器未被修复或修改。如果一个失败或需要更新，它会被销毁并提供一个新的——所有这些都是通过自动化完成的。

云原生系统采用 Cattle 服务模型。它们会随着基础设施的扩展或缩小而继续运行，而不管它们运行的机器是什么。

Azure 云平台支持这种具有自动缩放、自我修复和监控功能的高弹性基础设施。

## 现代设计

您将如何设计云原生应用程序？你的架构会是什么样子？您会遵守哪些原则、模式和最佳实践？哪些基础设施和运营问题很重要？

### 十二因素应用

一种被广泛接受的构建基于云的应用程序的方法是[十二因素应用程序](https://12factor.net/)。它描述了一组原则和实践，开发人员可以遵循这些原则和实践来构建针对现代云环境优化的应用程序。特别注意跨环境的可移植性和声明性自动化。

虽然适用于任何基于 Web 的应用程序，但许多从业者认为十二因素是构建云原生应用程序的坚实基础。基于这些原则构建的系统可以快速部署和扩展并添加功能以快速响应市场变化。

下表重点介绍了十二因素方法：

在《 [Beyond the Twelve-Factor App](https://content.pivotal.io/blog/beyond-the-twelve-factor-app) 》一书中，作者凯文霍夫曼详细介绍了最初的 12 个因素（写于 2011 年）。此外，他还讨论了反映当今现代云应用程序设计的三个额外因素。

我们将在本章和整本书中提到许多 12+ 因素。

### Azure 架构完善的框架

设计和部署基于云的工作负载可能具有挑战性，尤其是在实施云原生架构时。Microsoft 提供行业标准最佳实践来帮助你和你的团队提供强大的云解决方案。

[Microsoft Well-Architected Framework](https://learn.microsoft.com/en-us/azure/architecture/framework/)提供了一组指导原则，可用于提高云原生工作负载的质量。该框架由卓越架构的五个支柱组成：

| 信条                                                         | 描述                                                         |
| :----------------------------------------------------------- | :----------------------------------------------------------- |
| [成本管理](https://learn.microsoft.com/en-us/azure/architecture/framework/#cost-optimization) | 专注于尽早产生增量价值。应用**构建-测量-学习**原则来加快上市时间，同时避免资本密集型解决方案。使用现收现付策略，在扩展时进行投资，而不是预先进行大量投资。 |
| [卓越运营](https://learn.microsoft.com/en-us/azure/architecture/framework/#operational-excellence) | 自动化环境和操作以提高速度并减少人为错误。快速向后或向前滚动问题更新。从一开始就实施监控和诊断。 |
| [性能效率](https://learn.microsoft.com/en-us/azure/architecture/framework/#performance-efficiency) | 有效地满足对您的工作负载提出的要求。支持横向扩展（向外扩展）并将其设计到您的系统中。持续进行性能和负载测试以确定潜在的瓶颈。 |
| [可靠性](https://learn.microsoft.com/en-us/azure/architecture/framework/#reliability) | 构建既有弹性又可用的工作负载。弹性使工作负载能够从故障中恢复并继续运行。可用性可确保用户始终访问您的工作负载。设计应用程序以预期故障并从故障中恢复。 |
| [安全](https://learn.microsoft.com/en-us/azure/architecture/framework/#security) | 在应用程序的整个生命周期中实施安全性，从设计和实施到部署和运营。密切关注身份管理、基础设施访问、应用程序安全以及数据主权和加密。 |

首先，Microsoft 提供了一组[在线评估](https://learn.microsoft.com/en-us/assessments/?mode=pre-assessment&session=local)，以帮助你根据五个架构良好的支柱评估当前的云工作负载。

## 微服务

云原生系统采用微服务，这是一种用于构建现代应用程序的流行架构风格。

微服务构建为一组分布式的小型独立服务，通过共享结构进行交互，具有以下特征：

<span>◼ </span>每个都在更大的域上下文中实现特定的业务功能。

<span>◼ </span>每个都是自主开发的，可以独立部署。

<span>◼ </span>每个都是独立的，封装了自己的数据存储技术、依赖项和编程平台。

<span>◼ </span>每个都在自己的进程中运行，并使用标准通信协议（例如 HTTP/HTTPS、gRPC、WebSockets 或[AMQP](https://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol) ）与其他进程通信。

<span>◼ </span>它们组合在一起形成一个应用程序。

图 1-4 对比了单体应用程序方法和微服务方法。请注意整体式架构是如何由分层架构组成的，该架构在单个进程中执行。它通常使用关系数据库。然而，微服务方法将功能分成独立的服务，每个服务都有自己的逻辑、状态和数据。每个微服务都托管自己的数据存储。

<center>图 1-4 单体与微服务架构
</center>

请注意微服务如何促进本章前面讨论的[十二因素应用程序中的](https://12factor.net/)**流程**原则。

> *因素 #6 指定“每个微服务都应该在自己的进程中执行，与其他正在运行的服务隔离。”*

### 为什么要微服务？

微服务提供敏捷性。

在本章的前面，我们比较了作为单体构建的电子商务应用程序与微服务构建的电子商务应用程序。在示例中，我们看到了一些明显的好处：

<span>◼ </span>每个微服务都有一个自治的生命周期，可以独立演化和频繁部署。您不必等待季度发布来部署新功能或更新。您可以更新实时应用程序的一小部分，而中断整个系统的风险较小。无需完全重新部署应用程序即可进行更新。

<span>◼ </span>每个微服务都可以独立扩展。您无需将整个应用程序作为一个单元进行扩展，而是仅扩展那些需要更多处理能力以满足所需性能级别和服务级别协议的服务。细粒度扩展可以更好地控制您的系统，并有助于降低总体成本，因为您可以扩展系统的一部分，而不是全部。

[.NET Microservices: Architecture for Containerized .NET Applications](https://dotnet.microsoft.com/download/thank-you/microservices-architecture-ebook)是了解微服务的优秀参考指南。这本书深入探讨了微服务设计和架构。[它是全栈微服务参考架构](https://github.com/dotnet-architecture/eShopOnContainers)的配套产品，可从 Microsoft 免费下载。

### 开发微服务

可以在任何现代开发平台上创建微服务。

Microsoft .NET 平台是一个很好的选择。免费且开源，它具有许多简化微服务开发的内置功能。.NET 是跨平台的。可以在 Windows、macOS 和大多数 Linux 版本上构建和运行应用程序。

.NET 具有高性能，并且与 Node.js 和其他竞争平台相比得分很高。有趣的是，[TechEmpower](https://www.techempower.com/)对许多 Web 应用程序平台和框架进行了广泛的[性能基准测试。](https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext).NET 进入前 10 名 - 远高于 Node.js 和其他竞争平台。

[.NET](https://github.com/dotnet/core)由 Microsoft 和 GitHub 上的 .NET 社区维护。

### 微服务挑战

虽然分布式云原生微服务可以提供巨大的敏捷性和速度，但它们也带来了许多挑战：

#### *通信*

前端客户端应用程序将如何与后端核心微服务进行通信？你会允许直接通信吗？或者，您是否可以使用提供灵活性、控制和安全性的网关来抽象后端微服务？

后端核心微服务如何相互通信？您是否允许可以增加耦合并影响性能和敏捷性的直接 HTTP 调用？或者您是否可以考虑使用队列和主题技术来解耦消息传递？

[云原生通信模式](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/communication-patterns)一章介绍了通信。

#### *弹性*

微服务架构将您的系统从进程内网络通信转移到进程外网络通信。在分布式架构中，当服务 B 没有响应来自服务 A 的网络调用时会发生什么？或者，当服务 C 暂时不可用并且其他调用它的服务被阻止时会发生什么？

弹性在[云原生弹性](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/resiliency)章节中介绍。

#### *分布式数据*

通过设计，每个微服务都封装了自己的数据，通过其公共接口公开操作。如果是这样，您如何跨多个服务查询数据或实现事务？

分布式数据包含在[云原生数据模式](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/distributed-data)一章中。

#### *秘密*

您的微服务将如何安全地存储和管理机密和敏感配置数据？

详细介绍了机密[Cloud-native security](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/security)。

### 使用 Dapr 管理复杂性

[Dapr](https://dapr.io/)是一个分布式的开源应用程序运行时。通过可插入组件的架构，它极大地简化了分布式应用程序背后的**管道**。它提供了一种**动态粘合剂**，将您的应用程序与 Dapr 运行时中预构建的基础设施功能和组件绑定在一起。Figure 1-5 shows Dapr from 20,000 feet.

在图中的第一行，请注意 Dapr 如何为流行的开发平台提供[特定于语言的 SDK 。](https://docs.dapr.io/developing-applications/sdks/)Dapr v1 包括对 .NET、Go、Node.js、Python、PHP、Java 和 JavaScript 的支持。

虽然特定语言的 SDK 可以增强开发人员的体验，但 Dapr 与平台无关。在底层，Dapr 的编程模型通过标准的 HTTP/gRPC 通信协议公开功能。任何编程平台都可以通过其原生 HTTP 和 gRPC API 调用 Dapr。

图中心的蓝色框代表 Dapr 构建块。每个都为您的应用程序可以使用的分布式应用程序功能公开预构建的管道代码。

组件行表示您的应用程序可以使用的大量预定义基础结构组件。将组件视为您不必编写的基础结构代码。

最后一行突出显示了 Dapr 的可移植性和它可以运行的不同环境。

[Microsoft为 .NET 开发人员](https://learn.microsoft.com/en-us/dotnet/architecture/dapr-for-net-developers/)提供了一本免费电子书Dapr，用于学习 Dapr。

展望未来，Dapr 有可能对云原生应用程序开发产生深远影响。

## 容器

在任何云原生对话中听到**容器**这个术语是很自然的。在[Cloud Native Patterns](https://www.manning.com/books/cloud-native-patterns)一书中，作者 Cornelia Davis 指出，“容器是云原生软件的重要推动力”。 [Cloud Native Computing Foundation 将微服务容器化作为其Cloud-Native Trail Map](https://raw.githubusercontent.com/cncf/trailmap/master/CNCF_TrailMap_latest.png)的第一步- 指导企业开始其云原生之旅。

将微服务容器化简单明了。代码、它的依赖项和运行时被打包到一个称为[容器镜像](https://docs.docker.com/glossary/?term=image)的二进制文件中。图像存储在容器注册表中，容器注册表充当图像的存储库或库。注册表可以位于您的开发计算机、数据中心或公有云中。[Docker 本身通过Docker Hub](https://hub.docker.com/)维护一个公共注册表。Azure 云具有一个私有[容器注册表](https://azure.microsoft.com/services/container-registry/)，用于将容器映像存储在靠近将运行它们的云应用程序的位置。

当应用程序启动或扩展时，您将容器映像转换为正在运行的容器实例。[该实例在安装了容器运行时](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)引擎的任何计算机上运行。您可以根据需要拥有任意数量的容器化服务实例。

图 1-6 显示了三个不同的微服务，每个微服务都在自己的容器中，都在一台主机上运行。

<center>图 1-6 在容器主机上运行多个容器
</center>

请注意每个容器如何维护自己的一组依赖项和运行时，它们可能彼此不同。在这里，我们看到不同版本的产品微服务在同一台主机上运行。每个容器共享底层主机操作系统、内存和处理器的一部分，但彼此隔离。

请注意容器模型如何很好地遵循[十二因素应用程序中的](https://12factor.net/)**依赖关系**原则。

> *因素 #2 指定“每个微服务隔离并打包自己的依赖项，在不影响整个系统的情况下接受更改。”*

容器支持 Linux 和 Windows 工作负载。Azure 云公开拥抱两者。有趣的是，是 Linux 而不是 Windows Server 成为了 Azure 中更受欢迎的操作系统。

虽然存在多家容器供应商，但[Docker](https://www.docker.com/)占据了最大的市场份额。该公司一直在推动软件容器运动。它已经成为打包、部署和运行云原生应用程序的事实标准。

### 为什么是容器？

容器提供可移植性并保证跨环境的一致性。通过将所有内容封装到一个包中，您可以*将*微服务及其依赖项与底层基础设施隔离开来。

您可以在托管 Docker 运行时引擎的任何环境中部署容器。容器化工作负载还消除了使用框架、软件库和运行时引擎预配置每个环境的费用。

通过共享底层操作系统和主机资源，容器的占用空间比完整的虚拟机小得多。较小的尺寸会增加给定主机一次可以运行的*密度或微服务数量。*

### 容器编排

虽然 Docker 等工具可以创建映像并运行容器，但您还需要工具来管理它们。容器管理是通过称为**容器编排器**的特殊软件程序完成的。当使用许多独立运行的容器进行大规模操作时，编排是必不可少的。

图 1-7 显示了容器编排器自动化的管理任务。

<center>图 1-7 容器编排器做什么
</center>

下表描述了常见的编排任务。

请注意容器编排器如何接受[十二因素应用程序中的可](https://12factor.net/)**处置**性和**并发**性原则。

> *因素 #9 指定“服务实例应该是一次性的，有利于快速启动以增加可扩展性机会和优雅关闭以使系统处于正确状态。”* Docker 容器和编排器本质上满足了这一要求。”

> *因素 #8 指定“服务扩展到大量相同的小进程（副本），而不是在可用的最强大的机器上扩展单个大型实例。”*

虽然存在多个容器编排器，[但 Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)已成为云原生世界的事实标准。它是一个可移植、可扩展的开源平台，用于管理容器化工作负载。

您可以托管自己的 Kubernetes 实例，但随后您将负责配置和管理其资源——这可能很复杂。Azure 云将 Kubernetes 作为一项托管服务。Azure Kubernetes [服务 (AKS)](https://azure.microsoft.com/services/kubernetes-service/)和[Azure Red Hat OpenShift (ARO)](https://azure.microsoft.com/services/openshift/)使您能够充分利用 Kubernetes 作为托管服务的功能和强大功能，而无需安装和维护它。

[扩展云原生应用程序](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/scale-applications)中详细介绍了容器编排。

## 支持服务

云原生系统依赖于许多不同的辅助资源，例如数据存储、消息代理、监控和身份服务。这些服务称为[支持服务](https://12factor.net/backing-services)。

图 1-8 显示了云原生系统使用的许多常见支持服务。

<center>图 1-8 常见的支持服务
</center>

您可以托管自己的支持服务，但随后您将负责许可、供应和管理这些资源。

云提供商提供种类丰富的*托管支持服务。*您无需拥有该服务，而只需使用它即可。云提供商大规模运营资源，并负责性能、安全和维护。监视、冗余和可用性内置于该服务中。供应商保证服务水平性能并完全支持他们的托管服务——打开一张票，他们会解决你的问题。

云原生系统青睐来自云供应商的托管支持服务。节省的时间和劳动力可能是巨大的。自行托管和遇到麻烦的运营风险可能会很快变得昂贵。

最佳实践是将支持服务视为**附加资源**，动态绑定到具有存储在外部配置中的配置信息（URL 和凭据）的微服务。该指南在本章前面讨论的[十二因素应用中有详细说明。](https://12factor.net/)

> *因素 #4*指定支持服务“应该通过可寻址的 URL 公开。这样做可以将资源与应用程序分离，使其可以互换。”

> *因素 #3*指定“配置信息被移出微服务并通过代码外部的配置管理工具外部化”。

使用此模式，无需更改代码即可附加和分离支持服务。您可以将微服务从 QA 提升到暂存环境。您更新微服务配置以指向暂存中的支持服务，并通过环境变量将设置注入容器。

云供应商提供 API 供您与他们专有的支持服务进行通信。这些库封装了专有管道和复杂性。但是，直接与这些 API 通信会将您的代码与特定的支持服务紧密耦合。隔离供应商 API 的实现细节是一种广泛接受的做法。引入一个中间层或中间 API，将通用操作公开给您的服务代码，并将供应商代码包装在其中。这种松散耦合使您能够将一种支持服务换成另一种支持服务，或者将您的代码移动到不同的云环境，而无需更改主线服务代码。前面讨论过的 Dapr 遵循这个模型及其一组[预构建的构建块](https://docs.dapr.io/developing-applications/building-blocks/)。

最后一点，支持服务还促进了本章前面讨论的[十二因素应用程序中的](https://12factor.net/)**无状态**原则。

> *因素 #6*规定，“每个微服务都应该在自己的进程中执行，与其他正在运行的服务隔离。将所需状态外部化到支持服务，例如分布式缓存或数据存储。”

[云原生数据模式](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/distributed-data)和[云原生通信模式](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/communication-patterns)中讨论了支持服务。

## 自动化

如您所见，云原生系统采用微服务、容器和现代系统设计来实现速度和敏捷性。但是，这只是故事的一部分。您如何配置运行这些系统的云环境？您如何快速部署应用程序功能和更新？你如何完善整个画面？

输入广泛接受的[基础架构即代码](https://learn.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code)或 IaC 实践。

借助 IaC，您可以自动化平台配置和应用程序部署。您实质上是将软件工程实践（例如测试和版本控制）应用到您的 DevOps 实践中。您的基础设施和部署是自动化的、一致的和可重复的。

### 自动化基础设施

[Azure Resource Manager](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/overview)、[Azure](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview) Bicep 、 HashiCorp 的[Terraform](https://www.terraform.io/)和[Azure CLI](https://learn.microsoft.com/en-us/cli/azure/)等工具使您能够以声明方式编写所需的云基础架构脚本。资源名称、位置、容量和秘密是参数化的和动态的。该脚本作为项目的工件进行版本控制并签入源代码管理。您调用脚本来跨系统环境（例如 QA、暂存和生产）提供一致且可重复的基础设施。

在幕后，IaC 是幂等的，这意味着您可以一遍又一遍地运行相同的脚本而不会产生副作用。如果团队需要进行更改，他们会编辑并重新运行脚本。只有更新的资源会受到影响。

在文章“[什么是基础设施即代码”](https://learn.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code)中，作者 Sam Guckenheimer 描述了“实施 IaC 的团队如何快速、大规模地交付稳定的环境。他们避免了环境的手动配置，并通过代码表示其环境的所需状态来加强一致性。使用 IaC 的基础设施部署是可重复的，并且可以防止因配置漂移或缺少依赖项而导致的运行时问题。DevOps 团队可以使用一组统一的实践和工具进行合作，以快速、可靠和大规模地交付应用程序及其支持的基础设施。”

### 自动化部署

前面讨论的[十二因素应用程序](https://12factor.net/)在将完成的代码转换为正在运行的应用程序时需要单独的步骤。

> *因素 #5*指定“每个版本都必须严格区分构建、发布和运行阶段。每个版本都应标记有唯一 ID 并支持回滚功能。”

现代 CI/CD 系统有助于实现这一原则。它们提供单独的构建和交付步骤，以帮助确保一致且高质量的代码可供用户随时使用。

图 1-9 显示了部署过程中的分离。

<center>图 1-9 CI/CD 管道中的部署步骤
</center>

上图中，特别注意任务分离：

1、 开发人员在他们的开发环境中构建一个功能，迭代所谓的代码、运行和调试的“内部循环”。
2、 完成后，该代码将*被推*送到代码存储库中，例如 GitHub、Azure DevOps 或 BitBucket。
3、 推送会触发将代码转换为二进制工件的构建阶段。这项工作是通过[持续集成 (CI)](https://martinfowler.com/articles/continuousIntegration.html)管道实施的。它会自动构建、测试和打包应用程序。
4、 发布阶段获取二进制工件，应用外部应用程序和环境配置信息，并生成不可变版本。发布被部署到指定的环境。这项工作是通过[持续交付 (CD)](https://martinfowler.com/bliki/ContinuousDelivery.html)管道实施的。每个版本都应该是可识别的。您可以说，“此部署正在运行应用程序的 2.1.1 版”。
5、 最后，发布的特征在目标执行环境中运行。版本是不可变的，这意味着任何更改都必须创建一个新版本。

应用这些实践，组织已经从根本上改进了他们发布软件的方式。许多已经从季度发布转变为按需更新。目标是在开发周期的早期发现问题，当它们修复起来成本较低时。集成之间的持续时间越长，解决问题的成本就越高。通过集成过程的一致性，团队可以更频繁地提交代码更改，从而实现更好的协作和软件质量。

DevOps 中详细讨论了基础设施即代码和部署自动化，以及 GitHub 和 Azure [DevOps](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/devops)

> 链接：https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/definition

> <span style="font-style: italic;">声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。</span>