- 微服务架构将应用程序分解成与业务领域相一致的小型、自治的服务。
- 每个微服务一个数据库、Saga、API 网关、CQRS 和 Clean Architecture 等模式可以实现数据、事务和通信的管理。
- 容器、Kubernetes、CI/CD、高级可观测性和零信任安全是微服务在生产环境中运行的关键技术支柱。
- 这种方法提供了敏捷性和可扩展性，但引入了复杂性，需要分布式系统方面的专业知识和强大的 DevOps 文化。
La 微服务架构 已成为事实上的标准 构建现代云应用：可扩展、高弹性且易于演进。这远非仅仅是拆分单体应用的“技巧”，它意味着我们在设计、开发、部署和运维软件的方式上将发生深刻变革。
在本文中，我们将以某种方式看到 对微服务架构的定义及其实现方式进行了深入而实用的解释。 去中心化架构它真正的优点和缺点是什么？哪些组件使它成为可能？它与 MVC 或 Clean Architecture 等模式有何关系？数据库和容器扮演什么角色？哪些设计和部署模式是防止该发明变成难以维护的混乱的关键？
微服务架构究竟是什么？
当我们谈到微服务时，我们指的是…… 一种开发方法，其中应用程序被分解为小型、自主和专门化的服务。每项服务都有明确的业务职责。这些服务通常通过轻量级 API（REST、gRPC、消息传递、事件）进行通信，独立部署，并且通常管理自己的数据存储。
微服务本质上是 一个可独立部署的软件组件，由一个小团队控制 它负责产品的整个生命周期：设计、开发、测试、部署、可观测性和维护。这种“产品而非项目”的理念是该模式的核心：服务并非交付后就被遗忘，而是需要精心培育并持续演进。
与传统的整体式建筑相比， 所有功能都共存于单个进程和单个数据库中微服务致力于解耦：每个服务都可以用不同的语言编写，使用自己的数据库技术，并按自己的节奏进行版本控制，而无需每次更改都带动整个系统。
这种模式与以下实践完美契合： DevOps、持续集成和持续交付因为它能够实现快速、频繁且低风险的部署周期。但作为回报，它也带来了网络、数据、可观测性和治理方面的新复杂性，这些复杂性必须得到有效管理。
微服务的关键特性
基于微服务的系统通常共享多个组件。 尽管每个组织实施这些特征的方式各不相同，但它们都具有一些共同特征。:
首先，应用程序组件的实现方式如下： 独立服务，作为独立的部署和替换单元服务之间不再使用内存中的库进行通信，而是使用 HTTP/REST 调用、gRPC 或消息传递，这虽然会引入延迟，但可以降低耦合度。
分解发生 围绕业务能力并非按技术层划分。每项服务都与一个限定的子域或上下文（例如，用户、目录、订单、支付）相对应，并集中所有必要的逻辑：API、域逻辑、数据访问和第三方集成。
人们采取了一种思维方式 “产品，而非项目”一个跨职能团队（后端、前端、QA、DevOps）负责微服务的整个生命周期。这有助于实现端到端的责任归属，加快交付速度，并避免部门间无休止的交接。
关于整合方式，其原则是 “巧妙的末端和简单的管道”业务逻辑位于服务中，而通信基础设施（HTTP、队列、事件代理）则尽可能保持精简，避免使用过于复杂的编排和重量级协议，并倾向于使用更轻量级的协议。 面向事件的编程.
另一个重要特征是 去中心化技术治理每个团队都可以根据自身需求选择最合适的语言、框架和数据库类型，只要他们遵守最低限度的通用标准（安全性、日志记录、可观测性、API 契约）。这种自由度允许他们根据具体情况优化性能、成本和生产力。
去中心化数据管理和基于微服务的数据库模式
迁移到这种方法时，最棘手的决定之一就是如何处理数据。最常见的模式是： 每个微服务的数据库每个服务都拥有并管理自己的数据库，该数据库可能与其他服务采用相同的技术，也可能采用完全不同的技术。
这种方法增强了自主性，因为 每次方案变更只会影响拥有该数据的服务。它减少了单个数据库服务器上的瓶颈，并促进了多语言持久化：一个服务可以使用 PostgreSQL，另一个服务可以使用 MongoDB，还有一个服务可以使用缓存。 Redis的 另一个是类似 Elasticsearch 的搜索引擎，用于复杂查询和文本分析。
例如，在电子商务网站中，我们可以拥有…… 用户服务将其关系数据存储在 PostgreSQL 中。一个使用 NoSQL 数据库对高度可变产品进行建模的目录服务，一个使用针对事务优化的关系数据库的订单服务，一个由 Redis 支持的用于临时数据的购物车服务，以及一个使用 Elasticsearch 进行复杂查询和文本分析的搜索服务。
权衡是 分布式交易 ACIDs在实践中已不再可行。通常的做法是，与其进行涉及多个表的大型事务，不如使用最终一致性、领域事件和 Saga 等模式来协调服务之间的更改，并接受在短时间内不同服务可能看到不同状态的情况。
要访问属于其他服务的数据，建议不要“深入”其数据库，而是使用以下方法： 诸如 API 组合之类的模式 （一项服务通过调用多个专有服务来组合数据）或 CQRS（分离读取和写入，并通过事件保持只读投影的更新）。
管弦乐编排与舞蹈编排及传奇模式
当一个业务流程经过多个服务时（例如， 客户注册、创建会员账户、发送欢迎礼包和电子邮件协调主要有两种方式：统筹安排和编排安排。
重点关注 编排有一个核心组件（编排器或“协调器”服务），它了解整个流程：它调用积分服务，然后调用邮政服务，再调用电子邮件服务，控制中间状态，并处理错误。这种架构更容易理解，但往往会集中过多逻辑，变成一个“中心化怪物”。
相比之下，采用的方法是 编舞该过程基于 服务发布和消费的事件客户服务发出“customer_created”事件；会员服务监听该事件并分配积分；邮政服务监听该事件并生成邮件；电子邮件服务发送欢迎邮件。每个服务在观察到特定事件时都知道该做什么，无需中央组件来控制流程。
老板 佐贺 它依靠这些理念来管理分布式事务。Saga 由跨不同服务的一系列本地操作组成，并在发生错误时，通过一系列补偿操作来撤销（或缓解）之前的更改。Saga 可以以编排的方式实现（一个组件控制整个流程），也可以以协同的方式实现（每个服务对事件做出响应并发布新事件）。
编排式设计更适合高度分布式、事件驱动的微服务架构，但是 这需要对业务流程进行非常好的可观察性和监控。 找出每个步骤中发生的情况，并检测出不一致或部分失败的情况。
容错和弹性模式
在分布式系统中，必须假设： 任何服务调用都可能失败、耗时过长或返回间歇性错误。忽视这一点会导致连锁故障和全球性中断。
为了最大限度地降低这些风险，我们应用了多种韧性模式，首先是 最大等待时间（超时） 在所有远程调用中，没有人希望线程无限期地阻塞以等待服务中断；当超时到期时，客户端可以选择重试、将操作排队稍后执行，或降低功能级别。
老板 断路器 它增加了一层额外的保护：如果客户端检测到对某个服务的调用失败率很高，它会“断开电路”，暂时停止尝试调用该服务，并立即返回失败或降级响应。经过一段时间后，它会允许一些测试调用（半开放状态），如果这些调用再次成功，则会再次断开电路。
设计也很常见 水密隔间为了控制损失，我们采用了逻辑和物理两方面的措施：例如，每个服务部署多个 Pod、使用多台机器，甚至部署多个区域，以防止局部故障导致整个系统崩溃。此外，我们还采用了速率限制或负载均衡队列等技术，以防止突发的流量高峰对关键服务造成严重影响。
这一切都基于 可重用的弹性模块 （例如，像 Resilience4j 这样的库与 Spring Cloud 等框架集成）允许您以集中一致的方式在所有服务中配置重试策略、请求限制、熔断器和错误处理。
微服务架构的典型组成部分
除了业务服务本身之外，成熟的微服务架构还包含许多 确保一切可靠运行的关键平台组件:
一方面是 容器编排器或平台 （通常是 Kubernetes）负责调度和运行容器、扩展副本、重启故障服务以及提供服务发现和内部负载均衡机制；建议对该基础设施采取以下措施： 容器安全.
建筑边缘出现了 API 网关它作为外部客户端的单一入口点：将请求路由到正确的微服务，强制执行身份验证和授权，添加或验证安全标头，控制配额，充当 TLS 代理，并且在许多情况下聚合响应。
采用异步通信。 即时通讯和流媒体平台 例如 Apache Kafka 或 Azure 服务总线，它们支持发布-订阅模式、作业队列、领域事件和高度可扩展的事件驱动架构。
La 可观测性 这是另一个关键组成部分：集中式日志、应用程序指标、分布式跟踪和实时监控使您能够了解拥有数十甚至数百个服务的系统中正在发生的事情。像 OpenTelemetry 这样的框架以及收集和分析管道（配备专用收集器）现在必不可少。
最后，该 集中式配置管理 和 安全模块 访问令牌、服务间的 mTLS 加密、基于角色的访问控制和密钥管理完善了整个体系。配置与代码分离，因此只需更改外部参数，即可将相同的组件部署到多个环境中。
微服务架构和设计模式
为了避免重复造轮子（以及陷入反模式），关键在于依靠…… 已被证明在分布式环境中行之有效的架构和设计模式:
该模式在建模阶段尤为突出。 按子域分解这与领域驱动设计（DDD）密切相关。其理念是明确定义子领域和上下文（例如用户、订单、计费、物流等），并根据这些边界分配微服务，避免服务过大或过小。
对于同步通信，采用以下模式。 远程过程调用可使用 REST、gRPC、GraphQL 或 WebSocket 实现。建议采用 API 优先的方法，首先使用正式的契约（REST 使用 OpenAPI，gRPC 使用 IDL，GraphQL 使用 schema）设计接口，然后再生成或调整代码。
当需要异步通信时，会使用这种模式。 这是基于生产者发送给代理的事件，多个消费者可以按照自己的节奏处理这些事件。使用 AsyncAPI 定义事件契约非常适合这种情况，类似于 OpenAPI 在 REST 世界中的使用方式。
在数据访问领域，除了每个微服务一个数据库之外，以下几种方式也越来越重要。 CQRS（命令查询职责分离）将写作模型（命令）与阅读模型（查询）分离，使用投影和事件来保持针对搜索优化的只读视图同步。
为了将微服务暴露给外部客户端，该模式 API网关 它集中了访问权限，而类似这样的变体则…… 前端后端（BFF） 它为每种类型的客户端（Web、移动、内部应用程序）创建特定的 API，根据每个界面的需求聚合和调整数据。
与 MVC、整洁架构和经典模式的关系
在许多项目中，故事都是从……开始的。 基于MVC的单体应用 （模型-视图-控制器）：处理请求的 Web 控制器、与单个数据库紧密耦合的领域模型以及在服务器上呈现的视图。
MVC 模式在每个公开 API 或 Web 界面的微服务中仍然非常有用（例如，使用框架时）。 Python 中的 Flask），但 它不再是整个应用程序的全局结构。目前的趋势是将前端（SPA、移动应用）解耦，并使用使用微服务 API 的现代框架，如果继续使用传统的 MVC，则将其作为内部细节。
La 清洁建筑 它与微服务特别契合，因为它提倡定义良好的层次和领域导向的依赖关系：核心是实体和用例，外部是接口适配器（控制器、表示器、持久化网关），边缘是框架（数据库、HTTP、消息传递）。
通过将这些原则应用于微服务中，我们就能实现这一点。 业务逻辑与技术细节隔离开来。我们可以更换数据库、Web框架或消息传递提供商，而无需重写服务的核心代码。此外，这极大地简化了单元测试和集成测试。
SOLID 设计模式、职责分离、依赖注入和简单代码原则仍然非常重要；它们现在只应用于每个微服务的较小范围内，从而更容易长期保持代码的整洁。
容器和无服务器架构中的自动化、持续集成/持续交付 (CI/CD) 和部署
如果没有微服务架构，微服务架构就毫无意义。 整个生命周期的积极自动化 在环境中 云原生由于涉及数十项服务，手动部署无异于自取灭亡。
团队通常会建立以下流程： 持续集成和持续交付（CI/CD）经常得到支持 Git 操作以可重复、可控和可追溯的方式编译代码、运行测试、生成容器镜像、应用数据库迁移（在适当的时候）以及部署服务。
最普遍的部署模式是 “将服务部署为容器”这涉及到将每个微服务打包到一个镜像（例如 Docker 镜像）中，并让 Kubernetes 或其他编排工具来处理复制、扩展和更新。这可以实现高效的资源利用和快速、一致的部署。
除此之外，还可以应用平台模式，例如： 服务网格 （Istio、Linkerd 等）在不修改服务代码的情况下，增加了高级路由功能、mTLS 安全策略、详细的可观测性以及版本之间的流量分配（金丝雀发布、蓝绿部署）。
在某些情况下，特别是对于非常有限的任务或事件驱动型任务，以下情况会发挥作用： 无服务器部署按需函数（例如 AWS Lambda）由 API 网关、队列、流或调度器等服务进行编排。虽然并非所有服务都需要无服务器架构，但它非常适合规模很小、弹性很高的微服务。
分布式系统中的安全性、可观测性和测试
微服务中的安全性基于以下原则： 零信任：默认情况下，任何人都不信任任何人。这包括通过 API 网关（OAuth2、OIDC）进行强大的身份验证，颁发随每个请求传输的令牌（例如 JWT），以及在每个服务中进行本地授权，此外还使用 mTLS 对服务之间的流量进行加密。
老板 访问令牌 这种方法可以概括为：网关验证客户端的凭据，生成包含安全上下文（身份、角色、范围）的令牌，并将其转发给微服务，微服务使用该令牌做出授权决策，而无需存储密码或内部身份验证逻辑。
就可观测性而言，有几种模式结合在一起： 应用程序指标 （按服务划分的技术和业务指标） 审核记录 （用户操作审计日志） 分布式跟踪 （跨多个服务跟踪请求） 异常跟踪 （集中式错误管理系统） 健康检查 API （状态端点）和 日志聚合 （在通用平台上进行日志聚合）。
所有这些都有助于检测异常情况。 缩短诊断时间 并了解系统在实际负载下的运行情况。如果没有良好的可观测性，微服务系统就会变成一个几乎无法操作的黑盒。
在测试领域，除了经典的单元测试之外，还有诸如以下模式： 服务集成合同测试 （核实供应商和消费者是否遵守相同的API合同） 服务组件测试 （使用外部依赖项的存根隔离运行服务），减少对脆弱且缓慢的端到端测试的依赖。
最后，成熟的 DevOps 文化和实践 混沌工程 （注入受控故障以验证架构的弹性）有助于确保系统在出现问题时运行良好，而这种情况在生产环境中迟早都会发生。
优势、劣势和采用标准
主 微服务的优势 它们围绕敏捷性和可扩展性展开：小型自主团队、频繁部署而无需停止整个应用程序、每个功能领域的独立扩展、每个服务的技术自由以及由于故障隔离而带来的更高弹性。
他们也喜欢 重用封装良好的功能 （支付、身份验证或通知服务可以作为许多解决方案的标准构建模块），降低本地更改的成本，并使组织（团队）与业务模型（领域和产品）更好地保持一致。
另一方面，微服务引入了 远非微不足道的复杂性故障点增多、网络延迟升高、数据一致性维护难度加大、部署和测试流程更加复杂，以及对可观测性、自动化和治理工具的更大需求。
此外，他们还要求 具备分布式系统经验的技术人才容器、Kubernetes、安全、集成模式、API 治理和领域设计——这些并非每个团队或公司都能掌握。
因此，微服务架构尤其适用于以下情况： 拥有庞大代码库、众多团队、功能变更频繁且对可扩展性要求极高的组织例如大型数字平台、复杂的SaaS或拥有庞大用户的系统。对于小型应用或小型团队而言，一个优秀的模块化单体架构通常更简单、更经济且足以满足需求。
微服务架构代表着对传统单体架构的重大飞跃，如果设计和治理得当，它将成为扩展组织、团队和系统的强大工具。通过利用诸如每个微服务一个数据库、Saga、API 网关、CQRS、整洁架构、容器化部署和强大的可观测性平台等模式，可以构建出结合多种架构的解决方案。 变革速度、应对失败的能力、技术自由以及与业务更紧密的契合度前提是能够接受复杂性带来的额外成本，并在自动化、文化和良好实践方面进行投资。
