非自营商品订单系统从点到面的分析与解决

前几天在与朋友聊他公司的一些技术问题时，碰到一个比较典型的案例，现在拿出来与大家分享一下。

我朋友公司现在在做C端的礼品业务，自己做了一个在线购物的商城，上架了大约4000件商品，每日订单量大概在100笔。但是这些商品并不是自营商品（即库存、定价与物流都不是自已的，都是供应商提供的），这些商品的库存、价格等关键信息都是通过http接口方式从供应商那边获取。

情况是这样，用户在商城内下了一笔订单，订单中包含了多家不同供应商的商品，有可能是京东提供的，有可能天猫提供的，或者其它供应商的。现在要保证客户下单时，这些商品的库存要足够、这些商品的价格要与客户看到的价格一致，而且订单的生成要保持原子性，订单中各个商品要与供应商的商品保持一致性。

问题是，如何让客户下单保持业务的稳定性、性能？他们现在是因为接口调用的问题，商品下了单但库存又没有、售价经常不对，导致下单失败，客户体验非常不好。

首先，如果就从解决这种问题下手，可以做以下这些方案？

提前做好4000件商品的基础信息缓存及同步，比如价格、库存。设定定时任务，每隔10分钟刷新一次4000件商品的信息（这里要根据对方接口允许的并发数及间隔时间作处理）

数据同步器

异步处理简介

为了提高客户的交互体验，设定一个客户下单处理时间的闸值，比如3秒。超过3秒的后端请求，一律先为客户下好订单，但订单的状态是（正在生成订单中），然后由后端服务去请求订单中涉及到的接口，做好回调机制更新此订单。
建立好逆向流程（即保持下单事务的一致性），比如商城下单失败，但接口下单却成功了。此类脏数据，要即时通过逆向服务来解决。
做好各个环节的锚点监测，把各个环节的性能分析出来，之后做性能优化。这块可以用zipkin实现。
做好安全排查，避免业务上、技术上的安全漏洞给系统造成危害

通过这些措施应该能解决掉这个问题，但看问题一定不能看表面，要透过现象看本质。其本质问题还是一个架构的问题。我了解到目前他们的商城还是一个独立应用，并没有按领域进行拆分，这种单一应用很容易出现某个点的问题影响到其它点。

所以架构方面要从以下点出发：

在业务层面理清商城规划，理清商品、会员、订单、库存、物流、优惠打折等领域
根据业务领域用应用层、服务层、能力层、数据库层、服务治理层等进行系统分层，同时做好系统保障（日志、监控）
以SOA分布式系统为设计理念，规划好系统逻辑组件结构，以能支持各个微服务功能适中、对外接口可监控、调用接口可配置、数据全局搜索、缓存、文件服务等
在整个系统部署时要确定好是否使用CDN、F5防火墙、NGINX负载均衡、数据库主从、分布式文件存储等
系统最终是要放在自己的机房中，对于网络及机房管理这块的也不能放松，需要对网络及机房进行严格的监控，要有相关的软件进行机房情况预警，要有相应的应急策略，最终做好系统运维工作。

因为朋友公司的产品正在研发中，涉及到商机，所以在此也没有具体的描述一些架构方案、产品方案及优化过程。如果想了解的话，可以私信我，进行交流与沟通。

本人从事技术工作多年，在市面上选择了一些自己认为非常好用的小软件，小系统，适合初创团队、对口业务直接使用，有需要的可以私信我。同时我自己也积攒了相当的项目管理经验、产品设计经验、技术架构经验，有在这三个方面有困惑的朋友，想寻求解决方案的朋友也可以私信我。