微服务与测试（四）

在前面的文章体系中对什么是微服务，以及微服务的优点和缺点都有所介绍，同时也介绍了单一应用程序的架构它所存在的缺点，以及微服务对单一程序架构进行的拆分和分离组件的应用。虽然我们很清晰的知道接口测试是对API的测试，也大概都听过契约测试，组件测试，端到端的测试，以及单元测试，其实在微服务架构中最核心的还是它的通信机制，就像我们在上一节文章中所提到的，如果我们只是单纯的在应用上层做接口测试，但是API Gateway出现问题，或者是底层的服务出现问题，所有的应用上层都得瘫痪，那么这也在另外一个角度给我们一个暗示，我们经常谈的分层，不单单是基于金字塔模型的分层，如果单纯的在API测试的维度来说，它也是存在分层，当然这个话题不是今天的主题。

刚才也说到，微服务架构中，最核心的是它的通信机制，它采用的是轻量级的通信方式，但是在客户端与服务端交互上，又可以分为同步通信与异步通信，而今天主要介绍同步通信部分。在微服务的架构中，最终所有的组件都会分布式的部署在不同的机器上，每个进程就是一个服务，进程与其他进程通过不同网络请求进行通信，就像前面介绍的无涯课堂，它分为四个不同的微服务，分别是账户服务，订单服务，物流服务，和图书服务，那么这样服务在实际的业务场景中会进行服务与服务之间的通信，每个服务之间都会相互调用和请求对方，在这个时候，客户端与服务端之间的边界显得很模糊，有可能客户端就是服务端，服务端就是客户端，因为不同的请求交互上，它可能是回应其他的服务，也可能是为了回应其他的服务去请求另外一个服务，这个时候它是服务端也是客户端，见如下交互：

在如上图中可以看到，图书服务相对账户服务而言它是客户端，但是相对物流服务它是客户端，在账户服务请求图书服务，图书服务请求物流服务的业务场景中图书服务即是客户端也是服务端。

在同步通信中，客户端发送请求给服务端，服务端得回应客户端的请求，这样的机制也可以称为请求/响应机制，在这样的一个过程中，存在的缺点是超时和强耦合，超时很好理解，也就是客户端与服务端之间的交互可能在请求/响应的过程中出现网络异常或者终端出现负载，导致服务端不能及时的回应客户端的请求，强耦合也就是说客户端的请求太依赖于服务端的回应，如果服务端不回应会怎么样，如果服务端和客户端根本不知道对方存在又会如何，这是异步需要思考的，至少在同步的通信中是这样的。有一种解决方案是使用Hystrix来解决超时的问题，它的主要作用是失败的时候重试。见同步通信中的交互图：

相对来说，在微服务的架构中，使用同步通信的还是少，更多使用的是异步通信，会通过MQTP的方式来管理客户端与服务端的交互。也如前面说的，微服务使用的是轻量级的通信协议，也就是基于HTTP的RESTFUL API，所以在整个微服务测试中，可以使用Postman或者JMeter这样的测试工具，也可以使用如Requests这样的第三方库来调用对对应的API来验证服务的正确性,容错性和健壮性。后面详细的介绍接口的测试维度。