采用微服务所带来的诸多优势往往会在质量层面引发一系列挑战。

微服务近来已经成为优步、Netflix、Spotify以及Amazon等众多重量级厂商的优先选择。毫无疑问，这套架构方案在软件开发生命周期内具备着巨大吸引力，但其带来的诸多优势亦往往会在质量层面引发一系列挑战。

　　1.系统依赖性增加

　　根据定义，由整体式应用或服务过渡至微服务架构时会引入更多逻辑隔离组件。尽管这种拆分方式增加了缩放能力与灵活性水平，但亦引入更多依赖关系，使得系统整体更为复杂。具体来讲，这意味着完整测试环境的配置与检测指标更加难以衡量。

　　例如，假定我们设置的测试环境将原有应用程序拆分为10项Web服务。为了便于讨论，我们假设每项Web服务各自拥有10项操作，且每项操作具备自己的一项独立微服务（10乘以10）。原本的测试环境只需要访问初始的10项Web服务，但如今新的测试环境则需要在全部测试场景中访问100项经过妥善配置的微服务。

　　2.并行开发障碍

　　系统依赖性的增加还会给微服务的并行开发工作造成影响。系统依赖性扩展会产生两种瓶颈类型：团队需要等待其它团队以完整相关微服务的并行开发，以及/或者团队需要等待测试环境得到妥善配置（即包含全部相关微服务的正确版本）方可实现聚合、配置与设定。微服务数量越多，需要考虑的对象就越是广泛，这意味着以并行方式开发及发布新功能就变得愈发困难。

　　3.影响传统测试方法

　　传统测试方法往往需要配合要求或者用户背景，并通过UI测试进行验证。而在微服务方面，我们则需要对测试策略进行整体变更，这意味着原有测试方法将不再适用。尽管通过UI实现的测试仍可在软件开发生命周期末期顺利起效，但微服务在消息层需要的方案无疑更加复杂。

　　另外，验证各独立微服务还只是第一步。我们还需要通过现具分布式特性的微服务架构检查全部关键性事务的执行路径。由于微服务的目标之一在于实现快速变更，因此我们必须意识到：

　　· 与服务自身相关的素材会发生变化。

　　· 这种变化会影响到其它服务的依赖性。

　　· 这种变化会影响到关键性端到端事务。

　　· 这种变化会影响到最终用户体验。

　　· 需要在测试数据中引入更多新要求。

　　· 需要应对更多非功能性要求，例如性能、可访问性、可靠性以及弹性等等。

　　4.更多潜在故障点

　　微服务迁移的另一大负面影响在于引发大量独立故障点。回到之前提到的简单举例，单一Web服务的失败将影响全部10项操作。但在迁移后，拆分带来的10项微服务各自都会在发生故障时影响其它9项服务。尽管微服务能够利用隔离机制限定各独立故障点的影响范围，但开发测试人员必须意识到众多活动组件所带来的高度复杂性。

　　为了了解微服务变革给业务带来的影响，开发测试团队必须马上对测试依赖性进行广泛而严格的监控。另外，开发测试团队还需要能够深入访问采用这类高度模块化、分布式体系架构的测试环境。