vivo官方商城经过了七年的迭代，从单体架构逐步演进到微服务架构，我们的开发团队沉淀了许多宝贵的技术与经验，对电商领域业务也有相当深刻的理解。

去年初，团队承接了O2O商城的建设任务，还有即将成立的礼品中台，以及官方商城的线上购买线下门店送货需求，都需要搭建底层的商品、交易和库存能力。

为节约研发与运维成本，避免重复造轮子，我们决定采用平台化的思想来搭建底层系统，以通用能力灵活支撑上层业务的个性化需求。

包括交易平台、商品平台、库存平台、营销平台在内的一整套电商平台化系统应运而生。

通过上面的映射关系，可以为每个租户灵活分配存储资源，数据量很小的租户还能复用已有的库表。

示例一：

示例三：

答案是，当库数量和表数量存在公因数时，会存在倾斜问题，先除以表数量就能剔除公因数。

以2库4表为例，对4取模等于1的数，对2取模也一定等于1，因此0号库的1号表中不会有任何数据，同理，0号库的3号表、1号库的0号表、1号库的2号表中都不会有数据。

问题：分库分表后，数据库自增主键不再全局唯一，不能作为订单号来使用。且很多内部系统间的交互接口只有订单号，没有用户标识这个分片键。

方案：如下图所示，参考雪花算法来生成全局唯一订单号，同时将库表编号隐含在其中（两个5bit分别存储库表编号），这样就能在没有用户标识的场景下，从订单号中获取库表编号。

问题：管理后台需要根据各种筛选条件，分页查询所有满足条件的订单。

方案：将订单数据冗余存储一份到搜索引擎Elasticsearch中，满足各种场景下的快速灵活查询需求。

比如订单创建和取消时对库存和优惠券系统的调用，如果不能保证强一致，可能导致库存超卖或优惠券重复使用。

对于强一致性场景，我们采用Seata的AT模式来处理，下面的示意图取自seata官方文档。

比如支付成功后通知发货系统发货，确认收货后通知积分系统发放积分，只要保证能够通知成功即可，不需要同时成功同时失败。

对于最终一致性场景，我们采用的是本地消息表方案：在本地事务中将要执行的异步操作记录在消息表中，如果执行失败，可以通过定时任务来补偿。

• 熔断
  

使用Hystrix组件，对依赖的外部系统添加熔断保护，防止某个系统故障的影响扩大到整个分布式系统中。

• 幂等性
  

所有接口均具备幂等性，上游调用我们接口如果出现超时之类的异常，可以放心重试。

• 网络隔离

只有极少数第三方接口可通过外网访问，且都有白名单、数据加密、签名验证等保护，内部系统交互使用内网域名和RPC接口。

• 监控和告警

通过配置日志平台的错误日志报警、调用链的服务分析告警，再加上公司各中间件和基础组件的监控告警功能，让我们能够能够第一时间发现系统异常。

• 是否用领域驱动设计

考虑到团队非敏捷型组织架构，又缺少领域专家，因此没有采用

• 高峰期性能瓶颈问题

大促和推广期间，特别是爆款抢购时的流量可能会触发限流，导致部分用户被拒之门外。因为无法准确预估流量，难以提前扩容。

可以通过主动降级方案增加并发量，比如同步入库切为异步入库、db查询转为cache查询、只能查到最近半年的订单等。

考虑到业务复杂度和数据量级还处在初期，团队规模也难以支撑，这些设计有远期计划，但暂时还没做。（架构的合适性原则，杀鸡用牛刀，你愿意也行）。

我们在设计系统时并没有一味追求前沿技术和思想，面对问题时也不是直接采用业界主流的解决方案，而是根据团队和系统的实际状况来选取最合适的办法。好的系统不是在一开始就被大牛设计出来的，而是随着业务的发展和演进逐渐被迭代出来的。

目前交易平台已上线一年多，接入了三个业务方，系统运行平稳，公司内有交易/商品/库存等需求的新业务，以及存量业务在遇到系统瓶颈需要升级时，都可以复用这块能力。

上游业务方数量的增加和版本的迭代，对平台系统的需求源源不断，平台的功能得到逐渐完善，架构也在不断演进，我们正在将履约模块从交易平台中剥离出来，进一步解耦，为业务持续发展做好储备。