什么是微服务架构？

微服务架构是一种将应用程序构建为一组小的、独立的组件的方法，这些组件 通过API在网络上进行交互。NIST SP 800-204 认为这种方法具有更小的代码库、独立团队和按组件扩展的优点。

这就像有一组工作人员，他们都带着共同的目标协同工作，每个人都发挥着自己的专长。这与以前的单体结构不同，后者就像一个大人物包揽一切，随着应用程序复杂性的增加，变得难以控制。

微服务架构与传统的单体架构在以下方面有所不同。

• 去中心化： 微服务将功能分解并分布到各个独立的服务中，而 一个 单体将所有功能整合到单一代码库中。
• 松耦合： 微服务通过 API 进行通信，具有高内聚和低耦合的特点，而单体应用中，组件通常是耦合且内聚的。
• 独立部署： 微服务允许在不影响整个系统正常运行的情况下更换或部署单个服务，而单体架构中的更改则需要协调部署。
• 可扩展性： 微服务可以根据用户需求独立调整，而像单体应用这样的方法则需要在整个应用程序中进行扩展。
• 故障隔离： 在微服务中，当一个服务失败时，它不会影响其他服务；而在单体服务中，一个组件的失败可能会导致整个应用程序的失败。

采用微服务架构，是以运维复杂性来换取独立伸缩和故障隔离。

优势：

• 可扩展性： 根据需求以一定规模开发特定服务，从而实现资源的有效利用。
• 增强的敏捷性： 独立开发和部署与更快的周期启动和变更响应能力相关。
• 技术灵活性： 每个服务使用合适的语言和工具的能力，是可能与创新和服务优化相关的因素。
• 故障隔离： 为了减少服务故障的影响并提高系统稳定性。
• 可维护性： 每个小型、特定的服务都比一个单一、包罗万象的服务更容易理解、开发和管理。

挑战：

• 复杂性增加： 由于固有的复杂性，管理分布式系统比集中式系统需要更复杂的方法。
• 数据管理： 在数据管理中，每个服务的独立数据存储通常与这些服务之间的最终数据一致性相关联，而非即时一致性。
• 测试： 进行所有简单和复杂的测试至关重要，以确保所有服务的兼容性以及整个系统在部署后的稳定性。
• 沟通： 服务间的通信对于高效运行至关重要，但它会带来延迟和可能的故障区域。
• 安全性： 跨多个服务保护敏感数据需要周密的计划和执行，以避免服务漏洞。

微服务主要通过 API（应用程序编程接口）进行交互，这些 API 描述了数据将如何交换以及以何种格式交换。这种通信模式包括：

• 同步请求-响应： 一个服务将请求转发给另一个服务，并期望后者做出响应。这很简单，但如果管理不善，可能会导致紧密耦合和性能问题。 通常通过HTTP上的REST或用于低延迟的gRPC；外部客户端通过API网关进入。REST API是服务被访问的方式，而不是服务本身。
• 异步消息传递： 服务通过消息代理交换消息，以实现解耦并获得更高的可扩展性。当需要处理大量数据或事件时，此模式最为有效。 代理通常是Apache Kafka或RabbitMQ，而不是微服务本身。
• 事件驱动架构： 服务发布事件，其他服务可以监听 ，以促进 松散耦合和响应性。这种模式非常适合需要跨多个服务进行更新或更改的场景。

最佳实践包括：

• 领域驱动设计 (DDD)： 将系统分解为 限界上下文 涵盖业务能力，这将提高系统的可读性和可维护性。
• API优先设计: 建立清晰且文档完善的接口，以便服务在系统中进行互操作，从而确保一致性和易于集成。
• 容器化： 将服务划分为包，并放入部署容器中，以便更好地控制和 轻松扩展解决方案. 这意味着 将它们部署在 Docker 容器中 由 Kubernetes 调度：82% 的容器用户在生产环境中运行 Kubernetes (CNCF, 2026).
• 持续集成和持续交付 (CI/CD): 通过定期、可预测和可重复的发布来标准化构建、测试和部署。
• 监控和可观测性： 记录和监控服务状态和性能，以确保它们被良好地记录和存档，以便在出现问题时，可以轻松识别根本原因。

成功的微服务现实案例包括：

• Netflix： 实施了基于微服务的架构，以支持全球扩张并管理其流媒体服务的高流量。
• 亚马逊： 该电商网站选择 一个 在从之前的单体设计迁移后采用微服务架构，旨在提高适应性和通用性。
• 优步： 微服务分别管理乘车请求、付款和司机，从而促进增长。

两者 Netflix 和 Amazon 最初都是单体，后来才拆分：在一个应用内部构建模块，然后将扩展性受限的模块拆分出来。