搭建微服务架构的电商平台系统

Posted 2023-04-02 爱埋珊瑚海～～

业务介绍

基于传统电商业务搭建一套线上商城平台，主要涉及到三个角色分为平台、供应商、普通会员用户；

• 平台审核注册的供应商、审核供应商发布的商品、定义全平台商品促销活动等功能
• 供应商新建商品、发布商品、上架下架商品、定义促销活动等
• 终端用户在商城搜索热门商品，加购商品，提交订单，订单支付，订单退款退货等

技术架构

本文主要基于目前主流的容器化微服务部署架构进行介绍，如下图所示：

• 整体架构采用前后端分离的架构，前端分为会员侧的商城端网站（shopping-web）和平台侧的后台管理网站(operation-web)，前者主要为普通会员提供商城的商品购买整个下单服务，后者主要为平台侧用户或供应商侧用户进行商品、促销活动的管理功能。

• 前端请求后端业务接口通过一个统一的网关服务（gateway-service）进行路由转发，目的是方便权限控制和统一路由管理。

• 具体的业务服务会对接第三方平台服务，比如对接第三方支付、短信服务等等

如上图所示，后端服务拆分如下：
gateway-service:后端网关服务, 负责接收前端的统一请求，然后将请求分发到具体的服务
home-service:首页服务，负责提高首页需要的数据，主要偏查询和免登录服务
es-service：elasticsearch服务，负责查询和存储商品的数据
opertion-service: 后台运维服务，负责管理后台功能对应的接口对接
cart-service: 购物车服务，负责购物车查询，添加，删除等操作
order-service: 订单服务，提供提交订单，查询订单等订单相关操作
pay-service: 支付服务，提供对接第三方支付渠道的服务
promotion-service: 促销活动服务，提供促销活动管理相关操作
category-service: 类目服务，提供产品类目管理
product-servicce: 产品服务，提供产品新建、发布、上下架操作
member-service: 会员服务，提供会员注册、注销、登录、查询等操作
supplier-service: 供应商服务，提供供应商注册、注销、登录、查询等操作
message-service:消息服务，提供消息存储，消息查询，消息状态管理等操作
upload-service:上传下载服务，提供文件上传下载操作
metadata-service: 元数据服务，提供基础数据的配置管理操作

技术选型

• 微服务实现框架采用SpringBoot+SpringCloud
• 数据库采用 mysql MHA 方案
• 涉及分布式缓存 采用 Redis+Sentinel 方案
• 商品分词搜索查询 采用Elasticsearch
• 容器编排 采用kubernetes双集群方案（后台服务一套集群、前端应用一套集群）
• 容器集群暴露pod的方式以ingress 方式，具体实现可以用nginx或者公有云服务商提供的负载均衡器（AWS的ALB，阿里云的SLB,腾讯云的CLB）
• 提供给公网访问的网站地址可以采用公有云服务商提供的DNS服务器进行域名解析

微服务架构的分布式事务解决方案

分布式系统架构中，分布式事务问题是一个绕不过去的挑战。而微服务架构的流行，让分布式事问题日益突出！

下面我们以电商购物支付流程中，在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析！

如上图所示，假设三大参与平台（电商平台、支付平台、银行）的系统都做了分布式系统架构拆分，按上数中的流程步骤进行分析：

1、电商平台中创建订单：预留库存、预扣减积分、锁定优惠券，此时电商平台内各服务间会有分布式事务问题，因为此时已经要跨多个内部服务修改数据；

2、支付平台中创建支付订单（选银行卡支付）：查询账户、查询限制规则，符合条件的就创建支付订单并跳转银行，此时不会有分布式事务问题，因为还不会跨服务改数据；

3、银行平台中创建交易订单：查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台，此时也会有分布式事务问题（如果是服务化架构的话）；

4、支付平台收到银行扣款结果：更改订单状态、给账户加款、给积分帐户增加积分、生成会计分录、通知电商平台等，此时也会有分布式事务问题；

5、电商平台收到支付平台的支付结果：更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等，系统内部各服务间调用也会遇到分布式事问题；

 

如上图，支付平台收到银行扣款结果后的内部处理流程：

1、支付平台的支付网关对银行通知结果进行校验，然后调用支付订单服务执行支付订单处理；

2、支付订单服务根据银行扣款结果更改支付订单状态；

3、调用资金账户服务给电商平台的商户账户加款（实际过程中可能还会有各种的成本计费；如果是余额支付，还可能是同时从用户账户扣款，给商户账户加款）；

4、调用积分服务给用户积分账户增加积分；

5、调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录；

6、调用通知服务将支付处理结果通知电商平台；

 

如上图，把支付系统中的银行扣款成功回调处理流程提取出来，对应的分布式事务问题的代码场景：

/** 支付订单处理 **/

@Transactional(rollbackFor = Exception.class)

public void completeOrder() {

  orderDao.update();  // 订单服务本地更新订单状态

  accountService.update();  // 调用资金账户服务给资金帐户加款

  pointService.update();  // 调用积分服务给积分帐户增加积分

  accountingService.insert();  // 调用会计服务向会计系统写入会计原始凭证

  merchantNotifyService.notify();  // 调用商户通知服务向商户发送支付结果通知

}

 

本地事务控制还可行吗？

 

以上分布式事务问题，需要多种分布式事务解决方案来进行处理。

 

订单处理：本地事务

 

资金账户加款、积分账户增加积分：TCC型事务（或两阶段提交型事务），实时性要求比较高，数据必须可靠。

 

会计记账：异步确保型事务（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）

 

商户通知：最大努力通知型事务（按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对）

针对上以分布式事务问题,建议可以参考龙果学院（http://www.roncoo.com）的《微服务架构的分布式事务解决方案》教程中将提供详细完整的解决方案