前言
苏宁售后服务运营能力承诺服务系统（简称“ASAP”）是物流研发中心建设的针对苏宁售后服务的时效承诺管理和服务运营能力管理的核心支撑系统，ASAP 系统经历两年多的线上考验与技术迭代，目前服务着成万级商家，亿级 SKU。
系统定位及核心业务场景分析
首先介绍一下系统的定位，苏宁售后服务运营能力承诺服务系统（ASAP, 下称“系统”），是售后服务能力的“库存系统”，主要为售后服务的服务时效承诺和运营服务能力提供管理，与易购商城及线下门店的商品销售及售后服务履约相关联，系统定位为苏宁易购核心销售链路上的核心服务之一。在商品销售和售后服务履约过程，为消费者、苏宁客服、苏宁自营售后服务商、厂家售后服务商和平台售后服务商提供能力服务支撑，为售后服务能力均匀有序的释放提供了系统支撑，从而保障了售后服务质量。
然后介绍一下系统的主要功能及业务模式，系统主要提供服务承诺和服务能力的实时接口查询，服务能力的实时增加和扣减接口服务。从业务模式上又分为苏宁自营售后服务、厂家售后服务、平台服务商售后服务，其中苏宁自营售后服务是指由苏宁自营的帮客公司提供的售后服务业务，厂家售后服务是指由商品的原厂商（比如海尔、华为）提供的售后服务业务，平台服务商售后服务是指由平台服务商（比如闪修侠）提供的售后服务，针对这三种业务类型，系统提供全面支撑。
系统的特点
库存系统主要面临以下几个挑战：
- 高并发，热点争抢
涉及商品四级页的时效针对同一个商品，比如秒杀、团购、打折促销等活动商品，如何支撑高并发时效能力查询与扣减服务。 - 尽可能减少能力超扣，保证数据一致性。
区别与实物商品库存，售后服务能力主要是为了减小下单环节的依赖，能力控制可以放宽限制，服务的能力异步扣除，允许并发情况的少量超扣，但从服务上要保证扣完后的实际能力与查询能力保持一致性，这是底线原则。 - 系统扩展性
如何建设出可无限扩展的架构，在系统扩展过程中，各部署节点都需要具备无限扩展能力，而常见的瓶颈如数据库的连接数、队列的连接数等。
架构设计目标
应用架构
业务流程：
1）服务商的运营人员针对服务类型进行服务承诺和服务能力的维护
2）消费者在苏宁易购 APP 或是网站上选购商品，打开商品四级详情页，调用 SOLP 进行时效查询
3）SOLP 调用 ASAP 提供的时效查询接口进行查询。
4）消费者完成下单支付，订单由订单中心下发到“售后服务接单管理系统”，由“售后服务接单系统”调用 ASAP 系统进行能力扣减。
5）如后续的售后服务订单有取消或另约服务时间请求，则会调用 ASAP 的能力的回滚接口进行能力回滚。
系统架构
ASAP 架构主要涉及：
1）ASAP 服务：主要提供能力的加减服务包括能力新增和能力扣减接口，
2）ASAP 后台：主要提供系统给运营人员进行承诺和时效服务的
3）中间件：主要涉及分布式服务框架 RSF、任务调度平台 UTS、消息队列 WindQ
4）数据层：主要用到了 Redis 集群，mysql 数据库集群。
5）基础服务：主要依托苏宁的基础 DEVOPS 工具链完成开发和运维工作。
技术框架
开发框架
系统采用苏宁 SNF 技术框架开发，苏宁 SNF 框架基于 MAVEN 项目管理，提供各种的骨架组件。在这些骨架组件中，基本的依赖和基本设置都在模板中做好，无需各项目重复工作。本框架也包括了基本的项目框架结构和各种基本设置，同时也集成了苏宁框架组统一的日志记录、异常捕获、数据访问等苏宁自己的基础组件。
项目组在 SNF 框架的基础上，进行少量的裁剪和扩充就可以进行开发，既能统一项目设置和架构，又能大量节省开发人员搭建框架的时间。
开发环境
STS+Maven+SVN +JDK1.7+JBoss。
分布式服务框架 RSF
系统提供的核心的服务接口均采用苏宁自研的 RSF 框架实现，RSF 框架 解决了分布式系统间的服务调用问题，提供一种透明的、高性能的 RPC 服务调用方案。
主要功能：
- 支持同步、异步 Future、异步 Callback 三种客户端调用模型；
- 支持 TCP 协议及 Hessian、JSON、KRYO 序列化机制；
- 服务节点的自动注册和发现 ;
- 多种负载均衡方式 ;
- 服务路由 ;
- 容错重试机制；
- 流控，熔断等机制；
- 统一的服务配置管理，支持配置的动态修改。
总体架构：
系统面临的挑战及应对
虽然系统采用了 SNF 框架，基于苏宁组件和基础设施，搭建了高并发的分布式架构，但随着苏宁易购电商业务高速发展，订单屡创新高的背景下，系统依然面临一些挑战：
- 扩展痛点：受限于数据库的连接数瓶颈、Redis 服务器的连接数瓶颈等因素，导致应用集群无法无限扩展；
- 机房容灾及机房容量：机房断电，电缆被挖，造成整个苏宁易购交易系统瘫痪；单个机房容量受限，无法创建更多的服务器；
- 热点瓶颈：虽然通过构建缓存化支持能力服务，但单个商品的并发查询和扣减仍然存在上限
为了解决上述问题，我们启用了应用的本机分布式缓式，并在公司规划下正在进行多活架构构建。
应用服务器内存缓存
我们通过 Ehcache 框架，对于一些配置主数据和能力总量在应用服务器进行内存缓存，从生产压测情况来看效果明显，在不新增服务器的条件下 tps 成倍增加，redis 热点消失。
后续也计划对于已约数量等实时能力数据，通过分布式缓存实现共享，以进一步提升单个商品并发查询和扣减的热点瓶颈。
多活架构
目前 ASAP 系统在公司统一部署下实现了多活的支持，在多个机房之间建立数据库和 Redis 缓存数据的准实时同步，支持多个机房间的流量切换，当 A 机房出现故障，可由 B 机房完全接管，具体多活的生产应用还在联调中。
双 11 等大促活动保障
经过两年多的大促实战，基本形成了事前、事中、事后完整的大促保障工作机制，工作项标准化，越来越细致，组织上有专人牵头负责具体工作项事务，形成了完整的闭环。
容量和性能评估
对公司双 11 大促的 活动预告及销售目标进行详细评估和分解，转化成 ASAP 系统的核心服务的 SLA，确定库存系统的核心服务的 TPS 目标。
性能压测达标
大促前，我们会进行多轮的生产压测，最重要的是单系统的接口压测和端到端全链路压测。通过单系统服务接口压测，我们排除接口潜在的性能瓶颈并针对性的优化，能够清楚认识负责系统的单接口所能支持的并发上限；通过生产真实流量回放的端到端全链路压测平台，进行全链路的生产压测，发现真实流量下的系统压力情况，和资源情况，提前发现性能瓶颈和潜在的系统风险。性能测试是大促筹备最为关键的一环。
系统健康体检
提前对系统的各方面进行全面的健康检查，比如 db 磁盘的容量、连接数、topsql，缓存的内存使用率、并发命令数和连接数，消息队列的连接数，各节点的 cpu 负载情况，排除单点故障，排除虚拟机的资源争用问题，排除高可用问题（同一物理机多应用节点）等。
机器扩容
基于容量预估出来的各服务接口的 TPS 目标，根据压测结果评估系统的服务器是否需要扩容，比如 jboss 集群是否需要扩容，redis 集群是否需要扩容，数据库服务器性能是否有足够等。
梳理流控与降级方案
所有服务接口需要设定合理的流控阀值，以确保系统不会挂死；梳理所有接口的调用系统和业务场景并明确业务的优先级，假设系统因为某服务导致性能出现瓶颈，根据业务优先级逐步调整流控阀值；业务流控或系统流控要实现用户的友好提示；对于依赖系统，如果出现超时或宕机，则定义降级策略，确保服务请求的快进快出。
作者：汪成伟，苏宁易购 IT 总部物流研发中心技术总监，目前负责苏宁物流研发中心售后相关系统的架构与开发管理工作，具有十多年互联网一线研发及管理经验。曾负责过 B2C 电商平台、移动新闻资讯平台，用户上网行为分析大数据平台及 O2O 社交应用的研发工作。是 DevOps 的践行者，在企业应用架构设计、高并发系统设计、大促保障、研发过程管理、稳定性治理、安全开发上有丰富的经验。
评论