微服务字面上理解一个是微，另一个是服务，用大白话描述就是每个模块负责很小的功能范围视为微，而服务则是通过API的形式向其他模块提供服务

      在早期的单体架构中，整个网站都运行在一套服务器集群上，共享计算机所有计算和存储资源，这种架构的优势在于当应对小规模的用户的时候，功能实现相对比较容易，可以快速开发，并且依赖较少，但这种架构没有处理高并发的能力，没有处理大数据量的能力，除非不计成本的整体做负载均衡

      到了微服务时代，每个服务都用一个或多个服务实例来承载，对外通过API的方式提供给其他调用者，对内通过服务网关提供统一接口，每个服务通过服务注册将自己注册在服务列表中，并通过服务配置中心来配置服务，在这个架构中每个服务都有自己的进程和数据库，因此在某个服务性能不足的时候便可以单独扩容，从描述中不难看出这种架构的优点，除了灵活高可用外，系统版本发布升级等都有很大的灵活度

      在微服务架构设计过程中，服务边界的划分是个关键，理论上可以无限细分服务边界，然每个微服务做足够小的事情，然而这并不是很合理，服务边界的划分需要掌握一个平衡点，太多的微服务会导致一个操作的调用链太长，对排查问题造成很大的麻烦，并且系统的延迟也会变得更大，在单体系统中通过内存通信，相对时间可以忽略不计，但在微服务中，大量使用RESTful或RPC，会导致通信产生的开销过大

测试平台微服务化

      微服务架构有着非常多的优点，然而并不是适用于任何场景，合适的场景用合适的框架在是正确的选择，例如公司的产品很单一，测试规模便不会很大，并且团队成员有限，那么单体架构的优势反而更大，反之产品复杂多样，测试平台的扩展性和配置能力就会有比较高的要求，以此类推，选择适合的

服务边界划分

• 测试资源服务:主要用于测试资源的保存、修改及调用，并且能够通过给定的参数进行资源查找

• 测试配置服务:静态配置、动态配置及带逻辑功能的配置，如果将静态配置和动态配置的读取和保存都统一起来，那么便可以将这两者归并为一类，服务可以通过配置的名称来提供配置的新增、修改和保存；带有逻辑功能的配置则可以单独开辟一个微服务来提供

• 测试报告服务:保存和读取测试用例执行的测试报告

• 测试日志服务:保存和读取测试用例执行的测试日志

• 测试用例管理服务:负责管理测试用例，通过扫描测试用例来维护测试用例信息并提供查询

• 测试用例执行服务:给定测试用例或测试列表，执行相应的测试用例

      最终，这些服务将自己的接口注册在服务网关上，提供外部调用者访问，一般是API Gateway，这样便可以通过服务网关来调用各个微服务提供的接口，并配置相应的服务，从使用者的层面来说，并不会感知微服务的存在，所有的配置都会通过服务网关分发到相应的微服务中，例如测试工程师对测试资源进行了配置，然后将其保存，这个时候可能会调用一个RESTful API将测试资源的信息作为body传递给服务网关，服务网关就会将这个API分发到测试资源微服务中，测试资源微服务对其进行处理后，返回执行结果

      微服务之间也可以相互调用，除非人为的设定了界限，例如不允许某些服务之间调用，否则在测试执行的过程中，会调用测试资源微服务，获取测试资源，同样的也会调用测试配置服务，将结果和日志写入测试报告

作者：Davieyang.D.Y

原文链接：https://davieyang.blog.csdn.net/article/details/107873854