微服务字面上理解一个是微，另一个是服务，用大白话描述就是每个模块负责很小的功能范围视为微，而服务则是通过API的形式向其他模块提供服务
在早期的单体架构中，整个网站都运行在一套服务器集群上，共享计算机所有计算和存储资源，这种架构的优势在于当应对小规模的用户的时候，功能实现相对比较容易，可以快速开发，并且依赖较少，但这种架构没有处理高并发的能力，没有处理大数据量的能力，除非不计成本的整体做负载均衡
到了微服务时代，每个服务都用一个或多个服务实例来承载，对外通过API的方式提供给其他调用者，对内通过服务网关提供统一接口，每个服务通过服务注册将自己注册在服务列表中，并通过服务配置中心来配置服务，在这个架构中每个服务都有自己的进程和数据库，因此在某个服务性能不足的时候便可以单独扩容，从描述中不难看出这种架构的优点，除了灵活高可用外，系统版本发布升级等都有很大的灵活度
在微服务架构设计过程中，服务边界的划分是个关键，理论上可以无限细分服务边界，然每个微服务做足够小的事情，然而这并不是很合理，服务边界的划分需要掌握一个平衡点，太多的微服务会导致一个操作的调用链太长，对排查问题造成很大的麻烦，并且系统的延迟也会变得更大，在单体系统中通过内存通信，相对时间可以忽略不计，但在微服务中，大量使用RESTful或RPC，会导致通信产生的开销过大
测试平台微服务化微服务架构有着非常多的优点，然而并不是适用于任何场景，合适的场景用合适的框架在是正确的选择，例如公司的产品很单一，测试规模便不会很大，并且团队成员有限，那么单体架构的优势反而更大，反之产品复杂多样，测试平台的扩展性和配置能力就会有比较高的要求，以此类推，选择适合的
服务边界划分 测试资源服务:主要用于测试资源的保存、修改及调用，并且能够通过给定的参数进行资源查找测试配置服务:静态配置、动态配置及带逻辑功能的配置，如果将静态配置和动态配置的读取和保存都统一起来，那么便可以将这两者归并为一类，服务可以通过配置的名称来提供配置的新增、修改和保存；带有逻辑功能的配置则可以单独开辟一个微服务来提供测试报告服务:保存和读取测试用例执行的测试报告测试日志服务:保存和读取测试用例执行的测试日志测试用例管理服务:负责管理测试用例，通过扫描测试用例来维护测试用例信息并提供查询测试用例执行服务:给定测试用例或测试列表，执行相应的测试用例最终，这些服务将自己的接口注册在服务网关上，提供外部调用者访问，一般是API Gateway，这样便可以通过服务网关来调用各个微服务提供的接口，并配置相应的服务，从使用者的层面来说，并不会感知微服务的存在，所有的配置都会通过服务网关分发到相应的微服务中，例如测试工程师对测试资源进行了配置，然后将其保存，这个时候可能会调用一个RESTful API将测试资源的信息作为body传递给服务网关，服务网关就会将这个API分发到测试资源微服务中，测试资源微服务对其进行处理后，返回执行结果
微服务之间也可以相互调用，除非人为的设定了界限，例如不允许某些服务之间调用，否则在测试执行的过程中，会调用测试资源微服务，获取测试资源，同样的也会调用测试配置服务，将结果和日志写入测试报告