专题出品人：孙迁
苏宁云商 IT总部总监
拥有十多年 IT 系统规划及研发工作，其中包括多年互联网平台的建设和研发管理经验。
前期主要负责企业内部内控系统的建设以及包括企业集成总线、短信平台、监控平台、以及基础技术组件的研发工作。
后续负责支撑销售的核心交易系统的研发工作，其中包括购物车、订单、价格、库存、会员、促销、寻源等系统。
在高并发及大数据系统设计、运维及研发管理方面有丰富的经验。
拥有十多年 IT 系统规划及研发工作，其中包括多年互联网平台的建设和研发管理经验。
前期主要负责企业内部内控系统的建设以及包括企业集成总线、短信平台、监控平台、以及基础技术组件的研发工作。
后续负责支撑销售的核心交易系统的研发工作，其中包括购物车、订单、价格、库存、会员、促销、寻源等系统。
在高并发及大数据系统设计、运维及研发管理方面有丰富的经验。
时间：07月08日
地点：大宴会厅1电商的竞争最终是技术的较量，电商是各大热门技术的集大成者，但电商系统架构没有标准模式模板。
电商公司都是在各自发展的过程中逐步摸索和踩坑适合自己业务高速发展的技术和业务架构。
核心架构演进过程中会遇到哪些痛点？让我们听一听主流电商公司系统架构发展过程中的宝贵经验。
库存系统历来是电商平台的心脏，不但要面对高并发的查询场景，更是整条交易链路上资源争抢的核心所在，其性能高低、可用性好坏、扩展性强弱直接决定了电商平台的高性能、高可用、高可扩展性。又因其数据一致要求非常之高，所以设计实现过程中难点非常之多，挑战性很大。
苏宁电商业务又有O2O双线发展、业务场景销售模式繁多、完善的自营模式等等特点，库存业务的复杂性较普通平台式电商要高的多。在此背景下，库存产品线进行了一系列优化升级，近三年来进行了大刀阔斧的架构变革，使库存系统性能、可用性、稳定性实现了质的飞跃，稳定支撑了业务量大幅攀升。
此次分享，以苏宁库存交易系统的架构演进为主线，详细围绕苏宁近10年信息化各阶段中库存遇到的问题及架构改进思路，并介绍库存设计的架构最佳实践。
a. 库存系统定位
b. 核心场景分析
c. 库存业务架构
d. 架构演进概览
a. 总体架构
b. 系统交互
c. 抢购库存架构
a. 单元化设计原则
b. 库存多活设计
物流是电商重要的一环，近几年随着电商爆发式的增长，订单量的成倍增长和客户对物流体验的极致要求对电商物流系统来说都是极大的冲击和考验。
在业务规模的驱动之下，京东物流系统经历了怎样的架构演进之路？面对亿级单量，系统又做了哪些应对高并发的技术升级？
京东物流系统经过多年的技术升级与大促考验，足以支撑亿级单量的顺畅生产，这次分享将聚焦物流系统高并发技术架构，旨在介绍京东物流系统在高并发架构方面的演进过程。
As one of core parts in Walmart eCommerce platform, search system is facing challenges like fast growing number of products, increasing search traffic volume, real time update, and new business needs. To handle these challenges, we continuously improve and redesign the search architecture.
This session will first introduce the architecture of Walmart eCommerce search system, followed by its challenges; then discuss several architecture design cases with focus on the search backend system; finally share experience and lessons we have learned in this evolution.
a. Distributed search cloud (vs. open source Solr Cloud)
b. Re-rank (decouple from underlying search engine)
c. Metadata store (support real time update)
d. Microservices
a. Pros & Cons using open source
b. Chaos by microservices Audiences
为什么我们要做异地多活？简单来说，一是因为双11很火（扩容的需要），二是因为杭州很热（容灾的需要），这两个需求在各个层面都影响着阿里巴巴各项业务的飞速发展。
为了不影响业务的调整发展，阿里巴巴通过“异地多活”技术，将业务封闭在一个个逻辑单元内，然后在多地部署多个这样的逻辑单元，满足了业务对容量和容灾的需求。同时由于有个别业务对“中心单元”有强依赖，我们又通过中心的同城双活解决了容灾问题。
