“微服务”架构是近期软件应用领域非常热门的概念。在这种架构风格中，一个大型复杂软件应用会被分解为多个微服务。系统中的每个微服务一般都通过一个进程实现，仅需关注于完成一件任务并很好地完成该任务。在这种架构中，一方面由于微服务之间是松耦合的，使得开发人员可以专注于某个微服务而不是整个系统，有效降低了开发成本，另外一方面由于每个微服务都体量较小，可独立部署，使得可以实现快速开发测试部署上线，从而达到随着业务变化产品快速迭代的目的。

要想合理利用微服务架构，微服务之间的有效可靠通信是个必须解决的问题。当不同的微服务位于不同的机器时，基于 TCP/IP 的网络通信是微服务之间进行有效可靠通信的唯一途径，但每一个微服务都独立实现基于 TCP 的应用层协议一是会增加开发难度，二是无法保证可靠性，因此目前的互联网公司在使用微服务架构时，都会使用一些成熟的 RPC 框架来用作微服务之间的通信机制。常用的 RPC 框架主要有 Facebook 开源的 thrift RPC 与 Google 开源的 grpc 。

Thrift RPC 是由 Facebook 开发的，后托管到 Apache 软件基金会的一个开源项目。 在实际的生产环境中，使用 Thrift RPC 作为通信机制开发完一个微服务之后，需要先进行本机自测，然后提交到 QA 进行统一测试，然后才开始逐步上线。在自测阶段，通常的解决方法是：对于每一个下游依赖服务，实现出一个服务器，并 mock 出每一个 RPC 调用的返回数据，作为一个测试用例；对于当前微服务，实现一个客户端，用来调用当前服务，并根据是否出错与返回数据对当前微服务进行测试。在自测阶段主要存在两个问题。问题一：是对于每一个微服务，都需要为所有的下游依赖服务实现一个服务器，这一方面增加了开发成本并无法保证可靠性，另一方面由于在同一个系统中两个不同的微服务有很大概率依赖同一个下游服务，所以这实际上会造成重复开发。问题二：由于自测阶段是开发人员自己 mock 出测试数据，因此很难进行测试用例的管理与维护，就会造成测试不够充分的问题，从而丧失了测试原本的意义。

为了解决自测阶段存在的上述问题，本课题基于C/S架构与 Thrift RPC 实现了一个微服务自测平台。这个测试平台要解决的核心用户需求如下：一是通过注册机制像平台注册特定服务的 thrift 服务器或客户端；二是帮助用户进行测试用例的管理与维护。