微服务质量保证学习笔记（一）

微服务架构有哪些特点？

 

单体应用下的服务特性

　　每个文件都是一个可执行的文件，包含一个系统的所有功能，这些功能被打包成一体化的文件，几乎没有外部依赖，可以独立部署在装有Linux系统的硬件服务上

　　一个服务中包含了用户交互部分，业务逻辑处理层和数据访问层

 

单体应用架构下，一个服务中，两个业务模块作为该服务的一部分存在同一进程中，它们通过方法调用的方式进行通信

 

微服务架构下的服务特性

每个服务都只负责一小块儿具体的业务功能，能独立地部署到环境中，服务间边界相对清晰，相互间通过轻量级的接口调用或消息队列进行通信，为用户提供最终价值。这样的服务称为微服务（Microservice）。

 

 对比总结：

 

微服务的缺点：

分布式特性：微服务系统通常也是分布式系统，那么在系统容错、网络延迟、分布式事务等方面容易产生各类问题，这也需要投入较多的人力物力去应对。

技术栈多样性：不同的组件选择不同的技术栈，会导致应用程序设计和体系结构不一致的问题，一定程度上也会产生额外的维护成本。

Dev-Ops：微服务架构下需要有一个成熟的 DevOps 团队来处理维护基于微服务的应用程序所涉及的复杂性，同时还需要配备相应的工具。

网络的可靠性：独立运行的微服务使用网络进行交互，这需要可靠且快速的网络连接，同时还需要避免服务间的网络通信存在安全漏洞。

 

从微服务数量规模角度来看。

线上运维方面：更多的服务意味着要投入更多的运维人力和物力，如服务器硬件资源、运行时容器、数据存储和带宽成本、人力维护成本、线上监控成本等。

团队协作成本：微服务之间主要通过接口进行通信，当修改某一个微服务的接口时，所有用到这个接口的微服务都需要进行调整，当核心接口调整时，工作量更为显著。

团队沟通成本：为了确保一个团队的服务发生更新时，不会破坏另一个团队的功能，就需要相关团队进行大量的沟通、确认工作。

 

微服务架构下的质量挑战

架构设计复杂度高；

团队协作难度大：系统依赖性的增加会给团队协作带来更大挑战，这里我所说的协作工作包括但不限于开发、联调、测试等。

1. 复杂的团队沟通：多个团队在使用，服务频繁进行改动或版本升级时，很容易出现跨微服务功能不可用、版本不兼容或延迟实现等问题

2、验证成本高：团队需要等待其他团队，以便完成相关微服务的并行开发；团队需要等待测试环境进行完整的搭建和配置后，方可实现整体联调、测试和验收。

3、反馈周期长：多团队并行开发，微服务由各自团队独立部署，测试环境的不稳定也更容易导致测试执行失败；服务较独立，有些链路很长的时候，定位问题复杂

测试成本高

1、测试环境：

某个微服务出问题时，导致其他服务不可用，谁来负责修复

2、测试技术和工具

微服务架构允许为每种服务使用不同的技术基础，可能导致需要使用不同工具来实现相同的功能，测试培养成本高

3、测试方法

测试对象发生非常多的变化，需要对测试对象进行重新分析

4、测试结果

微服务使用的是分布式系统，数据在网络上传输可能会出现不可避免的网络延时、超时、带宽不足等因素，会导致不稳定的测试结果

主要在：可靠性，数据一致性，关联性等方面