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