微服务架构的测试策略(1)

服务基础架构在过去的几年中出现了朝着更小，更集中的“微”服务方向的转变。这种方法有很多好处，如独立部署，扩展和维护各个组件以及能够多个团队并行开发。然而，一旦这些附加网络分区结构已经出现，我们就需要重新考虑调整原先应用于整体结构应用程序的测试策略。

这里，我们将讨论一些用来管理多个独立部署组件的额外测试复杂度的方法，以及在多个团队各自负责应用程序的不同服务时仍然保持正确的方法。

微服务架构将软件构建为一组协作服务

微服务架构是将单一职责原则应用于架构层面的自然结果。这比起传统的整体架构而言有许多好处，例如不同部分的独立部署，语言，平台以及技术独立，不同轴上的可扩展性以及增加的结构灵活性。

在规格方面，并没有硬性规定。

常见的是，微服务是大约数百行的程度，但也可以是几十行或数千行，这取决于它们封装后起到的职责。一个好的经验法则，虽然并非绝对，是尽可能的小，但要足够大，足够表现其领域概念。 “微服务应该要多大呢？”一文中有更多的详细内容。

微服务通常使用通过HTTP的REST来集成。以这种方式，业务域概念通常被建模为一个或多个由各个服务管理的资源。在最成熟的RESTful系统中，资源使用超媒体进行控制，使得各个资源的位置对服务所面向的消费者而言是不透明的。更多细节可参见 Richardson成熟度模型。

有时也可以使用备选的集成机制，例如轻便的消息传递协议，发布/订阅模式或替代传输方式，例如Protobuf或Thrift。

每个微服务可能提供也可能不提供某种形式的用户界面。

微服务通常可以分成相似类型的模块

通常情况下，微服务的内部结构由所示的各层的部分或全部来组成。

所选择的测试策略应着眼于保持轻便的同时，能够覆盖到各层以及层与层之间的服务。

资源(Resources)是作为由服务所暴露的应用协议以及表示域对象的消息之间的映射器。通常情况下，它们比较轻便，用于检查请求的完备性，并提供根据业务事务的输出来返回一个协议特定的响应。

几乎所有在域模型中的业务逻辑都代表了业务域。在这些对象中，服务跨越多个领域进行协调，而库作用于域实体的集合，而且往往持续性支持。

如果一个服务需要另一服务进行协作，那么一些逻辑就需要与外部服务进行通信。网关打包域对象的请求和响应，封装消息并传递至远程服务。它可能会使用理解底层协议的客户机来处理请求-响应周期。

除了最简单的情况，或当一个服务作为聚合其他服务所拥有的资源的聚合器之外，微服务需要能够在几个请求之间储存域的对象。通常这是通过使用对象关系映射或使用满足持久性要求的复杂性的更轻便的数据映射器实现。

通常情况下，这个逻辑块被封装在一组由域存储库使用的专用对象中。

（待续）

{测试窝原创译文，译者：大头}

译者简介：大头，在读日本九州大学修士，计算机专业，主研究方向为文本挖掘，及自然语言处理。