电商系统架构设计，超大型电商系统架构设计原则与实践

与淘宝、天猫，京东这些平台是基于商城的电商系统相比，集自营模式、商城模式、三方平台于一体的，其商业模式要丰富得多，包括WMS、TMS、OMS的很多部分。国内的中小电商，如果要做系统架构设计，统软云最好的业务架构设计，因为商业模式都差不多。

一.超大型电子商务系统的架构目标

1.搭建超大型电子商务交易平台，兼顾效率和性能，实现高效率、高时效、低成本的目标。

2.成本低，增加服务复用性，提高开发效率，降低人力成本；使用成熟的开源技术，降低软硬件成本；使用虚拟化技术降低服务器成本。

3.可扩展性高，系统架构设计简单清晰，应用系统间耦合度低，易于横向扩展，业务功能添加和修改方便快捷。

4.高可用性和自动化操作和维护。整体系统可用性为99.99%，单个系统可用性为99.999%。全年全系统故障时间小于50分钟，单个系统故障小于5分钟。

二.商城商业建筑设计原则

1.商业平台

业务平台，相互独立。如交易平台、仓储平台、物流平台、支付平台、广告平台等。业务下沉，可复用。如用户、商品、品类、推广、时效等。

2.核心业务与非核心业务分离

电子商务的核心业务与非核心业务分离，核心业务精简(有利于稳定)，非核心业务多元化。例如主交易服务和一般交易服务。

3.区分主流程和辅助流程。

区分哪些是电子商务的主要流程。运行时应优先保证主进程顺利完成，辅助进程可采用后台异步方式。避免辅助进程失败导致主进程回滚。比如下单时同步调用快照，异步通知总账和发票。

4.隔离不同类型的业务

业务是买卖双方签订交易合同，需要优先保证高可用性，让用户快速下单。性能业务对可用性没有太高的要求，可以优先保证一致性。闪购业务对高并发的要求很高，要和普通业务隔离。

三.应用建筑设计原则

1.稳定性原则

专注一切稳定；架构尽量简单明了；不过度设计。

2.耦合/分裂

部分稳定与波动板块分离；核心业务与非核心业务分离；电子商务主流程与辅助流程分离；与应用数据分离；与服务实现细节分开。

3.抽象

app抽象:app只依赖于服务抽象，而不依赖于服务实现细节和位置。

数据库抽象:应用只依赖逻辑数据库，不需要关心物理库的位置和碎片。

服务器抽象:应用虚拟化部署，动态分配资源，无需关心物理机配置。

4.松散耦合。

跨域调用是异步的，不同的业务域尽可能异步耦合。

非核心业务尽量异步，核心和非核心业务尽量异步耦合。

5容错设计。

服务自治:服务可以彼此独立地修改、部署、发布和管理。避免连锁反应。

集群容错:应用系统集群，避免单点故障。

多机房容灾:多机房部署，多活动。

商城应用架构分层

表现层。包括主页、列表页和详细信息页。

业务流程层。商品系统、交易系统、订单系统、财务系统、物流系统等。

服务层，服务构建层，它包括:商品服务、交易服务、订单服务、金融服务和物流服务。

治理方面，包括服务质量层、数据架构层、治理层等。

四.商城应用架构拆分原则

1.横向扩展。即复制的能力，应用系统实现多机集群，提高并发，数据库读写分开，比如商品读和商品写。

2.垂直分割。指不同业务系统的拆分，如商品系统、交易系统等；数据库又分为商品数据库和订单数据库。

3.业务细分。同样的业务应该是碎片化的，比如秒杀系统和常规订单系统，应该是分开的；数据库方面，比如订单表按照ID分为数据库和模块化操作后的表。

4.水平分割。服务水平、功能与非功能分离，稳定业务与多变业务分离；数据库方面，冷热数据分开，历史数据分开。

五.商城服务设计的依赖原则

1.依靠稳定的部分。稳定部分不依赖可变部分，可变部分可以依赖稳定部分，坚决避免循环依赖。

2.跨域弱依赖。当跨业务域调用时，尽可能异步和弱依赖。

3.基于服务依赖。基于服务的服务不能向上依赖流程服务；组合服务和流程服务可以向下依赖基本服务。条件是基础服务要稳定。

4.非功能性服务依赖。非功能性服务不能依赖功能性服务；功能服务可以依赖于非功能服务。条件:非功能服务是稳定的。

5.平台服务依赖。平台不依赖上层应用；上层应用可以依赖平台服务；条件:平台服务稳定。

6.核心服务依赖。核心服务不依赖非核心服务；非核心服务可以依赖核心服务；条件:核心服务稳定。

六.服务设计的基本原则

1.无国籍。状态数据尽量不要保存在本地，接口调用幂等。

2.可重复使用。复用粒度是具有业务逻辑的抽象服务，而不是服务实现细节。服务引用只依赖于服务抽象。

3.松散耦合。跨业务调用和尽可能异步地解耦。当必须同步调用时，设置超时和队列大小。相对稳定的基础服务和可变的流程服务分层。

4.治理。制定服务契约，服务可以降级，服务可以限制，服务可以切换，服务可以监控，白名单机制。

七.商城数据架构的设计原则

1.统一数据视图。确保数据的及时性、一致性、准确性和完整性。

2.数据和应用的分离。app只依赖于逻辑数据库；系统不直接访问其他主机数据库，只能通过服务访问。

3.数据异构。当源数据和目标数据的内容相同时，索引是异构的，例如商品库的不同维度。内容不同，做数据库异构，比如订单买家数据库和卖家数据库。

4.数据读写分离。访问量大的数据库读写分离，数据量大的数据库的子数据库，不同业务域的数据库分区隔离，重要数据的备份。

5.使用Mysql等主流数据库。除了成本因素，Mysql数据库具有很强的扩展能力，积累了很多丰富的运维经验。

6.合理使用缓存。当数据库能够支持时，尽量不要引入缓存。合理利用缓存进行灾难恢复。

八.商城技术架构概述

1.基础平台。数据访问的技术组成部分包括:缓存服务JFS/Jimstore、图像服务JSS、即时服务JDW、索引服务搜索和数据库服务DBS。

2.集成层。服务流程引擎PAF、服务中间件SAF、MQ服务JDMQ、数据库中间件JDAL、调度服务JDWorker、业务规则服务JDRules、配置服务JDCenter和推送服务JMP。

3.质量层。监控服务UMP，日志服务Loghub，风控系统JDriskM，应用管理jdcenter。

4.其他还有治理层、虚拟平台、运营管理等等。

九.京东商城系统运维原则

1.它可以被监控。服务的TPS和RT是否满足SLA，是否出现意外流量。

2.app可以回滚，功能可以降级。当app出现问题时，需要回滚到以前的版本或降级功能。

3.在线扩容。当预期流量超过时，应用系统可以选择在线水平扩展。

4.安全保障。确保系统的保密性和完整性。有足够的抗攻击能力。

5.容错。核心应用需要多个活动，避免单点设计，有自己的容错和修复能力。恢复时间短。

6.故障转移。多机房部署，出现故障可以及时切换。