【.com快译】采用微服务带来的诸多好处，往往会带来一系列质量层面的挑战。微服务最近成为许多重量级人物的首选，例如Uber、Netflix、Spotify和Amazon。毫无疑问，这种架构解决方案在软件开发生命周期中具有巨大的吸引力，但它带来的众多优势往往会导致一系列质量层面的挑战。1.增加系统依赖根据定义，从单体应用或服务过渡到微服务架构时，会引入更多逻辑隔离的组件。虽然这种拆分方法提高了可扩展性和灵活性的水平，但它也引入了更多的依赖关系并使整个系统更加复杂。具体来说，这意味着完整测试环境的配置和检测指标更难衡量。例如，假设我们设置了一个将原始应用程序拆分为10个Web服务的测试环境。为了便于讨论，我们假设每个Web服务都有10个操作，每个操作都有自己独立的微服务（10乘以10）。原来的测试环境只需要访问最初的10个web服务，而现在新的测试环境需要在所有测试场景下访问100个正确配置的微服务。2.并行开发障碍系统依赖的增加也会影响微服务的并行开发。系统依赖扩展会产生两种类型的瓶颈：团队需要等待其他团队完成相关微服务的并行开发，和/或团队需要等待测试环境被正确配置（即包含所有相关微服务的正确版本）以这样做聚合，配置和设置。微服务的数量越多，需要考虑的对象就越广泛，这意味着并行开发和发布新功能变得更加困难。3、对传统测试方式的影响传统测试方式往往需要配合需求或用户背景，通过UI测试进行验证。在微服务方面，我们需要对测试策略做一个整体的改变，这意味着原来的测试方式将不再适用。尽管通过UI进行测试在软件开发生命周期结束时仍然可以顺利进行，但微服务在消息传递层需要更复杂的解决方案。此外，验证单个微服务只是第一步。我们还需要通过现有的分布式微服务架构来检查所有关键事务的执行路径。由于微服务的目标之一是实现快速变化，我们必须意识到：与服务本身相关的东西会发生变化。此更改将影响其他服务的依赖项。此更改会影响关键的端到端事务。此更改会影响最终用户体验。需要在测试数据中引入更多新的需求。需要解决更多的非功能性需求，例如性能、可访问性、可靠性和弹性。4.更多的潜在故障点微服务迁移的另一大负面影响是引入了大量独立的故障点。回到前面提到的简单示例，单个Web服务的故障将影响所有10个操作。但迁移后，拆分后的10个微服务中的每一个在发生故障时都会影响其他9个服务。虽然微服务可以利用隔离机制来限制单个故障点的影响，但开发测试人员必须意识到许多活动组件所带来的高度复杂性。为了了解微服务变更对业务的影响，开发和测试团队必须立即对测试依赖项进行广泛而严格的监控。此外，开发和测试团队需要深入访问采用这种高度模块化、分布式架构的测试环境。原标题：微服务带来的4大质量挑战原作者：CynthiaDunlop
