微服务与测试（三）

在微服务的架构中，一般使用的是轻量级的通信方式，也就是基于HTTP的REST，也就是基于应用层的协议。就像在前面的文章中介绍中，微服务把一个单一的应用程序拆分成N个一组服务，这些服务来各自处理各自的外部请求，另外一点是这些服务会部署在不同的终端上运行，所以这些服务交互必须通过进程间的通信才能够完成，如下图：

每个服务在不同的终端同时每个服务只关心自己的业务组件，但是服务最终是为业务服务的，那么也就是说这些服务之间也必须可以很好的通信。在单一的应用程序中，实现端到端的测试相对来说很轻松的，因为它没有那么多的关联，但是微服务化后，实现端到端的测试前提是每个服务之间遵守一定的约定同时每个服务之间都可以流程走通，实现端到端的测试成本来说是比较大的。抛开怎么实现契约测试，集成测试，组件测试，端到端测试这些概念，首先需要思考的是微服务化，我们首先需要明白的是服务它是怎么通信的，这也是开头说到的，一般来说，在微服务中，通信可以分为两类，分别是同步通信和异步通信，在另外一个角度，或者说是在进程间的交互的角度上，可以分为一对一和一对多，以及同步通信和异步通信，具体总结如下：

1、一对一：客户端向服务端发送请求，希望很快的可得到服务端的回应

2、一对多：客户端发送请求后，不会很快得到服务端的回应，但是服务端最终是会回应客户端的请求，这种一般使用异步通信的方式

3、单一的请求：客户端发送请求后，不会刻意的关注服务端是否回应，只负责发送请求就可以了

在同步通信中，始终会应用到服务发现的机制，抛开HTTP的协议是无状态的协议一说，客户端发送请求后，服务端的回应某些时候并不是那么的顺利，也就是说客户端的请求可能会出现堵塞，如下图所示：

客户端发送请求后，服务端没有回应，导致请求被堵塞，这就是同步通信存在的问题之一，但是涉及一个问题是堵塞后，客户端是不是应该一直请求，就有点类似于你不理我，我就一直请求你，直到服务端有回应为止，抛开技术的范畴，即使在生活中，我们出去约会，到约定的时间，对方人还没有来，假设对方人联系不上，我们一般会等待，但是如果一直联系不上我们就不会再等待了。客户端在请求服务端遇到堵塞也会遇到这样的情景，这个时候客户端会处在堵塞状态等待服务端的响应，但是一般假设响应将会很快回应。