0%

微服务服务层

简介

服务层依赖于底层平台提供的可靠的运行和抽象通信方案, 通过边界层暴露服务给相应的业务

功能

服务功能的实现分为两类

  • 业务功能: 直接实现了业务目标的服务
  • 技术功能: 通过提供一套共用的技术来支持业务功能的服务
graph TB
  a[业务功能: 管理下单和执行] -->|实现| b{{订单服务}}
  c[技术功能: 与第三方支付系统进行交互并提供支持] -->|实现| d{{支付服务}}
  d -->|支持| b
  d -->|支持| e{{通知服务}}

服务聚合

在微服务应用早期阶段, 多个服务的职责都是处于相似的层次, 服务的结构是相对扁平化的

随着应用的发展, 整个微服务系统会面临着两大压力

  • 从多个服务聚合数据来为客户端的请求提供非规范化的数据
  • 利用底层的功能来提供专门的业务逻辑 (如发布某种特定类型的订单)

随着时间的推移, 整个微服务系统会出现服务层级的分化, 从读写的角度上看可以分为两大类

  • 聚合器 (aggregator): 这类服务一般是靠近系统边界的服务, 并与其他服务交互聚合输出
  • 协调器 (coordinator): 一般是专门定制的服务, 协调下层多个服务的工作
graph LR
  a[客户端] -->|请求| b{{聚合器}}
  b -->|查询| c{{服务 A}}
  b -->|查询| d{{服务 B}}
  b -->|查询| e{{服务 C}}
graph LR
  a[客户端] -->|请求| b{{协调器}}
  b -->|命令| c{{服务 A}}
  b -->|命令| d{{服务 B}}
  b -->|命令| e{{服务 C}}

在出现新的数据需求或者功能需求是, 需要决定是开发一个新服务还是修改已有的服务

  • 创建新服务会增加整体的复杂度并且可能导致服务间的紧耦合
  • 修改现有服务会导致内聚性降低以及难以替换

关键路径与非关键路径

随着服务的规模的不断演进, 有些功能对业务来说越来越重要, 一旦这个服务运行出错, 业务将会被阻断, 相应的, 有些服务的重要性就弱一些, 即使暂时无法使用, 也不会阻碍业务的正常进行

graph LR
  a[下单] -->|实现| b{{订单服务}}
  b --> c{{费用服务}}
  b --> d{{支付服务}}
  b --> e{{库存服务}}
  f[检索商品] -->|实现| g{{商品内容服务}}
  g --> e
  g --> h{{评价服务}}
  c -.- i(下游服务的可靠性会影响上游服务)
  d -.- i
  e -.- j(服务参与到多个路径中)
  k[个人信息] --> l{{用户详情服务}}

可以看到上面的路径的区别

  • 关键路径: 下单, 检索商品
  • 非关键路径: 个人信息

每个服务都不能保证 100% 可靠, 关键路径上的服务越多, 系统出现故障的可能性就越高, 一个服务的可靠性是它本身的可靠性再乘以所依赖的服务的可靠性的乘积

虽然使用微服务会使得服务的可靠性要依赖多个服务的总体可靠性, 但也明确的标识出了关键路径, 可以对它们投入更多资源来保证业务的完整性