云原生应用讲解系列二

继续上一篇云原生应用讲解系列一

微服务

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

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

• 每个都在更大的域上下文中实现特定的业务功能。
• 每个都是自主开发的，可以独立部署。
• 每个都是独立的，封装了自己的数据存储技术（SQL、NoSQL）和编程平台。
• 每个进程在自己的进程中运行，并使用标准通信协议（如HTTP/HTTPS、WebSockets或AMQP）与其他进程通信。
• 它们组合在一起形成一个应用程序。

下图对比了单片应用程序方法和微服务方法。请注意，monolith是如何由一个分层体系结构组成的，它在单个进程中执行。它通常使用关系数据库。然而，微服务方法将功能分离为包含逻辑和数据的独立服务。每个微服务都有自己的数据存储。

请注意微服务是如何从上一篇讨论的十二要素应用程序中推广“一个代码库，一个应用程序”原则的。

要素1指定“每个微服务的单个代码库，存储在其自己的存储库中。通过版本控制进行跟踪，它可以部署到多个环境。”

为什么选择微服务？

微服务提供了灵活性。

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

• 每个微服务都有一个自主的生命周期，可以独立发展并频繁部署。您不必等待每季度发布一次就可以部署新功能或更新。您可以更新复杂应用程序的一小部分，而中断整个系统的风险较小。
• 每个微服务都可以独立扩展。您没有将整个应用程序作为一个单元进行扩展，而是只扩展那些需要更多处理能力或网络带宽的服务。这种细粒度的扩展方法提供了对系统的更好的控制，并有助于在扩展系统的部分（而不是全部）时降低总体成本。

开发微服务

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

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

.NET的性能很高，与之相比，它的得分也很高节点.js以及其他竞争平台。有趣的是，TechEmpower跨许多web应用程序平台和框架进行了一系列广泛的性能基准测试。

.NET由Microsoft和GitHub上的.NET社区维护。

容器

现在，在任何关于云原生的对话中，都很自然地会听到容器这个词。在《云原生模式》（Cloud Native Patterns）一书中，作者Cornelia Davis指出，“容器是云原生软件的巨大推动者。”云原生计算基金会将微服务容器化作为其云原生路线图的第一步，为企业开始云原生之旅提供指导。

将微服务封装起来是简单而直接的。代码、它的依赖项和运行时被打包成一个称为容器映像的二进制文件。图像存储在容器注册表中，它充当图像的存储库或库。注册表可以位于开发计算机、数据中心或公共云中。Docker本身通过Docker Hub维护公共注册表。azure cloud提供了一个容器注册中心，用于在运行容器映像的云应用程序附近存储容器映像。

需要时，可以将图像转换为正在运行的容器实例。该实例在安装了容器运行时引擎的任何计算机上运行。您可以根据需要拥有任意多个容器化服务实例。

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

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

请注意容器模型如何很好地包含来自十二因素应用程序的“依赖性”原则。

要素2指定“每个微服务隔离并打包自己的依赖项，接受更改而不影响整个系统。”

容器支持Linux和Windows工作负载。蔚蓝的云公开地拥抱着这两者。有趣的是，是Linux，而不是Windows服务器，已经成为Azure中最流行的操作系统。

虽然存在多家集装箱供应商，但Docker占据了市场的绝大部分份额。该公司一直在推动软件容器运动。它已经成为打包、部署和运行云本地应用程序的事实标准。

为什么是Docker？

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

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

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

容器编排

在Docker等工具创建图像和运行容器的同时，还需要工具来管理它们。容器管理是通过一个称为容器编排器的特殊软件程序来完成的。在大规模操作时，容器编排是必不可少的。

下图显示了容器编排器提供的管理任务。

下表介绍了常见业务流程任务。

请注意，编排器是如何接受上一篇中讨论的十二要素应用程序中的可处置性和并发性原则的。

要素9规定“服务实例应该是一次性的，有利于快速启动以增加可伸缩性机会，并有利于正常关闭以使系统处于正确状态。Docker容器和orchestrator本身就满足了这一要求。”

要素8指定“服务跨大量相同的小进程（副本）扩展，而不是在功能最强大的计算机上扩展单个大型实例。”

尽管存在多个容器编排器，但Kubernetes已经成为云原生世界的事实标准。它是一个可移植、可扩展、开源的平台，用于管理容器化工作负载。

您可以托管自己的Kubernetes实例，但接下来您将负责提供和管理它的资源—这可能很复杂。Azure云将Kubernetes作为托管服务，即Azure Kubernetes服务（AKS）。托管服务允许您充分利用其功能，而无需安装和维护它。

后台服务

云原生系统依赖于许多不同的辅助资源，如数据存储、消息代理、监视和身份服务。这些服务称为支持服务。

下图显示了云原生系统使用的许多常见备份服务。

支持服务从上一篇中讨论的十二要素应用程序中促进了“无状态”原则。

要素6规定，“每个微服务应该在自己的进程中执行，与其他运行的服务隔离开来。将所需状态外部化到备份服务（如分布式缓存或数据存储）

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

云提供商提供了各种各样的托管支持服务。您不需要拥有服务，而只需要使用它。供应商按规模运营资源，并承担性能、安全和维护责任。监视、冗余和可用性都内置在服务中。提供商完全支持他们的托管服务—打开一张票据，他们就可以解决您的问题。

云原生系统支持云供应商提供的托管备份服务。节省了大量的时间和劳力。托管自己的主机并遇到问题的操作风险可能会很快变得昂贵。

最佳做法是将支持服务视为附加资源，动态绑定到微服务，并将信息（URL和凭据）存储在外部配置中。本章前面讨论的12因素应用程序详细说明了此指南。

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

要素#3指定“配置信息从微服务中移出，并通过代码外部的配置管理工具进行外部化。”

使用此模式，可以在不更改代码的情况下附加和分离备份服务。您可以将微服务从QA提升到暂存环境。您可以更新microservice配置以指向暂存中的备份服务，并通过环境变量将设置注入到容器中。

云供应商为您提供API，以便您与他们的专有支持服务进行通信。这些库封装了管道和复杂性。直接与这些api通信将使您的代码与支持服务紧密耦合。更好的做法是隔离供应商API的实现细节。引入中介层或中介API，将通用操作公开给服务代码。这种松散耦合使您能够将一个备份服务换成另一个备份服务，或者将代码移动到不同的公共云，而无需更改主线服务代码。

自动化

如您所见，云原生系统采用微服务、容器和现代系统设计来实现速度和灵活性。但是，这只是故事的一部分。如何配置这些系统运行的云环境？如何快速部署应用程序功能和更新？你怎样把全貌画出来？

以代码或IaC的形式输入广泛接受的基础设施实践。

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

自动化基础设施

诸如Azure资源管理器、Terraform和Azure CLI之类的工具使您能够声明性地编写所需的云基础设施脚本。资源名称、位置、容量和机密是参数化的和动态的。脚本被版本控制并作为项目的工件签入源代码管理。您可以调用脚本来跨系统环境（如QA、staging和production）提供一致且可重复的基础结构。

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

实现IaC的团队如何快速、大规模地提供稳定的环境。团队避免手动配置环境，并通过代码表示所需的环境状态来实现一致性。使用IaC的基础设施部署是可重复的，可以防止由配置漂移或缺少依赖项引起的运行时问题。DevOps团队可以与一组统一的实践和工具协同工作，以快速、可靠和大规模地交付应用程序及其支持基础设施。

自动化部署

上一篇中讨论的12因素应用程序在将已完成的代码转换为正在运行的应用程序时需要单独的步骤。

要素5规定“每个发行版必须在构建、发行和运行阶段之间实施严格的分离。每一个都应标记一个唯一的ID，并支持回滚功能。”

现代CI/CD系统有助于实现这一原则。它们提供了单独的部署步骤，并有助于确保用户可以随时获得一致且高质量的代码。

下图显示了整个部署过程的分离。

在上图中，请特别注意任务的分离。

开发人员在他们的开发环境中构造一个特性，遍历所谓的代码、运行和调试的“内部循环”。完成后，该代码将被推送到代码存储库中，如GitHub、azuredevops或BitBucket。

推送触发一个构建阶段，将代码转换为二进制工件。这项工作是通过持续集成（CI）管道实现的。它自动构建、测试和打包应用程序。

发布阶段提取二进制工件，应用外部应用程序和环境配置信息，并生成一个不可变的发布。版本已部署到指定的环境。这项工作是通过连续输送（CD）管道实施的。每个版本都应该是可识别的。

最后，发布的特性在目标执行环境中运行。发布是不可变的，这意味着任何更改都必须创建一个新的发布。

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

Azure管道

Azure云包括一个名为Azure Pipelines的新CI/CD服务，它是Azure DevOps产品的一部分，如下图所示。

Azure pipelines是一种云服务，它结合了持续集成（CI）和持续交付（CD）。您可以自动测试、生成代码，并将代码发送到任何目标。

您可以在YAML文件中的代码中定义管道，以及应用程序的其余代码。

• 管道使用您的代码进行版本控制，并遵循相同的分支结构。
• 您可以通过pull请求和分支构建策略中的代码检查来验证更改。
• 您使用的每个分支都可以通过修改azure来自定义生成azure-pipelines.yml文件。
• 管道文件已签入版本控制，如果有问题，可以进行调查。

Azure pipelines服务支持大多数Git提供者，可以为Linux、macOS或Windows平台上编写的应用程序生成部署管道。它包括Java、.NET、JavaScript、Python、PHP、GO、XCODE和C++的java支持。