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