本文介绍了微服务的概念，探讨了微服务出现的原因，分析了微服务的优缺点，并着重讨论了微服务对产品测试的影响。在微服务架构下，接口测试、集成测试、故障测试和自动化测试的重要性提升，同时对测试人员的技术要求也更高，要求掌握自动化测试和理解微服务技术体系。
微服务正在如火如荼中，有些公司已开始对现有产品改造或新产品走微服务架构。作为一名测试人员，需要跟上微服务的步伐，对微服务进行学习了解，微服务架构下产品要怎么测试等。
此刻脑海里想到要学习了解的问题：
微服务是什么？
微服务为什么出现？
微服务的优缺点是什么？
微服务产品，怎么开始测试？对测试带来变革是怎样的？
带着这些问题，开启学习，先百度百度一些相关的学习文章........
微服务是什么？
微服务英文：Microservice，是一种架构设计风格模式。
图片来于百度图片(在哪些文章上看到过，不记文章来源，只好在百度图片上搜索到了）
微服务=微+服务，从“微”和“服务”两个方面入手，初步了解微服务。微：字面含义是指细小，精细，简单地说就是将产品划分为更小，更准确地说指软件产品划分出一个个用户可以感知（具有业务场景）最小功能集。服务：即指这个“微”能够提供服务，这个服务是在其独立进程中工作，每个服务之间采用轻量级通信机制（微服务通信机制_勤奋的小猪-CSDN博客_轻量级通信机制， 题外话：常用的是HTTP协议的RESTful API，可参考文章：RESTful 架构详解 | 菜鸟教程进一步详细了解），每个服务都围绕着具体的业务进行构建，并且能够被独立部署到生产环境、预生产环境（开发环境、测试环境、预发布环境、生产环境的区别 - 简书）。
微服务为什么出现？
简单来说：就是现在软件产品规模越来越大和需要持续快速地响应市场需求的变化，现有的单体应用架构呈现的缺点越来越明显，已不再能很好地满足当前软件开发。
单体应用架构特点：应用程序的全部功能被一起打包作为单个单元或应用程序，这个单元可以是JAR、WAR、EAR,或其他一些归档格式,但其全部集成在一个单一的单元。（可能现在做到比较多的是前后端分离，前端一个应用程序包，后端一个应用程序包）
单体应用架构缺点：
1.系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动，重启周期边长；
2.系统错误隔离性差，可用性差，任何一个模块的错误可能导致整个系统的宕机；
3.可伸缩性差，系统的扩容只能对整个应用扩容，不能做到对整个功能点进行扩容；
4.线上问题修复时间长，任何一个线上问题修复需要对整个应用系统进行全面升级；
微服务的优缺点是什么？
微服务特点：微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。（百科解释）
微服务优点：
1.易于开发和维护：一个服务只关注一个特定的业务功能，所以它业务清晰，代码量少。开发和维护单个微服务相当简单。而整个应用是若干个微服务构建而成的，所以整个应用在被维持在一个可控的状态；
2.单个服务启动快：单个服务代码量少，所以启动快；
3.局部修改易部署：单个应用只要有修改，就得重新部署整个应用，微服务解决了这个问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可；
4.技术栈不受限：在微服务架构中，可以结合业务和团队的特点,合理选用技术栈。例如有些服务可以使用关系型数据库Mysql，有的服务可以使用非关系型数据库redis。甚至可根据需求，部分服务使用JAVA开发，部分微服务使用Node.js开发
5.按需收缩：可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，可以结合微服务的特点，增加内存，升级CPU或增加节点。
微服务的缺点：
1.运维要求高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的运行即可，在微服务中，需要保证几十甚至几百个服务器正常运行和协作，这给运维带来了巨大的挑战；
2.分户式固有的复杂性：使用微服务架构的是分布式系统。对于一个分布式系统，系统容错，网络延迟都会带来巨大挑战。
3.接口调整成本高：微服务之间通过接口进行通信
本文中单体应用架构和微服务优缺点转载为CSDN博主「Bewhatyouwanttobe」的原创文章
原文链接：单体架构和微服务架构的优缺点_ToBeWhatYouWant-CSDN博客_微服务架构的优缺点
微服务产品，怎么开始测试？对测试带来变革是怎样的？
学习到这里，对微服务有了一定的初步认识，微服务带来产品测试变化，个人觉得有以下几点：
带来变化，应该从2个方面：一个是对测试技术，测试策略带来变化；二是对测试人员变化；
测试技术：
（1）接口测试重要性：微服务较单体架构应用会有更多的服务个体，服务之边接口调用更多了，那涉及到各个服务之间接口测试就更重要了。
（2）集成测试重要性：正是由于微服务划分为多个服务组件，服务之间配合如何显得尤为重要了。
（3）宕机故障性测试重要性：某个功能不再是只有一个服务，而会有多个服务，这种多服务下某个服务挂掉出现故障后，对其它服务的影响，剩下正常服务的正常工作等场景测试。
（4）自动化测试重要性：微服务和DevOps均是以快速响应用户需求，势必开发周期快速缩短，测试周期和频率势必要提升从而才能匹配开发效率，这样传统的手工测试势必要向自动化测试倾斜，如接口自动化，UI自动化测试等。
测试人员：对测试人员要求越来越高
（1）要求掌握自动化（接口、UI）
（2）测试人员技术更新，要学会了解和掌握这些微服务的技术体系，新DevOps开发模式，CICD可持续集成，可持续发布等。
下面来看看其它一些大牛们对微服务测试这块：
在微服务架构下，给我们测试带来了如下挑战：
- 验证成本高，为了验证多个服务协作后的功能正确与否，需要为每个服务搭建基础设施（包括数据库、缓存等），并执行部署、配置等步骤，以确保服务能正确运行。
- 结果不稳定， 分布式系统，服务之间的通信都是通过网络调用，然而在网络上传送，都会面临
网络延时、超时、带宽等因素，容易导致不稳定的测试结果。 - 反馈周期长， 相比单体应用而言，微服务架构下，可独立部署的单元多，因此集成测试的反馈周期比之前会更长，定位问题的时间就会更久。
- 沟通成本高， 微服务常由不同团队开发并维护，当服务频繁进行改动和版本升级的时候，很容易导致不兼容，加大团队之间的沟通成本。
本文中该处挑战内容来源于原创文章链接：https://www.jianshu.com/p/847262220784
主要是三个变化挑战：
（1）自动化：测试任务的增加，要求测试人员必须把主要的精力用于将测试自动化，摆脱手动测试带来的沉重负担。当然，自动化测试必须足够稳定、稳健，不能动辄误报，否则反而会导致很高的维护成本。
（2）层次化：这意味着采用分层次的测试方法，粒度由细到粗，范围由小到大。
（3）可视化：为了降低交流成本，最好的办法就是让所有的测试结果可视化。这意味着将构建（Build）、测试（Test）、部署（Deploy）所有这些相关任务构建在一个流水线之中，让所有团队成员都可以随时监控项目进度，找到阻碍项目的瓶颈。
此处三个变化挑战的原文链接：https://blog.csdn.net/weixin_41978708/article/details/80025231
扫一扫
939
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
