微服务与测试(一)

在去年的时候就提到了，在接下来的一年，测试必然会接触到微服务的测试，而在微服务测试的层次，首先需要了解的是微服务到底是什么，它的通信机制又是什么，对测试的挑战又是什么，面对微服务，我们应该以什么样的思路和态度来面对这些了？在本篇文章对微服务做一个简单的介绍。在后面的文章中会逐步的介绍里面的细节知识。

首先什么是微服务，微服务是一种架构模式，也是一种思想，它倡导将单一应用程序划分成一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信进制互相沟通。(基于HTTP协议是RESTFUL API)。每个服务围绕具体的业务构建，并且能够独立部署到生产环境中。在这里可以获取到这么几个关键信息，第一是微服务它采用轻量级的通信方式，第二是它将一个单一的应用划分成N个小型的服务，而服务之间根据业务互相协调和配合，第三是每个微服务它是一个独立的进程，第四是微服务与数据库之间不是绝对的，也就是说，不一定说每个微服务都必须有自己的数据库，而且很有可能是多个微服务使用了一个数据库实例，也有可能是一个微服务使用了一个数据库，这具体得根据业务场景。

在微服务的通信机制是采用轻量级的通信方式，也就是基于HTTP协议的RESTFUL API,HTTP协议它是应用层的协议，因此不需要太多的去关注底层网络传输层的事情。在微服务通信机制中，分为两类，一类是同步通信的机制，另外一类是一步通信。同步通信比较好理解，也就是说客户端发送请求到服务端的过程，在这个过程中，客户端与服务端之间是有互相依赖的，客户端发送请求后，服务端必须得回应客户端的请求，而作为服务端还是客户端，它能够感知到对方的存在并且等待对应的回应，但是可能会由于网络因素等其他的异常情况，比如超时，导致客户端发送请求到服务器端后，需要迟迟的等待或者等待超时，因为这种方式有缺陷也有好处。而异步通信方式中，客户端与服务端之间没有太多的依赖性，简单的说就是客户端发送请求后，它不需要刻意等待被请求服务的回应，而对方也不知道客户端的存在，因此这样的一个通信方式中，这种方式使用轻量级消息传递代理。作为A和B两个服务，A服务生成一个消息后发送给消息代理，而订阅主题的B服务将提供属于该主题的所有服务。A和B服务之间根本不需要互相了解对方的存在，他们只知道某中类型的消息存在即可。

作为微服务而言，会有很多的优点，当然缺点也是存在，这也是为什么在谈论微服务或者devops的时候不得不谈论康威定律，关于该话题到后面具体讨论。在这里只是简单的看下微服务的优点，它的优点主要是易于维护，技术选型比较自由，不会捆绑在一个语言上面，易于扩展，独立部署，更好的组织支持和组织效率。

微服务给测试的挑战在我个人理解，主要是这么几点，第一点是技术的扩展，因为在面对微服务测试的时候，不得不了解通信的方式，微服务之间的各种请求和请求顺序以及逻辑；第二是对过去认知的一种颠覆，我们一直在金字塔的模式中来进行分层，但是在微服务的架构模式下，金字塔的测试模式依然会被使用，但是会增加新的层次，比如契约测试，组件测试，端到端的测试；第三，它让我们不得不去思考它带来的好处和带来的坏处，关于这点，后面具体说康威定律；第四，平台化的思路与服务，微服务的趋势是paas，也就是平台即服务，Platform As A Service；第五是如何在微服务架构的模式下，更快，怎么样可以打造高效的组织效率和研发效率，和符合要求的产品质量。对于测试而言，基于微服务的架构下，会越来越复杂，也会面临刚才说的很对的挑战，这种挑战一方面是技术方面，另外一方面是思路方面。