由Spring Cloud 模拟下单流程实现的实战项目

本文通过一个实战项目介绍了如何利用Spring Cloud实现模拟下单流程,涉及Spring Cloud Netflix、分布式事务解决方案Try Confirm Cancel模式以及事件驱动架构。项目中,订单服务与会员服务基于事件驱动进行通信,实现最终一致性。此外,文章还涵盖了系统结构、配置管理、监控服务、业务服务的详细说明,以及服务的启动和测试示例。
摘要由CSDN通过智能技术生成

前言

Spring Cloud为开发者提供了快速构建分布式系统中的一些常见工具,如分布式配置中心,服务发现与注册中心,智能路由,服务熔断及降级,消息总线,分布式追踪的解决方案等。

本次实战以模拟下单流程为背景,结合Spring Cloud Netflix和分布式事务解决方案中Try Confirm Cancel模式与基于事件驱动的服务架构作为实战演示。

开发环境

  • Docker 1.13.1
  • Docker Compose 1.11.1
  • Docker MySQL 5.7.17
  • Docker RabbitMQ 3.6.6
  • Java8 with JCE
  • Spring Cloud Camden.SR6

系统结构

Try Confirm Cancel 补偿模式

本实例遵循的是Atomikos公司对微服务的分布式事务所提出的RESTful TCC解决方案。

RESTful TCC模式分3个阶段执行

  1. Trying阶段主要针对业务系统检测及作出预留资源请求,若预留资源成功,则返回确认资源的链接与过期时间。
  2. Confirm阶段主要是对业务系统的预留资源作出确认,要求TCC服务的提供方要对确认预留资源的接口实现幂等性,若Confirm成功则返回204,资源超时则证明已经被回收且返回404。
  3. Cancel阶段主要是在业务执行错误或者预留资源超时后执行的资源释放操作,Cancel接口是一个可选操作,因为要求TCC服务的提供方实现自动回收的功能,所以即便是不认为进行Cancel,系统也会自动回收资源。

Event Driven Architecture 基于事件驱动架构

本实例中的order-ms与membership-ms之间的通信是基于事件驱动的。当订单被成功创建并且付款成功之后,该订单的部分信息将会发往membership-ms以进行积分的增加。

从系统层面看,order-ms在EDA中是属于Publisher角色,自然而然地membership-ms就是Subscriber。

Publisher中的事件状态转换如下:

  • NEW —> PENDING —> DONE
  • NEW —> PENDING —> FAILED / NO_ROUTE / NOT_FOUND / ERROR


Subscriber中的事件状态转换如下:

    评论 1
    添加红包

    请填写红包祝福语或标题

    红包个数最小为10个

    红包金额最低5元

    当前余额3.43前往充值 >
    需支付:10.00
    成就一亿技术人!
    领取后你会自动成为博主和红包主的粉丝 规则
    hope_wisdom
    发出的红包
    实付
    使用余额支付
    点击重新获取
    扫码支付
    钱包余额 0

    抵扣说明:

    1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
    2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

    余额充值