第三方商城对接架构设计

1 概述

由于业务需要，公司需要将原来的积分兑换商品功能由人工下单改为直接对接第三方商城对接，考虑到以后可能会对接多个第三方商城平台，所以采用统一接口门户调用，不同渠道调用不同实现类的设计方式，方便以后渠道的扩展。整体架构图如下：

第三方商城对接系统本身并不复杂，但是其中的实现细节方面需要注意的方面还是挺多的。比如：商品搜索如何实现，如何保证的库存，如何保证接口的限流，数据如何回滚等等。下面就一些系统实现中遇到的问题一一描述，不妥之处还望大家多多提建议。

2 商品搜索

商品搜索功能可以使用ELK来做，实现思路如下：
1. 晚上定时器从第三方商城拉取商品，更新到ELK。
2. 商品库存有更新时候，第三方商城回调我们的接口更新库存。
但是，这样的话面临一个问题：如果商品数量很多，那么晚上拉取商品时候将会是一个很耗时的操作，如果商品过多，就不能用这种方式来实现。所以这种方式只能适用少量商品的情况。

3 渠道分配器

整个渠道分配器采用工厂模式，思路如下：根据渠道号，工厂类会去渠道池中获取到对应的渠道实现类。

3.1 渠道池枚举类

public enum ShoppingRouteEnum {
JD(1, ShoppingRouteConstant.JD_BEAN_NAME, "京东", false),
YX(2, ShoppingRouteConstant.YX_BEAN_NAME, "严选", true);
private int channel;
private String beanName;
private String name;
private boolean available;
ShoppingRouteEnum(int channel, String beanName, String name, boolean available) {
this.channel = channel;
this.beanName = beanName;
this.name = name;
this.available = available;
}
public int getChannel() {
return channel;
}
public String getBeanName() {
return beanName;
}
public String getName() {
return name;
}
public boolean isAvailable() {
return available;
}
/**
* 获取所有可用的渠道
* @return
*/
public static List<ShoppingRouteEnum> getAllAvailable(){
List<ShoppingRouteEnum> shoppingRouteEnumList = new ArrayList<>();
ShoppingRouteEnum[] values = values();
for(ShoppingRouteEnum shoppingRouteEnum : values){
if(shoppingRouteEnum.isAvailable()){
shoppingRouteEnumList.add(shoppingRouteEnum);
}
}
return shoppingRouteEnumList;
}
/**
* 根据渠道号获取所有可用渠道
* @param channel
* @return
*/
public static ShoppingRouteEnum getAvailableByChannel(int channel){
ShoppingRouteEnum[] values = values();
for(ShoppingRouteEnum shoppingRouteEnum : values){
if(shoppingRouteEnum.getChannel() == channel && shoppingRouteEnum.isAvailable()){
return shoppingRouteEnum;
}
}
return null;
}
}

3.2 渠道工厂类

@Component
public class ShoppingRoute implements ApplicationContextAware{
private ApplicationContext applicationContext;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
/**
* 根据渠道号获取渠道实现类
* @param channel
* @return
*/
public ClientShoppingService getClientShoppingServiceByChannel(int channel){
ShoppingRouteEnum routeEnum = ShoppingRouteEnum.getAvailableByChannel(channel);
if(ObjectUtil.isNotNull(routeEnum) && routeEnum.isAvailable()){
return applicationContext.getBean(routeEnum.getBeanName(), ClientShoppingService.class);
}
return null;
}
/**
* 获取所有可用渠道实现类
* @return
*/
public List<ClientShoppingService> getAllAvailableClientShoppingService(){
List<ClientShoppingService> clientShoppingServiceList = new ArrayList<>();
List<ShoppingRouteEnum> routeEnumList = ShoppingRouteEnum.getAllAvailable();
for(ShoppingRouteEnum shoppingRouteEnum : routeEnumList){
ClientShoppingService clientShoppingService = applicationContext.getBean(shoppingRouteEnum.getBeanName(), ClientShoppingService.class);
if(ObjectUtil.isNotNull(clientShoppingService)){
clientShoppingServiceList.add(clientShoppingService);
}
}
return clientShoppingServiceList;
}
}

4 商品下单

商品下单考虑到需要批量下单以及同第三方商城系统的交互的性能，所以不能同步提交第三方商城下单，这里我采用的解决方案如下：
1. 将订单存储到本地数据库，状态为未提交
2. 定时器1分钟跑批一次提交未提交状态的订单，由于第三方商城接口限流，所以每次只提交按照创建时间排序前若干条的订单。

采用这种解决方案需要考虑这个问题：某个订单一直提交不成功怎么办？

这种情况有大多是以下两种情况造成：（1）订单本身有问题，例如库存不足，商品已经下架等（2）数据库中堆积订单过多，超过第三方商城的限流的承受能力,导致一直轮训不到该订单。

对于这两种情况，暂没有特别好的解决方案，我们可以采取以下措施（1）记录日志（2）人工处理

5 限流器

第三方商城的接口通常都有限流，比如 70次/秒 ，如何保证我们的接口的调用次数在超过第三方接口限流的时候快速失败呢？这时候就需要限流器了。限流器器的实现请参考笔者的另外一篇博客：基于Redis的限流器的实现

6 库存扣减

商家销售的商品数量是有限的，用户下单后商品会被扣减，我们可以怎么实现呢？
举个例子：一件商品有1000个库存，现在有1000个用户，每个用户计划同时购买1000个。

• （实现方案1）如果用户加入购物车时进行库存预占，那么将只能有1个用户将1000个商品加入购物车。
• （实现方案2）如果用户提交订单时进行库存预占，那么将也只能有1个用户将1000个商品提单成功，其它的人均提示“库存不足，提单失败”。
• （实现方案3）如果用户提交订单&支付成功时进行库存预占，那么这1000个人都能生成订单，但是只有1个人可以支付成功，其它的订单均会被自动取消。

我们目前采用的方案2，理由：

• 用户可能只是暂时加入购物车，并不表示用户最终会提单并支付。所以在购物车进行库存校验并预占，会造成其它真正想买的用户不能加入购物车的情况，但是之前加车的用户一直不付款，最终损失的是公司。
• 方案3会造成生成1000个订单，无论是在支付前校验库存还是在支付成功后再检验库存，都会造成用户准备好支付条件后却会出现99.9%的系统取消订单的概率，也就是说会给99.9%的用户体验到不爽的感觉。
• 数据表明用户提交订单不支付的占比是非常小的（相对于加入购物车不购买的行为），目前京东到家给用户预留的最长支付时间是30分钟，超过30分钟订单自动取消，预占的库存自动释放

综上所述，方案2也可能由于用户下单预占库存但最终未支付，造成库存30分钟后才能被其它用户使用的情况，但是相较于方案1，方案3无疑是折中的最好方案。

7 重复提交订单的问题

重复提交订单造成的库存重复扣减的后果是比较严重的。比如商家设置有1000件商品，而实际情况可能卖了900件就提示用户无货了，给商家造成无形的损失

7.1 可能出现重复提交订单的情况

• （1、用户善意行为）app上用户单击“提交订单”按钮后由于后端接口没有返回，用户以为没有操作成功会再次单击“提交订单”按钮
• （2、用户恶意行为）黑客直接刷提单接口，绕过App端防重提交功能
• （3、提单系统重试）比如提单系统为了提高系统的可用性，在第一次调用库存系统扣减接口超时后会重试再次提交扣减请求

7.2 解决方案

• （1、用户善意行为）app侧在用户第一次单击“提交订单”按钮后对按钮进行置灰，禁止再次提交订单
• （2、用户恶意行为）采用令牌机制，用户每次进入结算页，提单系统会颁发一个令牌ID（全局唯一），当用户点击“提交订单”按钮时发起的网络请求中会带上这个令牌ID,这个时候提单系统会优先进行令牌ID验证，令牌ID存在&令牌ID访问次数=1的话才会放行处理后续逻辑，否则直接返回
• （3、提单系统重试）这种情况则需要后端系统（比如库存系统）来保证接口的幂等性，每次调用库存系统时均带上订单号，库存系统会基于订单号增加一个分布式事务锁。（分布式锁可以参考笔者的另一篇博客：redis分布式锁的实现）

8 库存数据的回滚机制如何做

需要库存回滚的场景也是比较多的，比如：

• （1、用户未支付）用户下单后后悔了
• （2、用户支付后取消）用户下单&支付后后悔了
• （3、风控取消）风控识别到异常行为，强制取消订单
• （4、耦合系统故障）比如提交订单时提单系统T1同时会调用积分扣减系统X1、库存扣减系统X2、优惠券系统X3，假如X1,X2成功后，调用X3失败，需要回滚用户积分与商家库存。

这几种情况我们可以采取以下解决方案：

• 其中场景1，2，3比较类似，都会造成订单取消，订单中心取消后会发送mq出来，各个系统保证自己能够正确消费订单取消MQ即可。
• 场景4订单其实尚未生成，相对来说要复杂些，这种情况提单系统T1需要主动发起库存系统X2、优惠券系统X3的回滚请求（入参必须带上订单号），X2、X3回滚接口需要支持幂等性。
• 场景4还存在一种极端情况，如果提单系统T1准备回滚时自身也宕机了，那么库存系统X2、优惠券系统X3就必须依靠自己为完成回滚操作了，也就是说具备自我数据健康检查的能力，具体来说怎么实现呢？可以利用当前订单号所属的订单尚未生成的特点，可以通过worker机制，每次捞取40分钟（这里的40一定要大于容忍用户的支付时间）前的订单，调用订单中心查询订单的状态，确保不是已取消的，否则进行自我数据的回滚。

9 多人同时购买1件商品，如何安全地库存扣减

现实中同一件商品可能会出现多人同时购买的情况，我们可以如何做到并发安全呢？
基于数据库的伪代码实现：

int ret=updateSQL("update stock_main set stockNum=stockNum-"+requestBuyNum +" where productId="+productId+" and stockNum>="+requestBuyNum );
if(ret==1){
return "扣减成功";
}else {
return "扣减失败";
}

这段代码只是在where条件里增加了and stockNum>=”+requestBuyNum即可防止超卖的行为

使用缓存校验减轻数据库压力:

如果商品是促销品（比如参与了秒杀的商品）并发扣减的机率会更高，那么数据库的压力会更高，这个时候我们可以采用redis缓存进行校验来减少数据库压力。

最后

以上就是喜悦红酒为你收集整理的第三方商城对接架构设计的全部内容，希望文章能够帮你解决第三方商城对接架构设计所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。