AWS 上的应用架构模式

在 AWS 上部署应用

Dunieski Otano

Amazon Web Services Solutions Architect

认识您的讲师

课程讲师 Dunieski Otano，AWS 解决方案架构师，约十年云端经验

在 AWS 上部署应用

为何选择合适的架构

浅色主题的决策图：一个架构选择节点分支为三要素——耦合、状态、通信；下方是权衡的天平图标

  • 架构是权衡的组合，不是唯一正确答案
    • 三个问题决定每次取舍：
      • 组件有多紧耦合？
      • 状态存在哪里？
      • 通信是同步还是异步？
    • 按工作负载选模式，而非追潮流
在 AWS 上部署应用

周五晚间的级联故障

  • 缓慢的支付 API 会卡住整个结账流程
  • 所有服务都同步等待它
  • 解决之道在于架构，而非更快的 API

对比：紧耦合服务整体停滞 vs 由消息队列解耦后仍可前进

在 AWS 上部署应用

架构选择为何影响部署

对比：脆弱的紧耦合架构中一个失败级联到全部服务 vs 韧性设计用队列缓冲隔离故障，其他服务继续提供服务

  • 所选模式决定应用如何扩展与失效
    • 紧耦合设计在高负载下会崩
  • 合适的模式让部署可预测
    • 同样代码，线上表现却可大相径庭
在 AWS 上部署应用

核心架构模式

  • 单体：一个可部署单元，上手简单
  • 微服务：独立服务，分别部署
  • 事件驱动：组件响应事件而非直接调用
    • 扇出是子模式：一条事件投递给多个消费者

 

三种应用架构并列：单体为单个堆叠块，微服务为独立可部署服务，事件驱动含事件总线，扇出在事件驱动面板内标注为一事件发布到多消费者

在 AWS 上部署应用

有状态 vs 无状态

  • 无状态：请求间不保留客户端数据
    • 任意实例可处理任意请求
  • 有状态：实例记住先前交互
  • 无状态支持横向扩展
    • 将共享状态放到 DynamoDB 或 ElastiCache

左侧为无状态函数实例，可接收任意请求；右侧为绑定到单一会话的有状态实例

在 AWS 上部署应用

紧耦合 vs 松耦合

紧耦合：调用方被慢速被调方阻塞；松耦合：SQS 队列缓冲消息，生产者可继续工作

  • 紧耦合：调用方等待被调方响应
  • 一个慢服务拖垮整条链路
  • 松耦合：服务间加入 Amazon SQS 队列
  • 即便消费者宕机，生产者仍可继续
在 AWS 上部署应用

同步 vs 异步

  • 同步：调用方阻塞等待结果
  • 当调用方需立刻得到答案时使用
  • 异步：交付工作后立即返回
  • 适合慢速、突发或非紧急任务

 

左侧为同步调用：调用方阻塞直至响应返回；右侧为异步移交：立即返回，后台处理

在 AWS 上部署应用

第三方调用的韧性模式

  • 指数退避重试：两次尝试间隔递增
  • 断路器：暂时停止调用故障服务
  • 死信队列：停放多次失败的消息
  • 组合使用；盲目重试会加剧故障

三种韧性模式：指数退避重试曲线、断路器阻断对故障服务的调用、死信队列收集耗尽重试的消息

在 AWS 上部署应用

让我们一起练习吧！

在 AWS 上部署应用

Preparing Video For Download...