微服务架构

微服务架构设计与实践

原创于 2025-12-11 08:55:45 发布 · 991 阅读

17 ·

CC 4.0 BY-SA版权

文章标签：

#架构 #微服务

本文将介绍微服务架构。当然，我们会从定义、优势和挑战入手。之后，我们将设计一个适用于电子商务领域的微服务架构。

读完本文，您将学会何时何地应用微服务架构，以及如何利用微服务架构设计具有高可用性、高可扩展性和低延迟的系统。

在本文中，我们将学习如何运用设计模式、原则和最佳实践来设计微服务架构。我们将从单体架构逐步过渡到事件驱动型微服务架构，并共同运用正确的架构设计模式和技术。

如果您喜欢此文章，请收藏、点赞、评论，谢谢，祝您快乐每一天。

什么是微服务？

微服务是能够协同工作并独立部署的小型企业服务。这些服务通过网络相互通信，并带来诸多优势。其中最大的优势之一是它们可以独立部署。此外，这也为与多种不同技术合作提供了可能。

微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个服务都在自己的进程中运行，并通过轻量级机制（通常是 HTTP 或 gRPC API）进行通信。

这些服务围绕业务能力构建，可通过全自动部署流程独立部署。这些服务几乎无需集中管理，它们可能使用不同的编程语言编写，并采用不同的数据存储技术。

因此我们可以说，微服务架构是一种云原生架构 方法，其中应用程序由许多松散耦合且可独立部署的较小组件组成。

微服务；

拥有自己的技术栈，包括数据库和数据管理模型；
通过REST API、事件流和消息代理的组合进行相互通信；
按业务能力组织，分隔服务的界限通常被称为有界上下文。

微服务特性

微服务架构规模小、相互独立且松耦合。一个小型开发团队即可编写和维护一个服务。每个服务都是一个独立的代码库，可以由一个小型开发团队进行管理。

服务可以独立部署。团队无需重建和重新部署整个应用程序即可更新现有服务。服务负责持久化自身的数据或外部状态。这与传统模型不同，传统模型中数据持久化由单独的数据层处理。

服务之间通过定义完善的 API进行通信。每个服务的内部实现细节对其他服务是隐藏的。服务无需共享相同的技术栈、库或框架。

在本文中，我们将参考这些微服务 特性来开发我们的参考应用程序。

再次参考 Martin Fowler 的文章，微服务架构有一些共同的特征符合这一标签。Martin
Fowler在以下标题中解释了这些特征；

通过服务组件化
，组件是可独立替换和升级的软件单元。

以业务能力为中心进行组织
微服务划分方法是将服务拆分成按业务能力组织的各个部分。

产品而非项目
这是亚马逊“你构建，你运行”的理念，即开发团队对生产环境中的软件负全部责任。

智能端点和哑管道
微服务旨在尽可能地解耦和内聚，因此它们拥有自己的领域逻辑，并通过 RESTful API 接收请求、应用逻辑并产生响应。

去中心化治理：
Netflix 就是一个遵循这种理念的优秀案例。将有用且经过全面测试的代码以库的形式共享，鼓励其他开发者以类似的方式解决类似的问题。

去中心化数据管理
微服务也实现了数据存储决策的去中心化。我们可以将这种方法称为多语言持久化或多语言数据库。这意味着微服务倾向于让每个服务管理自己的数据库，可以是同一数据库技术的不同实例，也可以是完全不同的数据库系统。

基础设施自动化
意味着对每个新环境和每个微服务分别进行自动化部署。

微服务设计应考虑故障
，通过处理故障并尝试通过适当的措施来管理错误，从而实现故障管理。

因此，这些特性给我们带来了一些关键好处；

代码更新更加便捷——无需修改整个应用程序即可添加新功能或特性。
团队可以为不同的组件使用不同的技术栈和不同的编程语言。
各项服务可以独立扩展，从而减少了因单个功能负载过大而导致整个应用程序扩展所造成的浪费和成本。

因此我们可以说：每项服务都是：

高度可维护和可测试——支持快速频繁的开发和部署
与其他服务松散耦合——使团队能够在大部分时间里独立开发其服务，而不会受到切换到其他服务的影响，也不会影响其他服务。
可独立部署——使团队能够独立部署其服务，而无需与其他团队协调。
能够由小型团队开发——这对于提高生产力至关重要，因为它避免了大型团队中高层领导繁重的沟通工作。

综上所述；

服务之间可以使用同步协议（例如HTTP/REST）或异步协议（例如AMQP）进行通信。服务可以彼此独立地开发和部署。每个服务都有自己的数据库，以便与其他服务解耦。

微服务架构的优势

我们将探讨微服务架构的优势和益处。让我们逐一阐述这些优势。

敏捷

微服务最重要的特性之一是，由于服务规模更小且可独立部署，因此更容易管理错误修复和功能发布。您可以更新某个服务而无需重新部署整个应用程序，并且在出现问题时可以回滚更新。在单体应用程序中，如果应用程序的某个部分发现错误，则可能会阻塞整个发布流程。因此，新功能需要等待错误修复后才能集成、测试和发布。

小型、专注的团队

微服务应该足够小，以便单个功能团队能够独立完成构建、测试和部署。微服务模型使组织能够围绕一项或多项服务创建小型跨职能团队，并以敏捷的方式运作。小团队规模可以提高敏捷性。大型团队往往效率较低，因为沟通速度较慢，管理成本增加，从而导致敏捷性下降。

小型且独立的代码库

在单体应用中，随着时间的推移，代码库会变得非常庞大，代码依赖关系也会变得错综复杂。尝试添加新功能需要对现有代码库进行大量重构。由于微服务不与其他服务共享代码或数据存储，因此可以最大限度地减少依赖关系，从而更容易添加新功能。

合适的工具才能胜任工作

在传统的分层架构中，应用程序通常共享一个公共技术栈，并由一个大型关系数据库来支持整个应用程序。这种方法存在诸多挑战，例如，应用程序的每个组件都必须共享公共技术栈、数据模型和数据库，即使某些模块有更合适的工具。这会让开发人员感到非常沮丧，因为他们知道有更好、更高效的方式来构建这些组件。此外，当应用程序技术栈过于老旧，无法在项目中应用新的最佳实践时，开发人员也会感到沮丧。

但在微服务架构中，小型团队可以选择最适合其微服务的技术，并在服务中使用多种技术栈的组合。由于微服务是独立部署的，并且通过REST、事件流和消息代理等多种方式进行通信，因此每个服务的技术栈都可以针对该服务进行优化。

技术日新月异，开发库和工具也在快速发展，因此，对于由多个较小服务组成的应用程序来说，采用更理想的技术向微服务演进要容易得多，成本也低得多。

误隔离

微服务架构的松耦合特性也有助于实现故障隔离，并增强应用程序的弹性。即使某个微服务出现故障，也不会影响整个应用程序。当然，您应该在设计微服务时就考虑容错性，并正确处理故障，例如通过实现重试和熔断机制。即使发生故障，只要在不影响业务的情况下修复故障，您的客户始终会感到满意。

可扩展性

微服务可以独立扩展，因此您可以只扩展资源需求较低的子服务，而无需扩展整个应用程序。所以我们可以说，微服务比单体应用程序需要更少的资源，因为它们能够精确地扩展所需的服务，
而不是扩展整个应用程序。

此外，使用 Kubernetes 等容器编排工具可以轻松实现扩展，您可以将更多数量的服务打包到单个主机上，从而更有效地利用硬件资源。

数据隔离

由于微服务遵循每个服务一个数据库的模式，数据库根据微服务设计彼此分离。因此，执行模式更新变得更加容易，因为只会影响单个数据库。在单体应用中，模式更新可能变得非常具有挑战性，而且风险很高。

正如你所看到的，我们已经了解了微服务的诸多优点，现在是时候来看看微服务架构面临的挑战了。

微服务架构的挑战

微服务架构优势显著，但也面临诸多挑战。从单体架构迁移到微服务架构意味着管理复杂性的大幅提升。以下是我们应用微服务架构之前需要考虑的一些挑战。

复杂

微服务应用包含许多需要协同工作并创造价值的服务。由于服务众多，这意味着其组件数量比单体应用更多。虽然每个服务本身更简单，但整个系统却更加复杂。即使是部署也可能非常复杂，因为数百个服务需要在不同时间部署，版本管理也十分困难。再想想通信问题。单体应用中组件间的通信非常容易，因为它是进程间通信，可以在同一台机器的同一个进程内进行。但微服务间的通信却是一个棘手的问题，需要制定策略来管理服务器之间（即使是位于不同地理位置的服务器）的服务间通信。

网络问题和延迟

由于微服务规模较小且需要进行服务间通信，因此我们需要妥善处理网络问题。如果为了特定请求而调用一系列服务，就会造成延迟问题，因此需要对 API 进行合理设计以确保通信顺畅。为了避免频繁的 API 调用，需要考虑异步通信模式，例如消息代理系统。

开发与测试

考虑一下端到端流程，这是一项长期的业务需求。如果该需求涉及多个需要作为一个整体应用程序运行的微服务，那么与单体架构相比，在微服务架构中开发和测试这些端到端流程会更加困难。现有工具并非总是针对服务依赖关系而设计的。跨服务边界的重构也可能非常棘手。

数据完整性

微服务有自己的数据持久化机制，因此数据一致性可能是一个挑战。大多数情况下，我们应该尽可能遵循最终一致性原则。但事务操作始终会面临挑战。

然而，这些挑战并未阻止微服务架构的普及。大多数组织都接受这些挑战，并调整其技术以适应微服务架构，从而获得这种架构带来的优势。

微服务架构的参考架构

我们将看到微服务架构的参考架构示例。我们将遵循这些参考架构，创建我们自己的电子商务架构。让我们开始吧。

参考微服务架构 1

首先，我们从简单的开始。

如图所示，该图像包含多个微服务和一个 API 网关，用于将微服务与客户端应用程序进行通信。

参考微服务架构 2

请查看微服务架构的不同图示。

这是微服务架构的常见视图。它包含多个微服务、API网关和用于微服务间通信的消息代理。

参考微服务架构 3

请查看微服务架构的不同图示。

您还可以看到另一个参考架构。这也是我们将逐步演进的电子商务参考架构之一。

参考微服务架构 4

请查看微服务架构的不同图示。

最后，我们可以看到一些先进的微服务架构。可以看到多个用于不同客户端应用程序的API 网关，以及通过事件总线系统实现的多个微服务之间的通信。我们将逐步了解为什么在构建微服务架构时要使用这些组件。

设计微服务架构——电子商务应用

我们将逐步设计微服务架构。根据需求，逐一迭代架构设计。我们有一个需求，需要保存订单、查看购物车等等。因此，我们需要在这个架构中设计数据库。

如您所见，我们采用了“每个微服务一个数据库”的策略，为电子商务应用中的每个微服务都配备了数据库。因此，这些数据库可以支持多种持久化方式。
这意味着产品微服务可以使用 NoSQL 文档型数据库，购物车微服务可以使用 NoSQL 键值对数据库，而订单微服务可以根据微软的数据存储要求使用关系型数据库。

如您所见，我们将电子商务应用程序设计为微服务架构，并处理可扩展性、可靠性等功能需求和非功能需求。