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


    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服务,采用的两种测试方案思路:


    绵薄之力

    最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走

    ​这些资料,对于想进阶【自动化测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。希望对大家有所帮助…….

  • 相关阅读:
    Lora项目--组网1主机多从机
    Web前端指令符:解码、应用与挑战
    vue3写一个定时器
    MFC中字符串string类型和CString类型互转方法
    leetcode每天5题-Day04
    存在接口CaichangApplet。定义了蔬菜的生长过程
    3.8-镜像的发布
    2024最新gitlab root账号密码重置
    PP-YOLOE: An evolved version of YOLO(2022.12)
    第19节-PhotoShop基础课程-历史记录画笔工具
  • 原文地址:https://blog.csdn.net/jiangjunsss/article/details/127805026