什么是微服务？怎么测试？今天一次性讲清楚

01 什么是微服务

Adrian Cockcroft对微服务的表述：loosely couped service oriented architecture with bounded context。

这里涉及两个微服务的概念：

loosely couped：松耦合

松耦合可以引申出其他概念，如各自独立，微服务应该是各自独立的，可以独立开发，独立测试，独立部署，独立运维，如果每个服务都需要同时被更新，那就不是松耦合。服务自理，高度内聚，对外界应该是没有依赖的。

bounded context：有界上下文

业务有界，每个微服务有着明确的业务功能，业务场景。数据有界，每个微服务自身数据不对外界暴露，外界只能通过微服务暴露的接口访问内部数据。

02 优点

隔离性好：

部署A服务时，不会影响B服务的运⾏

易于管理：

⾃动地服务升降级，不会影响整个系统的运⾏状态。监控每个微服务的运⾏状态，及时发出告警

弹性：

系统中一个组件不可用，并没有导致级联故障，系统其他部分可以正常运行

简化部署：

在大型代码仓库中，如果只修改了一小部分，也需要部署整个程序。这样做影响较大，风险也较大。微服务架构中，各服务是彼此独立部署的，如果出问题了，可以快速回滚。便于功能快速发布

03 缺点

多服务运维难度：

可能需要多个人对多个服务进行维护

系统部署依赖：

由于服务间存在调用依赖，因而部署也存在依赖

服务间通信成本：

直接通常是rpc调用，但仍有调用成本

数据一致性保证：

需要保证服务正常工作、异常工作下服务间处理一致

系统需要集成测试 ：

除单个服务外，需要服务集成起来，统一测试

04 CAP理论

衡量系统设计的准则。分布式系统不可能同时满足一致性(consistency)、可用性(availability)、分区容错性(partition tolerance)，最多只能满足两个。因此，任何分布式系统的设计只是在三者中的不同取舍而已。

C：分布式系统所有服务在同一时刻提供同样的业务形态。

A：每个服务都必须能在限定时间内响应请求。

P：即使服务之间丢失数据，服务仍然响应请求。

CAP理论是分布式系统的设计一个重要准则。

详细介绍：http://blog.csdn.net/chen77716/article/details/30635543

举例：

A：业务侧服务和订单平台服务必须都能访问。

P：订单状态同步失败，仍能下单，仍能查看业务的订单列表。

C：订单状态同步（业务侧订单系统和订单中心，订单平台和业务订单）

05 分布式系统的一种容错机制

分布式系统容错一般有两种机制：

重复尝试：

适用于能预知到的短期故障。

断路器模式：

适用于无法预知的突发性故障，无法预估恢复耗时的场景。记录成功和失败请求的数量。如果失效率超过一个阈值，触发断路器使得后续的请求立刻失败。如果大量的请求失败，就可能是这个服务不可用，再发请求也无意义。在一个失效期后，客户端可以再试，如果成功，关闭此断路器。

ps：异常场景应对措施——失败重试，负载均衡，熔断

06 公司级别的服务

具体实现特点：

隔离性一般：

无法做到所有服务彻底隔离。

部署A服务时，可能会影响B服务的运⾏

例如：

服务A挂掉，服务B可以正常运行，但可能真正使用B调用了A的某个接口，导致B无法正常使用

易于管理：

一般公司级别团队专门负责，可以保证监控每个微服务的运⾏状态，及时发出告警

故障预防：

一般有负载均衡，多台机器同时，一台无法提供服务，流量不会进来

简化部署：

各服务是彼此独立部署的；但由于服务间可能有依赖，回滚可能需要同时回滚，但具体看服务实现是否进行了100%向前兼容。

服务实现维护：

不同的服务可能由不同的开发人员维护，需要和多人打交道

07 如何测试？

1、测试要求：

服务独立测试：

功能、数据检查、性能

服务间一致性测试：

正常场景、异常场景

系统集成测试：

功能、数据检查、性能

服务幂等测试：

一个服务、服务之间

2、 具体测试执行，抛开测试外，大致用过两种测试方案：

间接测试：

在每个服务上，提供虚拟的http接口，这样服务测试转换为http接口测试

直接测试：

针对每个服务，专门写一个client进行访问测试

例如，下面是针对多个thrift服务，采用的两种测试方案思路：

---

资源分享

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】