苏宁 11.11：系统拆分的一些经验谈

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

技术上的压力来源于业务的需求。苏宁阿里战略合作后，易购赢得了社会的广泛关注，系统的流量在苏宁的传统促销节 8.18 显现出来；加上苏宁的双 11 销售目标，使得我们系统承担的压力更大了。

技术上的准备不是一蹴而就的，尤其像易购这样的大系统，更需要长期的积累和演变。历经多年的大促，目前苏宁在技术线上的准备变得也非常清晰和严谨。接下来我们将分享下在系统拆分、基础平台、研发流程和系统保障四个方面的经验。

另，ArchSummit 全球架构师峰会北京站将于 2015 年 12 月 18 日~19 日在北京国际会议中心召开，大会设置了《揭秘双十一背后的技术较量》专题来深入解读双十一背后的技术故事，欢迎关注。

一、 系统拆分方面

目前苏宁易购在线业务有相当多的系统，很多系统的TPS（每秒钟的请求数量）都非常高，而且做到了水平扩展。这些都是不断拆分和重构的结果，几年以前则是另一番景象。

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

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

系统职责明确了，能够独立发布了，进而快速响应新业务。系统变小了，新人只要了解很少的逻辑就能上手，而且模块小了、关注度高了，新人更能深入了解和优化系统。

二、 基础平台方面

系统拆分只是把系统的职责理顺了，接踵而来的是系统间的通讯问题和各个系统重复造轮子的问题。针对这些问题，苏宁成立了基础研发中心。基础研发中心属于一级中心，这也显示了苏宁对基础研发的重视。

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

云计算平台、云存储平台已经成为互联网的标配。云计算平台提供了KVM、Docker 的中间件服务，用来部署着苏宁大量的系统。云存储存支持文件存储和对象存储两种方式，支撑着苏宁的海量存储需求。

苏宁易购内部通讯方式主要有两套系统：MYESB 和RSF。 MYESB 是一个安全的集中消息转发服务系统，提供了同步和异步两种服务接口。其中同步基于HTTP+XML，异步基于MQ。RSF 类似阿里的Dubbo，提供远程调用的机制，支持HTTP 和TCP 通讯服务。它的优点是使消费方直接调用服务方，不需要像MYESB 需要代理转发，减少了系统延迟。 RSF 的TCP 通讯是长链的，可以减少网络开销。由于历史的原因苏宁有很多异构的系统，这些系统通常需要MYESB 来解决异构环境通讯问题；一般系统内部都是用RSF 作为通讯方式。

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

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

目前苏宁自建的CDN 服务承担的流量也相当的多。当流量比较大的时候，自身的业务会受到第三方CDN 的质量和价格约束。选择自建也是大型电商系统选择的必经之路。

当基础平台解决了共性问题后，上层业务系统只需要集中关注业务领域。这样一来业务系统开发的周期大大缩短，所以苏宁很多系统的开发周期都很短。当基础平台支撑能力越强，它为业务系统提供的可扩展性、可靠性、性能就越好，也能够保证业务系统的飞速发展，从而使业务真正站在巨人的肩上。从以往的资料来看，阿里、京东的业务和人员也都是在建立了基础平台之后快速发展起来的。

三、 研发流程

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

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

通过架构设计模版和设计检查单，确保这些问题在设计系统时候都认真思考过。这样一来架构设计变得简单、有序。

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

流程发布检查单是系统的最后一关，它需要经过产品负责人、开发负责人、QA、测试负责人、DBA、运维人员和线上验证人员对各个环节进行确认，让系统上线过程少出问题，出现了问题也能及时下架。

其实很多公司有这样的流程，但是受抵触情绪或者投入力度不够的影响，难免流于形式。而经验告诉我们，这些实践起来真的不难，而且非常有效。

四、 系统保障方面

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

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

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

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

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

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

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

黑名单主要是拒绝恶意的系统访问，如：IP 黑名单、用户黑名单。

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

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

另外很重要的一点是这些应急预案一定要演练，否则预案就变得不可靠，也极有可能出现重大问题。

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

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。