你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
微服务体系结构可以为应用程序提供许多优势，包括敏捷性、可伸缩性和高可用性。 此体系结构还可以带来挑战。 构建基于微服务的应用程序或将现有应用程序转换为微服务体系结构时，需要分析和评估当前情况，以确定需要改进的领域。
本文介绍迁移到微服务体系结构时要记住的一些注意事项。 可以使用本指南来评估应用程序、基础结构、DevOps 和开发模型的成熟度。
了解业务优先级
若要评估微服务体系结构，需要首先了解业务的核心优先级。 例如，核心优先级可能与敏捷性、更改采用或快速开发相关。 需要分析体系结构是否适合核心优先级。 请记住，业务优先级可能会随时间而变化。 例如，创新是初创公司的首要任务。 但是，几年后，核心优先级可能是可靠性和效率。
请考虑以下优先级：
- 创新，包括促进敏捷性和试验
- 可靠性，包括确保高可用性和容错
- 效率，包括优化资源和工作效率
记录与应用程序的各个部分相匹配的服务级别目标（SLO），以确保组织承诺，能够指导您的评估。
记录架构决策
微服务体系结构可帮助团队实现自主。 团队可以就技术、方法论和基础设施组件做出自己的决策。 然而，这些选择应尊重正式商定的原则，即共同治理。 这些原则表达了团队之间有关如何解决微服务更广泛策略的协议。
请考虑下列因素：
共享治理是否到位，以指导跨团队的体系结构决策
是否维护体系结构决策记录（ADR），包括明确的理由、权衡和状态
是否维护体系结构日志来记录设计探索和不断变化的背景
团队是否可以轻松访问和搜索 ADR 和体系结构日志
是否有技术评估框架来评估新工具和框架
你是否已制定技术选择和标准化原则
随着业务和技术要求的发展，体系结构决策是否定期进行评审和更新
评估团队组合
你需要正确构建团队，以避免跨团队进行不必要的沟通。 小型、集中、跨职能的团队最适合微服务体系结构。 这些调整通常需要改变心态，这必须在团队重组之前。
请考虑下列因素：
团队是否基于子域进行划分，并遵循 域驱动设计（DDD）原则
无论您的团队是否跨职能，并且有足够的能力独立构建和运营相关的微服务。
在计划外活动和与项目无关的任务中花费的时间量
在跨团队协作中所花的时间
您是否有识别和最小化技术债务的过程
团队如何吸取教训以及如何传达此体验
使用十二因素方法
选择微服务体系结构的基本目标是通过遵循敏捷做法更快地提供价值并适应变革。 Twelve-Factor 应用方法提供了有关如何生成可维护且可缩放的应用程序的指南。 这些准则促进不可变性、临时性、声明性配置和自动化等属性。 通过合并这些准则并避免常见的陷阱，可以创建松散耦合的自包含微服务。
了解分解方法
将整体应用程序转换为微服务体系结构需要时间。 从边缘服务开始。 边缘服务与其他服务的依赖关系较少，并且可以轻松地将系统分离为独立服务。 我们强烈建议 使用 Strangler Fig 和 反腐层 等模式，使整体式应用程序保持工作状态，直到将所有服务分解为单独的微服务。 在隔离期间，DDD 的原则可以帮助团队根据子域从整体应用程序中选择组件或服务。
例如，电子商务系统可能有诸如购物车、产品管理、订单管理、定价、发票生成和通知等模块。 你决定使用通知模块启动应用程序的转换，因为它不依赖于其他模块。 但是，其他模块可能依赖于此模块来发送通知。 可以将通知模块设为单独的微服务，但还需要更新整体应用程序以调用新的通知服务。 你决定接下来转换发票生成模块。 生成订单后调用此模块。 可以使用 Strangler Fig 和反腐层等模式来支持此转换。
数据同步、对单体和微服务接口的多次写入、数据所有权、架构分解、连接、数据量和数据完整性等因素，都可能使数据细分和数据迁移变得困难。 可以使用多种技术，例如在微服务之间保留共享数据库、根据业务功能或域将数据库与一组服务分离，以及隔离服务中的数据库。 理想的解决方案是使用每个服务分解每个数据库。 在某些情况下，这种方法可能不切实际。 在这些情况下，可以应用像具体化视图模式这样的模式和通过使用API 包装器来进行应用程序现代化的方法，以抽象化和现代化对旧有或共享数据的访问。
评估 DevOps 就绪情况
迁移到微服务体系结构时，评估 DevOps 能力非常重要。 微服务体系结构应促进应用程序中的敏捷开发，以提高组织敏捷性。 DevOps 是实现实现此能力的关键做法之一。
评估微服务体系结构的 DevOps 功能时，请考虑以下几点：
组织中的人员是否了解 DevOps 的基本做法和原则
团队是否了解源代码管理工具及其如何与持续集成和持续交付（CI/CD）管道集成
是否正确实施 DevOps 做法，包括：
遵循敏捷做法。
实现持续集成。
实现持续交付，其中代码更改会自动生成、测试和准备发布到生产环境。 此方法有助于确保软件随时可以自信地发布，并经过手动批准。
实现持续部署，通过在通过所有自动化测试后自动将代码更改部署到生产环境来扩展持续交付，而无需手动干预。
在 DevOps 和 IT Ops 的所有阶段嵌入持续监视，以确保从开发环境迁移到生产环境和客户环境时，应用程序和基础结构的持续运行状况、性能和可靠性。
你的生成和部署自动化策略是否与团队的交付目标和运营要求保持一致
是否使用功能标志和渐进式公开部署策略
如何为应用程序管理过渡环境和生产环境配置
工具链是否具有社区支持和支持模型，并提供适当的渠道和文档
确定经常更改的业务领域
微服务体系结构灵活且可适应。 在评估期间，推动组织中的讨论，以确定同事期望经常更改的领域。 构建微服务使团队能够快速响应客户请求的更改，并尽量减少回归测试工作。 在单体应用程序中，一个模块的更改需要进行多个层级的回归测试，并降低新版本发布的敏捷性。
请考虑下列因素：
服务是否可独立部署
服务是否遵循 DDD 原则
服务是否遵循单一责任原则、开闭原则、里氏替换原则、接口隔离原则和依赖关系反转原则（SOLID）原则
数据库是否为服务专用
是否使用支持的微服务机箱框架构建服务
评估基础结构就绪情况
迁移到微服务体系结构时，基础结构就绪情况是需要考虑的一个关键点。 基础结构设置不当或未使用适当的服务或组件会影响应用程序的性能、可用性和可伸缩性。 可以使用所有建议的方法和过程来创建应用程序。 但是，如果基础结构不足，应用程序的性能可能不佳，并且需要额外的维护。
评估基础结构就绪情况时，请考虑以下因素：
基础结构是否确保已部署服务的可伸缩性
是否已准备好用于微服务部署的容器基础结构
基础结构是否支持通过脚本进行预配，这些脚本可以通过 CI/CD 自动化
部署架构是否提供可用性的服务级别协议（SLA）
是否有灾难恢复（DR）计划和例行演练计划
数据是否复制到 DR 的不同区域
是否有数据备份计划
是否记录部署选项
部署基础设施是否受到监控
部署基础结构是否支持服务自我修复
评估发布周期
微服务可以适应变化，并利用敏捷开发来缩短发布周期，并更快地为客户带来价值。 评估发布周期时，请考虑以下因素：
生成和发布应用程序的频率。
部署后发布失败的频率。
在服务中断后恢复或修正问题需要多长时间。
是否对应用程序使用语义版本控制。
是否维护不同的环境并按顺序发布相同的版本。 例如，先发布到预发布环境，然后再发布到生产环境。
是否对 API 使用版本控制。
是否遵循 API 的正确 版本控制准则 。
更改 API 版本时。
处理 API 版本管理的方法包括：
- URI 路径版本控制。
- 查询参数版本控制。
- 内容类型版本控制。
- 自定义标头版本控制。
是否有针对事件版本管理的做法。
评估跨服务的通信
微服务是自包含的服务，它们通过跨进程边界相互通信来解决业务场景。 若要实现可靠可靠的通信，需要选择适当的通信协议。
请考虑下列因素：
是否遵循 API 优先方法，在其中将 API 设计和维护为系统体系结构的主要组件。
无论是评估高性能协议（例如 gRPC、HTTP/2）还是异步消息传送（如 Kafka 或 NATS），这些协议都能实现高效的服务到服务通信。
是否有长链操作，其中多个服务通过同步通信协议按顺序通信。
是否使用事件流式处理平台进行实时数据处理。
是否打算在系统中的任意位置实现异步通信。
是否计划评估消息中转站技术及其功能。
是否了解服务接收和处理的消息的吞吐量。
是否使用直接客户端到服务通信。
是否需要在消息代理级别持久化消息。
是否使用 具体化视图模式 来解决微服务的闲聊行为。
无论是打算实现重试、断路器、指数退避还是抖动模式来实现可靠的通信。 处理这些功能的一种常见方法是使用 大使模式。
是否定义了域事件来促进微服务之间的通信。
评估服务向客户端公开的方式
API 网关是微服务体系结构中的核心组件之一。 直接向客户端公开服务会产生可管理性、控制和可靠的通信问题。 API 网关充当代理服务器，用于截获流量并将其路由到后端服务。 如果需要按 IP 地址、授权或模拟响应筛选流量，可以在 API 网关级别筛选流量，而无需对服务进行任何更改。
请考虑下列因素：
客户端是否直接使用服务
API 网关是否充当所有服务的统一接口
是否为不同的客户端类型实现后端服务于前端（BFF）模式
API 网关是否可以设置配额限制、模拟响应和 IP 地址筛选等策略
是否使用多个 API 网关来满足各种类型的客户端的需求，例如移动应用、Web 应用和合作伙伴
API 网关是否提供一个门户，客户端可在其中发现和订阅服务，例如 Azure API 管理中的开发人员门户
解决方案是提供 L7 负载均衡还是 Web 应用程序防火墙（WAF）功能以及 API 网关
评估事务处理
分布式事务支持多个操作作为单个工作单元运行。 在微服务体系结构中，系统将分解成许多服务。 多个微服务在单个分布式事务中处理单个业务用例。 在分布式事务中，命令是在事件发生时启动的操作。 该事件在系统中触发操作。 如果作成功，它可能会触发另一个命令，然后可以触发另一个事件。 此过程会一直持续到所有事务完成或回滚，这取决于事务是否成功。
请考虑下列因素：
系统中的分布式事务数
如何处理分布式事务，包括使用编排或编舞的方式进行 Saga 模式管理
是否使用 事件溯源 来维护事务历史记录和状态
是否实现 命令查询责任分离（CQRS）模式
跨多个服务的事务有多少件
无论是遵循原子性、一致性、隔离和持久性（ACID）事务模型，还是基本可用、软状态和最终一致性（BASE）事务模型，以实现数据一致性和完整性
是否对涉及多个服务的事务使用长链操作
是否在执行 Saga 之外还实施补偿模式以用于事务回滚
评估服务开发模型
微服务体系结构的最大优势之一是技术多样性。 基于微服务的系统使团队能够使用他们选择的技术开发服务。 在传统应用程序开发中，可以在生成新组件时重复使用现有代码，或创建内部开发框架来减少开发工作量。 使用多种技术可以防止重复使用代码。
请考虑下列因素：
是否使用标准化服务模板来加速新的服务开发，并确保体系结构、部署和 DevOps 实践中的一致性
是否遵循 Twelve-Factor 应用方法并使用微服务的单个代码库来隔离依赖项并外部化配置
是否在密钥保管库中保留敏感配置
是否容器化服务
是否知道数据一致性要求
评估部署方法
部署方法是跨各种部署环境发布应用程序版本的方法。 基于微服务的系统提供比传统应用程序更快地发布版本的灵活性。
评估部署计划时，请考虑以下因素：
是否具有部署服务的策略
是否使用新式工具和技术部署服务
部署服务时团队需要哪种类型的协作
是否使用基础结构即代码（IaC）来配置基础结构
是否遵循不可变基础结构原则
是否使用 DevOps 功能自动执行部署
是否将相同的生成传播到多个环境，如 Twelve-Factor 应用方法建议的那样
评估托管平台
可伸缩性是微服务体系结构的主要优势之一。 微服务与业务域相对应，因此可以独立扩展每个服务。 整体式应用程序作为一个单元部署在托管平台上，因此需要整体地进行扩展。 此方法会导致停机、部署风险和维护。 整体式应用程序可能设计良好，并且具有解决各个业务域的组件。 但由于进程边界不足，违反单一责任原则的可能性增加。 确保单一责任原则的努力可能导致代码缺乏结构且难以维护。 由于应用程序是作为单个托管进程组合和部署的，因此难以实现可伸缩性。
微服务使团队能够选择正确的托管平台来支持其可伸缩性需求。 各种托管平台可以通过提供自动缩放、弹性预配、更高的可用性、更快的部署和轻松监视等功能来解决这些挑战。
请考虑下列因素：
用于部署服务的托管平台（如虚拟机、容器或无服务器平台）
托管平台是否可缩放并支持自动缩放
扩展托管平台需要多长时间
是否了解各种托管平台提供的 SLA
托管平台是否支持 DR
评估服务监视
监视是基于微服务的应用程序的重要元素。 故障排除错误可能令人望而生畏，因为应用程序分为许多独立运行的服务。 如果使用适当的语义来监视服务，团队可以轻松监视、调查和响应错误。
请考虑下列因素：
是否监视已部署的服务
您是否已定义SLO
是否具有日志记录机制以及使用的工具
是否已经实施了分布式跟踪基础设施
是否选择记录异常
是否维护业务错误代码以快速识别问题
您是否使用运行状况探测来监控服务
是否使用语义日志记录并实现关键指标、阈值和指示器
是否在日志记录期间屏蔽敏感数据
是否监视服务依赖项和外部集成
评估关联令牌分配
在微服务体系结构中，应用程序由独立托管的各种微服务组成，并相互交互，为各种业务用例提供服务。 当应用程序与后端服务交互以执行作时，可以将唯一的数字（称为关联令牌）分配给请求。 建议考虑使用相关令牌，因为它们可以帮助你排查错误。 它们可帮助你确定问题的根本原因、评估影响并确定解决问题的方法。
你可以使用关联令牌来检索请求跟踪，方法是识别哪些服务包含关联令牌，哪些服务不包含关联令牌。 没有该请求的关联令牌的服务显示失败状态。 如果发生故障，可以重试事务。 若要强制实施幂等性，只有没有关联令牌的服务才会为请求提供服务。
例如，如果您有一个包含许多服务的操作链，向服务传递关联令牌可以使您能够轻松调查事务期间任何服务失败时的问题。 每个服务通常都有自己的数据库。 关联令牌保存在数据库记录中。 如果事务重播，其数据库中具有该特定关联令牌的服务将忽略请求。 只有没有令牌的服务能处理请求。
请考虑下列因素：
在哪个阶段分配相关令牌
哪个组件分配相关令牌
是否在服务的数据库中保存相关性令牌
相关令牌的格式
是否记录关联令牌和其他请求信息
评估对微服务底盘框架的需求
微服务底盘框架是一个基本框架，提供跨领域关注的功能，如日志记录、异常处理、分布式跟踪、安全性和通信。 使用机箱框架时，更注重实现服务边界，而不是与基础设施功能交互。
例如，假设要构建购物车管理服务。 你想要验证传入令牌、将日志写入日志记录数据库，并通过调用该服务的终结点与另一个服务通信。 如果使用微服务机箱框架，则可以减少开发工作。 Dapr 是一个提供各种构建基块来实现横切关注点的系统。
请考虑下列因素：
是否使用微服务底盘框架。
是否使用 Dapr 与交叉关注点进行交互。
底盘框架是否与语言无关。
机箱框架是否为通用框架，以便它可以支持各种应用程序。 机箱框架不应包含特定于应用程序的逻辑。
机箱框架是否提供一种机制来根据需要使用所选组件或服务。
评估应用程序测试的方法
开发完成后，通常会对应用程序进行测试，以确保其已准备好进入用户验收测试（UAT）和生产环境。 请考虑在应用程序开发生命周期的早期进行测试。 此方法称为左移测试。 它提高了应用程序的质量，因为你在应用程序开发生命周期的每个阶段（包括设计、开发和开发后阶段）进行测试。
例如，生成应用程序时，首先设计体系结构。 使用 Shift-left 方法时，可以使用 Microsoft Threat Modeling 等工具测试漏洞的设计。 在开始开发时，可以通过运行静态应用安全测试（SAST）工具和其他分析程序来扫描源代码，以发现问题。 部署应用程序后，可以使用动态应用程序安全测试（DAST）等工具在托管应用程序时对其进行测试。 功能测试、混沌测试、渗透测试等各种测试稍后发生。
请考虑下列因素：
是否编写涵盖整个开发生命周期的测试计划
是否在需求会议和整个应用程序开发生命周期中包含测试人员
无论是使用测试驱动设计还是行为驱动设计
是否测试用户情景并在用户情景中包含接受条件
是否使用Microsoft威胁建模等工具测试设计
是否编写单元测试
无论是使用静态代码分析器还是其他工具来测量代码质量
是否使用自动化工具测试应用程序
是否实施 安全的 DevOps 做法
是否执行集成测试、端到端应用程序测试、负载和性能测试、渗透测试和混沌测试
评估微服务安全性
服务保护、安全访问和安全通信是微服务体系结构最重要的注意事项之一。 例如，基于微服务的系统跨多个服务并使用每个服务的令牌验证不是可行的解决方案。 这种类型的系统会影响整个系统的敏捷性，并可能会在服务之间引入实现偏差。
API 网关和应用程序防火墙通常处理安全问题。 网关和防火墙采用传入请求、验证令牌并应用各种筛选器和策略，例如实现 OWASP 前 10 个原则来拦截流量。 最后，将请求发送到后端微服务。 此配置可帮助开发人员专注于业务需求，而不是担心安全性的交叉问题。
请考虑下列因素：
服务是否需要身份验证和授权，以及是否实施 零信任体系结构原则
是否有全面的机密管理策略，包括密钥轮换、生命周期管理和审核，而不仅仅是将机密存储在密钥保管库中
是否使用 API 网关验证令牌和传入请求
无论是使用安全套接字层（SSL）还是相互传输层安全性（mTLS）为服务通信提供安全性
是否实现容器和映像安全扫描
是否实施网络安全策略以允许服务之间所需的通信
无论是使用防火墙（如 L4 还是 L7），在适用的情况下为内部和外部通信提供更多的安全性
是否在 API 网关中使用安全策略来控制流量
是否有运行时安全监视来检测异常行为
Contributors
Microsoft维护本文。 以下参与者撰写了本文。
主要作者：
- 奥瓦斯·梅博布·艾哈迈德汗 |高级云解决方案架构师 - 云和 AI 应用
- Nabil Siddiqui |解决方案工程师 - 云和 AI 应用
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。