既然有七种订单类型，这好办啊。可以采用策略+模板模式啊，一个抽象模板+七个子类就可以啦。但是后来仔细一想，如果将所有的处理逻辑都放在父类和子类当中，其实代码整体也显得十分臃肿。
为了想出更好的解决方案，于是对原有代码和业务流程进行了深入的梳理和总结，主要有以下几点：
通过以上分析，是不是可以将下单到确认收货作为一层，将不同订单类型的特定处理实现作为一层呢？这样不就将订单流程中各种特殊处理从订单主流程剥离开了吗，因此最终决定采用三层接口+策略模板的设计方案。
接口设计如下：
包含前端用户进行交互、处理mq消息以及给其它服务调用的接口。
订单核心主流程能力接口。将下单、支付到确认收货等“不变”的基础能力提供给顶层接口调用，这层接口有自主发货流程和客服发货流程两个实现类。
public interface IGameAccountOrderDealProcess { /** * 处理下单未支付订单 */ int handlePlaceOrder(GameAccountOrderContext orderContext) throws Exception; /** * 处理支付成功订单 */ int handlePaySuccessOrder(GameAccountOrderContext orderContext) throws Exception; /** * 处理已发货订单 */ int handleDeliverOrder(GameAccountOrderContext orderContext) throws Exception; /** * 处理支付前取消订单 */ int handleCancelBeforePayOrder(GameAccountOrderContext orderContext) throws Exception; /** * 处理支付后取消订单 */ int handleCancelAfterPayOrder(GameAccountOrderContext orderContext) throws Exception; /** * 处理交易成功订单 */ int handleConfirmReceiptOrder(GameAccountOrderContext orderContext) throws Exception; /** * 账号交易窗数据 */ <T extends TradeFlowData> T getOrderTradeData(String logStr, Long orderId, Integer device, Long uid); /** * 上传账密 */ ZZOpenScfBaseResult<String> uploadAccountAndPwd(GameAccountSelfTrade.AccountPwdArg arg, long uid, String logStr, ServiceHeaderEntity header) throws Exception; /** * 发货 * @param orderContext */ boolean deliverOrder(GameAccountOrderContext orderContext) throws Exception; /** * 订单确认收货 */ ZZOpenScfBaseResult<String> confirmReceiptOrder(GameAccountOrderContext orderContext, Long uid, boolean needCheckRisk) throws Exception;}各种订单类型的特殊处理，每一种订单模式都对应一个实现类。
public interface ITradeSelfHandler { GameAccountTradeFlow.GameAccountTradeType getOrderTrade(); /*------------处理mq消息相关---------------*/ /** *1.插入表之前设置客服和extendInfo */ void fillExtraOrderInfoBeforeInsert(GameAccountOrderResultEntity orderEntity, GameAccountOrderContext orderContext); /** * 下单后处理 */ void handleAfterPlaceOrder(GameAccountOrderContext orderContext); /** * 支付前取消处理 */ void handleCancelBeforePay(GameAccountOrderContext orderContext); /** * 支付后取消处理 */ int handleCancelAfterPay(GameAccountOrderContext orderContext) throws Exception; /** * 支付后一些额外处理 */ int handleAfterPaySuccess(GameAccountOrderContext orderContext); /** * 确认收货处理 */ int handleAfterConfirmReceipt(GameAccountOrderContext orderContext) throws Exception; /*---------------------------------*/ /** * 获取提现时间 */ Date getWithDrawlTime(); /** * 发送支付成功push */ void orderAlreadyPayPushMsgNew(GameAccountOrderContext orderContext, Pair<String, String> jumpUrl); /** * 获取分帐账户、类别信息 */ List<AccountOrderSplitModel> getOrderSplitModelList(GameAccountOrderContext orderContext, OrderMaxSettleInfo settleInfo); /** * 定制各自spiUi */ void buildOrderSpiUiData(GameAccountOrderContext orderContext, GameOrderSpiConfig bConfig, GameOrderSpiConfig sConfig, SpiUiData spiUiData) throws Exception; /** * 确认收货后一些处理 */ void otherOperationAfterReceipt(GameAccountOrderContext orderContext, Long uid);}原先在客服后台、定时任务、mq集群都有一些订单的操作，但是这些代码基本都是重复的，所以此次重构在订单核心服务中新增相应的订单操作功能，统一由其它服务进行RPC调用。
将订单相关的接口、工具类集中到同一个包下，方便定位。
//上下文实体public class GameAccountOrderContext { private String logStr; private Long orderId; private Integer mqStatus; private Order order; private GameAccountOrderResultEntity accountOrderEntity; private AccountOrderStatusEnum orderStatus; private Boolean hasInsuranceService;//订单是否有保险 private GameAccountTradeFlow.GameAccountTradeType tradeType; private GameAccountProductData accountProductData; private ZZProduct product; private ZZProductExt productExt; private Map<String, String> extValueMap; private AccountHelpSaleClue helpSaleClue;//帮卖线索 private DistributionShareInfoDTO distributionShareInfo;//分销信息 private ITradeSelfHandler tradeSelfHandler; private Integer serviceUiStatus;//对应订单spi状态}//上下文准备GameAccountOrderContext orderContext = orderContextBuilder.buildAccountOrderContext(order, zzProduct, logStr);订单流程不管对于什么业务，基本都是最重要的一个环节，为了避免产生重大问题，需要做到以下两点：
根据账号订单流程的特点，在测试的时候遵循以下原则：
对于每一种订单流程，同时进行新、老流程订单的测试。逐一对比新、老流程的买家侧和卖家侧各个流程节点的页面、按钮、跳转、push、私信等是否保持一致。
为了避免产生重大问题，上线后必须采取灰度策略，不然出了问题就可能就是事故了。本次采用的灰度策略是上线后按订单类型、订单量进行灰度，同时将灰度订单落表记录，配置如下：
[ { "orderType": 6,//订单类型 "dayNum": 50,//每日灰度量 "isTotalGray": true//是否全量 }] /** * 判断订单是否走新交易流程 */public boolean isNewOrderProcess(String logStr, GameAccountOrderContext orderContext) { Long orderId = orderContext.getOrderId(); try { if (gameGrayTestService.isNewTradeProcessOrder(orderId)){ return true; } GameAccountOrderResultEntity orderEntity = accountOrderManage.getGameAccountOrderEntity(orderId, logStr); GameAccountTradeFlow.GameAccountTradeType orderTradeType = orderContext.getTradeType(); String orderRedisSet = String.format("account_order_gray_set_%s_%s", Objects.nonNull(orderEntity) ? orderEntity.getSelfType() : orderTradeType.getSelfType(), DateUtil.format(new Date(), "yyyy-MM-dd")); if (ZZGameRedisUtil.sismember(orderRedisSet, orderId.toString())){ return true; } if (newAccountOrderTradeSwitch){ return true; } Optional<OrderGrayConfig> grayConfigOptional = grayConfigList.stream().filter(c->c.getOrderType() == orderTradeType.getSelfType()).findFirst(); if (grayConfigOptional.isPresent()){ OrderGrayConfig grayConfig = grayConfigOptional.get(); if (Objects.nonNull(grayConfig.getIsTotalGray()) && grayConfig.getIsTotalGray()){ return true; } if (orderContext.getOrderStatus() != AccountOrderStatusEnum.place_order){//只处理新订单 return false; } String dayNumKey = String.format(NEW_ORDER_PROCESS_GRAY_NUM, DateUtil.format(new Date(), "yyyy-MM-dd"), orderTradeType.getSelfType()); if (NumberUtils.toInt(ZZGameRedisUtil.get(dayNumKey)) < grayConfig.getDayNum()){ int result = gameGrayTestService.insertNewTradeProcessOrder(orderId); log.info("{} desc=insert_gray_order_data orderId={} result={}", logStr, orderId, result); if (result > 0){ ZZGameRedisUtil.increAndGet(dayNumKey, 1); ZZGameRedisUtil.expire(dayNumKey, 3600*24); ZZGameRedisUtil.sadd(orderRedisSet, orderId.toString()); ZZGameRedisUtil.expire(orderRedisSet, 3600*24); } return result >= 0; } return false; } } catch (Exception e) { log.error("{} desc=isNewOrderProcess_error orderId={}", orderContext.getLogStr(), orderContext.getOrderId(), e); } return false;}在一些重要的节点设置告警机制，比如上传账密、发货、提现等节点出现异常时会发送企业微信告警通知，可以第一时间关闭灰度，查找问题。
不过对于分帐正确性保障这块只是通过测试确保正确，这种最好是可以接入中台的BCP（Business Check Platform）系统。它是一种标准化数据校对平台，支持标准化数据源接入，基于事件触发规则执行，进行业务数据校对，可以及时快速的发现业务异常数据并实时告警。
在对订单流程进行重构之后，新增或修改某种订单模式，只需增改相应的订单类型处理类就可以了，也不用担心本次修改会影响到其它的订单模式，大大提高了开发效率。此外，重构代码可以帮助我们进一步深入了解整个业务流程，发现代码的坏味道，提升代码结构设计能力。
本文链接：http://www.28at.com/showinfo-26-6161-0.html转转游戏的账号订单流程重构之路
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号