外卖商品业务概览

核心交易流程

供应链流程

业务规模

在线商品数：2.6亿

日新增商品数：160W

在线商品分类数：2200W

日新增商品分类数：12W

在线有图商品数：2.3亿

在线商品图片覆盖率：90%

商品服务峰值QPS：5W

商品服务日调用量：16亿

支撑日订单量：1500W

支撑日交易额：5亿

商品中心架构演进

商品中心架构V1.0

问题

解决之道

商品查询服务和商品管理服务

商品库存服务

商品中心架构V2.0

问题

背景

16年业务持续增长，1000W单；

加大优质供给（大连锁）；

美团专送、快送、众包；

新业务（商超便利、生鲜瓜果、鲜花蛋糕）。

风险点

商品库读写压力过大

各业务方接入商品服务后，商品库写峰值QPS达到1.8K，读峰值QPS将近4W，并不断快速增长。 

商品库单表数据量过大

商品库超过4张表数据量过亿，其中商品SKU表超过1.5亿，容量将近120G。 

商品复杂查询场景变多

商品字段越来越多，各端需要多字段结合查询、分词搜索的业务场景越来越多。分词搜索无法满足，多维查询使用DB勉强满足 、性能差。

解决之道

商品库读

加缓存，构建商品SPU、SKU、TAG缓存，接入Tair双机房。

商品库写/数据量

水平分表，拆出商品SKU、SPU、REL三大集群，各100张分表。

分词搜索/多维查询

引入ElasticSearch，构建商品独立ES集群。

商品中心架构V3.0（当前架构）

服务设计调优之个人心得

高稳定性

大系统小做

化大为小，降低模块间耦合（高内聚低耦合），避免牵一发而动全身；

化繁为简，分而治之，便于开发和快速实现。

柔性可用

快速合理响应，尽可能保证核心流程可用和关键数据的返回，绝不轻易倒下。

过载保护

尽早拒绝，避免雪崩（越早越好，前端保护后端）；

尽力处理，局部可用（有损）。

大系统小做

保持简单：模块职责单一，微服务；版本迭代特性要小，不要想着憋大招。

面向痛点开发：感觉到痛点，才不得不做，避免过度设计。

灰度升级：灰度发布，不断增强信心，避免牵一发而动全身。

柔性可用

核心路径梳理：主要路径与核心元素是什么? 哪些可被自动降级 

服务化、配置化：路径上的元素都拆分成独立服务（核心/非核心），非核心服务的调用端都加上开关（手动/自动），超时时间也是一种自动降级开关 

异步化：部分非核心服务异步化（线程池/MQ）

过载保护

容量监控报警：容量规划（全链路压测），时刻保证一倍余量，达到容量峰值之前（2/3处）提前预警

流控：面向用户的流控（外卖EMS），面向服务的流控（OCTO一键截流）

弹性伸缩：动态扩缩容（HULK弹性伸缩平台）

高性能

代码逻辑：大部分性能问题都是由于代码写的不合理

批量化：读写操作批量化

异步化：非核心逻辑异步化

并发：多线程与分布式，充分利用多核或者集群资源

缓存：本地缓存、分布式缓存

DB：SQL调优，连接池调优，架构调优（垂直、水平拆分）

NoSQL：结合具体业务场景使用性能远超DB