苏宁11.11：双十一大促的实践之路

双十一 电商

“平京战役”一发布使本来就热闹的电商促销大战呛出了火药味，也为双11的大促增添了许多谈资，更让消费者享受到实实在在的优惠。而在技术上这种竞争则温和许多。

技术上的压力来源于业务的需求。苏宁阿里战略合作后，易购赢得了社会的广泛关注，系统的流量在苏宁的传统促销节8.18就显现出来了；加上苏宁的双11销售目标，使得我们系统承担的压力非常大。技术上的准备不是一蹴而就的，尤其像易购这样的大系统，更需要长期的积累和演变。经过了历年的大促，目前苏宁在技术线上的准备变得也非常清晰和严谨。

一、系统拆分

目前苏宁易购在线业务有大大小小几百个系统，很多系统都进入了万级的tps，基础平台则有几十万的tps，而且做到了水平扩展。这些都是不断拆分和重构的结果，几年以前则是另一番景象。

以前的苏宁易购主站都在基于IBM的Commerce开发的B2C平台上。 为了方便扩容，线上独立部署了10套这样的系统，用户浏览时会根据用户ID选择其中的一个系统。这个系统非常庞大，它包含了所有的业务代码、单个包超过400MB、启动时间需要15分钟、部署这样的系统需要一个多小时。每当大促来的时候，秒杀、抢购和正常的交易蜂拥而至，宕机就在所难免了。驾驭庞大的系统意味着高超的能力，要理清各种逻辑关系对几个牛人还可以，但是对普通工程师而言变相当有难度。修改频繁地出错，那种牵一发而动全身的痛，使得工程师对业务的变更畏手畏脚。大促中的几次宕机、新业务难以在老系统上扩展, 这些原因促使我们走上了系统拆分的道路。

进行系统拆分是需要充分准备的，没有一个合理的规划只会让系统的职责扯不断，理还乱，外加各种抱怨。系统拆分要分析主流程，分离主干系统和枝叶系统，把主干系统根据业务的内聚性独立出来，做到分别部署。我们分析了电商主要功能和重运营的特点。根据业务功能进行系统拆分，我们拆分几大核心系统：会员、商品、库存、价格、购物车、交易、订单、物流、内容管理等，并且组建了对应的研发中心来维护。根据交易环节系统的压力，独立了抢购和秒杀系统、拆分了购物券、云钻等销售系统，并组建了营销中心。

系统职责明确了，可以独立发布，响应新业务。系统变小了，新人只要关注很少的逻辑就能上手，专注度高了更能深入了解和优化系统。
二、 基础平台
系统拆分只是把系统的职责理顺了，还面临着系统之间的通讯问题和各个系统重复造轮子的问题。针对这些问题，苏宁成立了基础研发中心。基础研发中心属于一级中心，这也显示了苏宁对基础研发的重视。

苏宁的基础平台主要集中解决了基础架构方面包括自建CDN、云计算和云存储，通用系统方面短信、邮件、验证等系统，系统集成包方面括系统之间的通讯、统一验证和内部管理系统的统一权限，中间件方面包括session共享、分布式调用链、redis分片存储、数据库的分库分表中间件、统一配置管理和流控，运维监控平台，持续集成平台，针对安全的风控系统，针对业务的大数据分析。因为内容繁多，这里选择其中几个做简要介绍。

云计算平台、云存储平台已经成为互联网的标配。云计算平台提供了KVM到现在Docker化的中间件服务，部署着苏宁大量的系统。云存储存有文件存储和对象存储两种方式，支撑着苏宁的海量存储需求。
苏宁内部通信方式主要有两套系统：MYESB和RSF。

MYESB是一个安全的集中消息转发服务系统，提供了同步和异步两种服务接口，同步基于http+xml，异步基于MQ。RSF类似阿里的Dubbo，提供远程调用的机制，支持http和tcp通讯服务。它的优点是不需要统一的代理，能直接调用服务方，减少了系统延迟。

RSF的tcp通讯是长链，减少了网络开销。由于历史的原因苏宁有很多异构的系统，这些系统通常需要MYESB来解决异构环境通信问题。一般系统内部都是用RSF作为通信方式。

持续交付平台主要包括了代码基础框架自动生成、代码质量分析、代码的自动化部署、代码权限管理。有了上面的准备，构建一个系统就变得容易起来了。

监控是系统的眼睛，尤其是针对线上的系统。通过监控能确切的知道系统现在的运行状态，出了问题也能知道系统发生了什么。实时监控分析的纬度有局限性，很多监控数据需要做一些定制统计和分析，这需要离线来的监控分析系统。苏宁的监控平台包括了对硬件资源和操作系统和中间件以及系统的监控。目前监控的手段基本都是定时采样、日志收集分析、及时消息触发。日志收集分析在苏宁有了较大的发展， 目前日志系统有多个，实际日志系统，偏向分析的LogMonitor系统统，针对移动端的监控系统。实时日志分析系统是基于ELK技术, 可以实时监测请求情况、错误定位、多维度查询；LogMonitor统计分析接口时间处理时间、历史性能对比；新上线的，CloudyTrace更好地识别tp90、tp99等更高级的功能。

目前苏宁自建的CDN服务承担的流量占总流量的1/3。当流量比较大的时候，自身的业务会受到第三方CDN的质量和价格约束，自建也是大型网络选择的必由之路。

基础平台解决了共性问题后，上层业务系统只需要集中关注业务领域，这样一来业务系统开发的周期大大缩短，所以苏宁很多的系统开发周期只有1-3个月。基础平台支撑能力越强，它为业务系统提供的可扩展性、可靠性、性能就越好，为业务系统的飞速发展提供了保证，使业务系统真正的站在巨人的肩上。

阿里和京东业务和人员也都是在建立了基础平台之后，快速发展起来的。

三、 研发流程

近两年苏宁进入了快速发展期，各种系统不断地被拆分和研发。仅消费者研发中心就有近200个系统，各个系统的质量参差不齐，而且越是靠近用户端的，越容易成为用户反馈和抱怨的密集地。如何把控系统的质量？中心在研发流程上下了大力气。总结起来就是在关键的研发点制定了对应的检查单和组织会议对其检查。

经得起推敲的产品才是好产品。对于产品的评审，力度也是相当大。不单是对产品需求，大到产品的运营指标，小到产品的文字都会反复评审。

通过架构设计模版和设计检查单，确保这些问题在设计系统时候都认真思考过。这样一来架构设计变得简单、有序。除了通过代码检查、sonar平台、各种测试等手段，中心也采用代码飞检来确保代码质量。

代码飞检就是定期快速评审系统的核心代码。与面向项目组内的代码走查不同的是参加代码飞检的人员级别比较高，都是各个系统负责人、架构师以及总监。当各个系统裸露在大家面前的时候，系统的美与丑很容易被区分。通过这种方式，我们发现了很多优秀的代码，也发现了幕后的高手。意想不到的效果是优秀的人才很快浮出水面，而不是靠挖掘了。

流程发布检查单是系统的最后一关，它需要经过产品负责人、开发负责人、QA、测试负责人、DBA、运维人员和线上验证人员对各个环节进行确认。让系统上线过程少出问题，出现了问题也能及时下架。
其实很多公司有这样的流程，但是受抵触情绪或者投入力度不够的影响，难免流于形式。而经验告诉我们，这实践起来真的不难，而且非常有效。

四、 系统保障

双11期间，除了新业务开发，我们主要的工作就是确保系统能够顶住流量的压力。为此我们做了两手准备：一个是提高系统的负载能力，另一个就是做应急预案准备。

系统的压力来自流量。首先我们根据历史数据对双11的流量进行了预估，然后细化到每个系统制定pv、uv、峰值的tps。接下来就是每个系统要努力达到这些指标。我们对目前系统的压力、容量、相关指标进行统计，按照预期的流量判断系统的服务是否满足要求，如果不满足就需要通过优化和扩容来完成，能优化则优先通过优化解决，因为扩容意味更多的服务器资源。

优化方面，我们对系统进行自上而下的体检，针对体检发现的问题指定相关的方案。具体是对系统架构进行了梳理、关键代码的优化以及中间件的调优。

好的架构可以节约很多资源。架构梳理主要对重点业务的处理流程和处理的链路进行审核。系统依赖问题是我们经常遇到，一个系统经常依赖多个系统，一个业务需要多次调用第三方服务，流程链相当长。针对这种情况消除这种依赖可以通过依赖调用改成第三方主动推送数据来完成。

在压测过程中，我们经常发现很多接口的性能不够高，主要原因是代码的处理机制过于简单。很多人因为经验和时间的原因写代码验证完功能认为搞定了一切，造成性能有很大的问题，更别说可扩展性和可维护性。做代码优化要静下心来，深入了解业务特点，构建优化方案。消息推送系统是我们重点优化的一个系统，从数据库中取用户列表，改成把用户列表存储在redis缓存中，性能一下子提高很多；以前都是一股脑的随机发送，现在则是首先推送重点城市，保证重点城市的用户在5分钟内接收到数据。

中间件主要针对jvm策略、各种链接池、系统链接数、缓存和读写分离做一些调正，通过压测最容易找到性能的瓶颈。为了让数据更真实，重要系统在夜深人静的时候还在生产系统上直接压测，帮助我们快速发现系统真实能力和系统瓶颈。优化和测试验证是个反复的过程，这期间的过程也相当辛苦。

系统如果能够按照预期流量来，我们大部分系统是可以支撑的，问题是你不清楚实际会来多少，尤其是峰值的时候。而且这些流量除了正常用户的访问流量，还有一些异常的流量。为此我们准备了应急预案和相应的操作手册。我们的应急预案主要包括几个方面黑名单、限流和降级。

黑名单主要是拒绝对系统的访问，如：IP黑名单、用户黑名单。
限流则是在流量超过系统最大负载时，主动丢弃相关的请求，以保全系统。现在的系统的都是分层部署的，限流可以通过防火墙流控功能、中间件的流控功能和流控组件来实现。苏宁的流控组件还支持IP、用户、URL三个纬度来控制的频度，防止过度请求。

降级可以让系统临时承担更大的流量压力。可以通过一下策略进行降级：屏蔽非关键业务的入口、关闭影响性能非关键业务功能、开启验证码策略延缓系统压力、延长缓存的时间牺牲实时性、放弃后端的补偿机制以减少调用链时间等。在多大压力的情况下开启什么的降级策略，需要再定义和演练。在实践过程中，我们定义了不同级别的降级策略、每个级别对应不同的流量压力。

应急预案一定要演练，否则预案就变得不可靠，也极有可能出现重大问题。

总结

技术上的准备要经得起考验。双11就要到了，正是我们大考的时候，我们将严阵以待，确保系统平稳运行。双11之后，相信有更多的文章和数据会分享出来，让大家更多了解我们是如何一路走来的。