使用微服务架构的多云策略

按照这份在 Azure、AWS 和 Google Cloud 中构建微服务的完整指南，构建高度可用、可扩展和高性能的应用程序。

2005 年，Peter Rodgers 博士在 Web 服务边缘会议的演讲中谈到了微 Web 服务，第一代微 Web 服务基于面向服务的架构(SOA)。SOA 是作为任务执行的“自包含”软件模块，这允许服务基于 SOAP（简单对象访问协议）进行通信。SOAP 的主要思想是“尽可能做最简单的事情”。

微服务和多云环境

在我们进入微服务架构、模式以及如何构建支持多云部署的基于微服务的应用程序之前，让我们定义术语。微服务是一种架构模式，它允许应用程序由松散耦合的模块组成。但是，微服务设计应遵循以下规则：

多云（即混合云）意味着通过多个云提供商传播应用程序有两种不同的方法。例如，我们可以在 AWS 中构建核心应用程序，还有一些部分可以部署到 Azure 和 Google Cloud。另一个多云示例是为一个云设计的应用程序可以通过微小的更改迁移到另一个云。

微服务与单体应用

在我们进入示例之前，让我们看一下微服务和单体架构的优缺点的简要列表：

表 1：微服务

当我开始设计解决方案时，我总是以单体架构为起点。使用这种方法，我们可以实现以下目标：

表 2：整体式

在图 1 中，您可以看到一个典型的旅行系统模块化单体架构示例。它允许乘客找到司机、预订并加入旅行。

图 1：旅行预订应用程序

该系统由几个模块组成：

这种单体架构可以迁移到微服务架构。每个服务都可以独立运行，并且可以将状态保存在自己的数据库中。

上面解释的解决方案非常简单，可以毫无问题地转化为微服务。然而，在企业层面，这种迁移要复杂得多，就像在 Netflix 等大公司中看到的那样。

用于构建微服务架构的云组件和服务

在本节中，我们将介绍一些可用于构建微服务架构的云服务，以便我们知道在微服务架构设计和实施过程中选择什么服务或云组件。

Container Engine

容器引擎对于构建微服务至关重要，因为它们允许在各种云提供商中分离、编排和管理微服务。Docker是一种广泛使用的容器引擎，它允许将每个微服务包装到一个容器中，并将其放入基于云的容器编排系统中，如 Kubernetes（AKS、EKS）或直接启动应用程序。Containerd与 Docker 相同，但具有轻量级且更安全的架构。

Orchestrator

Kubernetes是一种流行的开源系统，用于编排、自动化部署和扩展容器应用程序。它包含并自动化部署。Azure、AWS和Google Cloud拥有自己的托管编排服务，其中已经包括负载平衡、自动缩放、工作负载管理、监控和服务 格。

Azure Service Fabric是一个用于编排微服务的分布式平台。几年来，主要目标是为基于 .NET Core/Framework 和 Windows 的微服务提供最佳支持；我们可以在选择服务流程图中看到它。微软声称 Service Fabric 也支持其他语言和平台，如 Linux。

Message Bus

队列是一种基于 FIFO（先进先出）原则的服务。所有消息总线系统都基于此服务。例如，Azure 具有包含简单业务逻辑的队列存储。如果你有一个简单的架构需要集中消息存储，你可以依赖队列。AWS 和 Google Cloud 也分别拥有Simple Queue Service和GC Pub/Sub。这些允许您在微服务和软件组件之间发送、存储和接收消息。

服务总线/消息总线基于与队列相同的方法。但是，消息总线在顶部有更多功能——它包含死信队列、预定传递、消息延迟、事务、重复检测和许多其他功能。例如，Azure Service Bus和AWS Managed Kafka 服务是高度可用的消息代理，适用于可以处理数千条消息的企业级应用程序。

Serverless

无服务器允许我们纯粹使用事件驱动的方法来构建微服务架构。它是一个可按需提供的单一云服务单元，旨在专注于直接在云中构建微服务，而无需考虑您应该使用什么容器引擎、编排器或云服务。AWS 和 Azure 分别有Lambda和Azure Functions。Google Cloud Functions遵循相同的原则。

Essential Microservices Design Patterns

现在我们了解了微服务架构，可以开始使用微服务开发应用程序了。我们还了解使用微服务的好处以及如何重构应用程序以支持此架构。开始构建应用程序的最佳点是了解微服务设计模式。

Domain Microservices

微服务领域模型（领域驱动设计的一部分）不仅仅是一种模式——它是一组设计和范围微服务的原则。应使用以下规则设计微服务域：

Anti-Corruption Layer

遗留系统可能有不可维护的代码和整体糟糕的设计，但我们仍然依赖来自该模块的数据，Anti-Corruption Layer在新的微服务架构和遗留架构之间提供了立面或桥梁。因此，它使我们能够远离操纵遗留代码并专注于功能开发。

图 2：反腐败层

Circuit Breaker

circuit breaker提供了阻止级联故障并自动恢复到正常状态的机制。想象一下，我们有服务 A 和服务 B，它们依赖于来自服务 C 的数据。我们在服务 C 中引入了一个影响服务 A 和 B 的错误。在设计良好的微服务架构中，每个服务应该相互独立。

但是，在从单体架构重构为微服务的过程中可能会出现依赖关系。在这种情况下，您需要实现一个断路器来预测级联故障。断路器充当状态机。他们监控最近的许多故障并决定下一步做什么。它们可以允许操作（关闭状态）或返回异常（打开或半打开状态）。

图 3：断路器状态

Service Mesh

服务 格实现了微服务架构的通信层。它确保服务请求的传递，提供负载平衡，加密数据（使用 TLS），并提供其他服务的发现。服务 格还：

它不仅允许您管理服务，还可以收集遥测数据并将其发送到控制平面。我们实现了一个服务 格，例如Istio，它是 Kubernetes 中用于管理微服务的最流行的服务 格框架。

图 4：服务 格算法

sidecar

Sidecar 是与主要服务一起部署的实用程序应用程序。Sidecar 有助于：

图 5：边车

Microservices in Action

为了展示微服务的强大功能，我们将把我们的整体旅行应用程序（参见图 1）迁移到微服务架构中。

我们将使用无服务器方法和 Azure 云。

图 6：旅行预订微服务

结论

构建高度可用、可扩展和高性能的应用程序可能具有挑战性。微服务架构为我们提供了不仅可以构建独立服务的选项，还可以创建多个团队来支持每个服务并引入 DevOps 方法。微服务和所有流行的云提供商允许我们构建多云微服务架构。这可以节省资金，因为某些服务具有不同的定价策略。但请务必选择最适合特定微服务领域的服务。例如，我们可以将AKS 与集成服务 格或基于AWS Lambdas的无服务器方法一起使用。多云允许我们应用云原生 DevOps 来独立交付服务。