什么是微服务编排？

想象一下交响乐团的指挥，他指挥每位乐手在正确的时刻演奏。同样，微服务编排可以确保每个微服务在需要时执行其特定功能，从而提供无缝的用户体验。如果没有这种协调，将会一片混乱，服务随意相互调用，组件故障时工作流中断，并且无法了解不同 IT 基础设施的整体情况。

组织需要微服务编排，因为现代应用程序复杂，由数百个独立的服务组成。微服务编排充当系统角色，将这些独立服务转化为协调良好的应用程序，同时保持分布式架构的可扩展性和灵活性优势。

根据 Research Nester 的一份报告，微服务编排市场在 2024 年的估值为 47 亿美元，预计到 2032 年将达到 723 亿美元。本研究表明，预测期内的复合年增长率 (CAGR) 为 23.4%。 ¹

推动市场稳步扩张的因素包括全球科技公司（如 Google 和 Amazon）应用程序的增长，以及来自电子商务、金融科技和流媒体服务的日益增长的需求。

Netflix 和 Hulu 等大型流媒体服务就是典型的用例。它们依赖微服务编排来协调数百个微服务，这些微服务负责处理从用户身份验证和内容推荐，到视频流和计费的所有事务。所有这些都必须协同工作，才能同时提供数百万种个性化观看体验。

微服务是小型、独立且自包含的软件组件，它们协同工作以构建完整的应用程序。它们使组织能够更高效地构建、部署和扩展应用程序。

与传统的单体应用程序不同，云原生微服务架构将应用程序拆分为更小的、专注的服务，这些服务负责处理特定的业务功能。每个微服务独立运行，通过应用程序编程接口 (API) 进行通信，并且可以单独开发、部署和扩展。

让我们以 Uber 或 Lyft 等拼车应用程序为例。当应用程序处理一次叫车请求时，编排器会调用位置服务以寻找司机，启动匹配算法，并计算价格。编排器还会以协调的顺序向乘客和司机发送通知。

这种方法使组织能够构建更灵活、可扩展的系统，并能够快速适应不断变化的业务需求。像 Netflix、Amazon 和 Uber 这样的科技公司率先采用微服务来应对大规模需求和快速的软件开发。根据 2021 年 IBM 调查，85% 的组织已经采用或计划采用微服务架构，这凸显了其日益重要的地位。

微服务编排框架使用集中式工作流管理系统，通过同步服务调用分发业务流程。编排器维护工作流定义，了解服务依赖关系，并能够确保微服务按正确的顺序运行。

例如，当像 Amazon 这样的电子商务公司处理客户订单时，编排器会调用库存服务以检查可用性，启动支付处理，安排发货，并向客户发送通知。编排器以协调的顺序完成所有这些任务。

这种协调依赖于关键技术，例如用于应用容器化的Docker，以及容器编排平台（诸如 Kubernetes，用于管理容器的部署、扩展和服务发现）。这些工具使服务能够动态通信，同时优化整个基础设施的资源分配。编排器会持续监控流程中的每一个步骤，因此当出现问题时，它可以自动重试失败的操作、回滚有问题的更改，或向管理员发出警报，以维护系统的可靠性。

微服务编排具有以下主要优势：

• 提升的可扩展性和资源管理：编排平台在所有微服务中提供智能的自动扩展和资源管理，能够根据需求模式做出全系统的扩展决策。

• 增强的系统弹性和故障隔离：集中式编排通过重试操作自动处理故障，防止单个服务的失败导致整个应用崩溃，并保持所有服务的数据一致性。

• 更快的开发与部署周期：自动化的服务协调消除了手动集成工作，使开发人员能够专注于业务逻辑，同时通过协调发布实现更安全的部署。

• 更高的技术多样性与灵活性：开发团队可以为特定服务选择最优的编程语言、数据库和框架，同时通过统一的编排参与协调的工作流程。

• 支持 AI/ML 工作负载：编排处理机器学习 (ML) 流程所需的复杂协调，从数据预处理和模型训练，到部署和监控。它还管理不同人工智能 (AI) 服务的不同计算需求。

成功的编排依赖于经过验证的微服务设计模式，这些模式能够解决常见的分布式系统挑战。以下是一些最重要的示例：

Saga 模式通过将分布式事务分解为可逆步骤来管理分布式事务。如果任何步骤失败，Saga 会执行补偿操作，以撤销之前的操作并保持各服务间的数据一致性。

例如，在电子商务网站上，如果结账时支付失败，Saga 会取消库存保留并恢复购物车。

断路器通过监控对下游服务的调用，并在检测到故障时停止请求，从而防止级联故障。

例如，当产品推荐服务开始出现故障时，断路器会自动阻止对该服务的请求，并显示之前缓存的推荐结果。

重试与超时模式通过等待并以智能的时间间隔再次尝试失败的请求，自动处理临时的服务故障。

例如，如果支付服务暂时不可用，系统将等待并重试。

在构建分布式系统时，DevOps 团队和开发人员必须决定服务是由中心进行协调，还是让服务自行协调。这一决策决定了微服务的通信方式、团队如何管理复杂性以及系统随时间的扩展方式。

• 微服务编排使用集中式协调器来管理所有服务交互。像项目经理一样，编排器了解整个工作流，并告诉每个服务何时执行操作。这种方法能够清晰地呈现复杂流程，并使实施业务规则和维护审计记录更加容易。

• 微服务协作采取相反的方法，服务通过事件自行协调，而无需中心控制。当一个服务完成工作时，它会发布一个事件，从而触发其他服务执行相应操作。像事件流平台（如 Apache Kafka）通常通过在大规模环境中可靠地传递服务间消息来支持这些交互。

当团队需要明确的工作流控制、集中治理和严格的数据一致性时，他们会选择编排。它在金融、医疗保健和物流领域尤其有价值，在这些领域，监管合规性和可审计性至关重要。

当可扩展性、弹性和服务自治是优先考虑时，团队会选择协作方式。它非常适用于事件驱动架构、实时系统和高吞吐量处理（例如内容平台和物联网 (IoT) 系统）。

大多数成功的微服务架构采用混合方法。这种方法可能意味着对需要严格控制的关键业务工作流采用编排，而对松耦合的交互采用协作，以利用独立处理的优势。

现代编排依赖于多个类别的工具协同工作，以管理微服务的整个生命周期，从部署和扩展到通信和监控。下面介绍的每个类别在实现高效微服务编排中都扮演着特定角色：

• 容器编排平台

• 服务网格

• 无服务器架构平台

• API Gateway

• 服务发现工具

• 工作流和编排引擎

容器编排平台可自动部署、扩展和管理容器化应用程序。它们通过处理服务发现、负载平衡、自动扩展和滚动部署为微服务编排提供基础层。

主要云供应商均提供托管编排服务，包括 AWS 的 Amazon ECS 和 EKS、Google GKE、Microsoft AKS 和 IBM Cloud Kubernetes Service。

服务网格负责服务间的通信、安全以及可观测性，而无需修改应用程序代码。它们提供自动负载平衡、断路器、超时和微服务交互的全面遥测。

Istio 是一款可配置的开源服务网格，可透明地叠加到现有应用程序上，具备高级流量管理和策略执行能力。它与 Kubernetes 以及许多其他与服务网格相关的技术配合良好。

Linkerd 也是开源的，注重简洁性和性能，提供基本的服务网格功能，同时保持最小的运维开销。

无服务器架构平台支持事件驱动的微服务，能够根据需求自动扩展。它们提供从零到数千实例的自动扩展，以及内置的流量管理以实现安全部署。

Knative 运行在 Kubernetes 之上，为容器化的工作负载提供无服务器架构功能，实现自动扩展和简化部署。

API 网关为微服务提供统一入口，负责身份验证、速率限制、请求转换以及全面的日志记录。它们对于协调外部客户端与内部服务之间的交互至关重要。

市面上有许多 API 网关解决方案，从开源选项如 Kong，到主要供应商提供的云托管服务不等。

服务发现工具使微服务能够动态地相互查找和通信，从而消除了硬编码的依赖关系。它们处理服务注册、健康状况检查和负载均衡协调。

流行的解决方案包括适用于 Kubernetes 环境的 etcd，以及云原生选项如 Amazon Web Services (AWS) Cloud Map。

工作流与编排引擎能够在多个微服务之间随时间协调复杂的多步骤流程。这些平台提供可视化的工作流定义、自动错误处理以及内置的重试逻辑，用于管理分布式业务流程。

Netflix Conductor 专门处理为微服务环境设计的工作流编排。Camunda Zeebe 通过使用业务流程模型和符号 (BPMN) 提供企业级流程编排，以实现可视化工作流程定义和全面的流程管理。