盘点电商大战背后的技术力量支撑

相关阅读：

阿里职位层级（附P级详细要求）

“我在公司待了 6 年，清退我却只花了 6 分钟”

我在阿里工作9年，今天我离职了

举措一——重构促销系统

『目的』满足贯穿从商品展示、搜索、购买、支付等整个流程，电商对于精细化、精准化促销运营的需求，使多渠道（终端）、多区域化营销成为简单易行的配置操作，提升运营能力。

『目标』保证促销规则支持分时段设置，多活动可叠加，促销系统中数据量超过商品信息系统的前提下，促销内容会根据执行效果快速调整，以强大的促销系统，保证有序的促销活动，使促销系统承担营销功能。

『核心改进点』数据模型与运营的贴合度决定的扩展性、灵活性，系统解耦和更强大的数据处理能力

『其他待解决问题』促销模型较陈旧、扩展性差，促销系统成熟度低、与其他系统耦合严重。

『解决方案』

step 1 ：确定最基本的促销模型；

step 2 ：在促销模型基础上抽象出活动模型；

step 3 ：基础模型定型，实施解耦相关设计——

系统交互解耦：将直读DB和存储冗余促销数据的系统修改为调用服务及监听MQ 逻辑回收：包括将促销校验与促销计算提取为交易服务，将原先由购物车、交易系统自行处理的促销逻辑回收 提取促销工具的属性：诸如类型枚举、促销标签、限购策略、库存策略等，以期外围系统尽量少的关注促销类型，通过促销ID拿到所需信息直接使用。［未来关注于业务层面的梳理与整合，逐步回收适用于活动模型的其他“类促销”业务。］

step 4 : 完善促销系统查询服务，使其具备更强大的数据处理能力和更好的性能表现。

应用架构实现上，从前端页面到后端逻辑，尽量避免有逻辑与促销类型直接绑定，全部以插件化方式与促销模型对接，完全根据促销类型的配置进行组装。针对不同维度、条件、优惠、促销属性，定制页面模板及业务逻辑，使得新增一种促销类型（在已有维度、条件、优惠下）仅需配置即可完成。促销系统的查询服务需要同时为多个系统提供数据，对TPS要求很高，同时促销的时效性又要求很高的实时性。我们采用的方式是在数据库前加Redis缓存，提高响应速度，同时监听MQ，根据事件清理相应的缓存数据。

『需注意问题』

Redis缓存虽减轻了DB压力，但对于计算密集型应用并未减轻应用服务器压力，IO未节省且增加序列化开销；事件驱动清理缓存在读写分离场景下，有可能比主从同步更快，造成缓存数据错误。

举措二——重构交易系统

『措施——引入业界成熟技术实现方案』

• 集中化配置：一点配置，所有实例可见，更易于管理，且配置修改后，通过热加载方式，立刻生效，快速便捷。

• 页面缓存技术：大流程计算结果进行缓存，在一次页面请求范围内，后续调用直接用缓存结果，极大提高页面刷新速度。

• 小版本合并：由于历史原因，交易系统存在很多版本的结算逻辑。最常用的是统一结算，还有一些特殊类型的结算，如秒杀、一键下单、补发货等等，逻辑与统一结算稍有不同，统称为小版本结算。因小版本结算与统一结算大部分逻辑相同，因此新交易系统将二者合到了一起，共享基础逻辑，而不同的逻辑则单独处理，极大提高了可维护性。

• 灰度发布、无缝切换：借助了Nginx在运行状态下可以reload配置，而基本不影响对外提供服务的能力。每个Nginx负载两台应用服务器，灰度发布时，将Nginx配置更改为只负载一台应用服务器，即可对另一台进行部署。用户请求不会导向正在部署中的服务器，从而不影响用户下单。

• 并行比对：交易系统的计算都和金钱有关，必须慎之又慎，因而提出线上并行比对方案，根据老交易系统比对新交易，保证其逻辑正确。

• 分流：开发分流功能，按照用户id来分流，正式分流前，先使用测试白名单中的用户进行预验证。预验证通过后，再按比例由低至高逐步切换。

• Web服务器按需伸缩：基于前面所讲的灰度发布技术，新交易系统很容易做到按需伸缩。正常情况下，每个Nginx负载两台应用服务器。双十一需要扩容时，将待扩服务器ip地址加入Nginx配置，重新reload，该Nginx就可负载更多台应用服务器了。

  
  

交易系统上线后为备战双十一，确保万无一失，利用老交易系统还未下线的条件进行了线上压测。为达到最准确的测试效果，且不影响正常系统运行，当当的技术团队进行如何准备，以及上文重构促销系统中提到的促销模型具体设计。

苏宁 迎战11.11——四大方向

方向一——关于系统拆分

『前提』技术上分析主流程、分离主干系统和枝叶系统、根据业务内聚性独立出主干系统，做到分别部署。业务上分析电商主要功能与重运营特点。

『执行』根据业务功能拆分出几大核心系统，包括：会员、商品、库存、价格、购物车、交易、订单和内容管理等，并组建对应的研发中心来维护；根据交易环节的系统压力，独立出抢购和秒杀系统，拆分出购物券、云钻等营销类的系统，并组建营销中心。

方向二——关于基础平台

『主攻解决问题』

• 基础架构方面包括自建CDN、云计算和云存储；

• 通用系统方面包括短信、邮件、验证等系统；

• 系统集成包方面括系统之间的通讯、统一验证和内部管理系统的统一权限；

• 中间件方面包括Session共享、分布式调用链、Redis分片存储、数据库的分库分表中间件、统一配置管理和流控；

• 平台方面：运维监控平台，持续集成平台，大数据分析平台；以及针对安全的风控系统等。

『Tips』

• 内部通讯方式系统分别选取MYESB和RSF，其中 MYESB是一个安全的集中消息转发服务系统，提供同步和异步两种服务接口。RSF类似阿里的Dubbo，提供远程调用的机制，支持HTTP和TCP通讯服务。

• 持续交付平台主要包括代码基础框架自动生成、代码质量分析、代码的自动化部署和代码权限管理。
  

• 监控平台包括对硬件资源、操作系统、中间件以及业务系统的监控。实时日志系统偏向分析的LogMonitor系统以及针对移动端的监控系统，基于ELK技术, 可以实时监测请求状态、系统错误和进行多维度查询分析；LogMonitor可以统计分析接口最大、平均处理时间和历史接口的性能对比。

方向三——关于研发流程

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

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

方向四——关于系统保障

『准备一：提高系统负载能力』

step 1 : 根据历史数据对双11的流量进行预估，细化到每个系统的PV、UV、峰值TPS，要求每个系统要努力达到这些指标；

step 2 ：对目前系统压力、容量和相关指标进行统计，按预期流量判断系统的服务是否满足要求；

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

『Tips』

架构梳理主要对重点业务的处理流程和处理的链路进行审核。一个系统经常依赖多个系统，一个业务需要多次调用第三方服务，导致流程链相当长。在非必要依赖的前提下，可通过依赖调用改成第三方主动推送数据来消除依赖。

『准备二：应急预案』

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

• 限流：在流量超过系统负载警戒线时，主动丢弃相关的请求，以保全系统，即为限流。限流可通过防火墙流控功能、中间件的流控功能和流控组件来实现。目前采用的流控组件还支持IP、用户、URL三个纬度来控制访问频度，以防止过度请求。
  

• 降级：降级可使系统临时承担更大的流量压力，具体策略包括：屏蔽非关键业务的入口、关闭影响性能非关键业务功能、页面静态化、开启验证码策略延缓系统压力、延长缓存的时间牺牲实时性、放弃后端的补偿机制以减少调用链时间等。在多大压力的情况下开启什么的降级策略，需要具体问题具体分析。

  
  

蘑菇街

迎战11.11——五个关注焦点

焦点一——稳定性

对已遇到过的问题，及时采用各种方式解决或规避。如：CentOS6.5自带device mapper存在dm-thin discard导致内核可能随机crash，解决方式为关闭discard support，在docker配置中添加“--storage-opt dm.mountopt=nodiscard --storage-opt dm.blkdiscard=false”，且严格禁止磁盘超配，磁盘超配可能会导致整个device mapper无法分配磁盘空间，从而使整个文件系统变成只读，引起严重问题。

焦点二——多维度的阈值监控

• 实时pid数量监控：由于Linux内核对pid的隔离性支持并不完善，导致需要监控实时pid数量，目前并没有任何Linux发行版能做到针对pid按照容器粒度进行pid_max限制。

• 内存使用监控：cgroup提供的内存使用值比真实使用的内存值要低。内核memcg无法回收slab cache，也不对dirty cache量进行限制，所以很难估算容器真实的内存使用情况。因此调整容器内存的计算算法，根据经验值，将cache的40%算做rss，调整后的内存计算比之前想对精确。
  

• 日志乱序：跑Docker的宿主机内核日志中常会产生字符乱序，导致日志监控无法取到正确的关键字进行报警。原因与宿主机和Docker容器中都跑了rsyslogd有关。该问题可通过修改container里的rsyslog配置，只让宿主机去读kernel日志解决。
  

• 隔离开关：在压力大的情况下，为个别容器进行动态的CPU，内存等扩容或缩容，调整甚至放开磁盘iops限速和网络的TC限速。健康监测：定期的扫描线上可能存在的潜在风险，以提前发现问题解决问题有备无患。

焦点三——灾备和紧急故障处理

• 如在不启动Docker Daemon情况下，离线恢复Docker中数据的方法。方法是：用dmsetup create命令创建一个临时的dm设备，映射到Docker实例所用的dm设备号，通过mount临时设备，恢复原有数据。

• 支持Docker容器冷迁移。通过管理平台界面一键实现跨物理机迁移。

焦点四——与已有运维系统的对接

Docker集群须能与现有运维系统无缝对接，才能快速响应，做到秒级的弹性扩容／缩容。因而以统一的容器管理平台，实现对多个Docker集群的管理，从下发指令到完成容器的创建可以在7秒内完成。

焦点五——性能优化

• 针对磁盘IO的性能瓶颈，调优像vm.dirty_expire_centisecs,vm.dirty_writeback_centisecs, vm.extra_free_kbytes这样的内核参数。

• 引入了Facebook的开源软件flashcache，将SSD作为cache，提高docker容器的IO性能。

• 通过合并镜像层次来优化docker pull镜像的时间。在docker pull时，每一层校验的耗时很长，通过减小层数，不仅大小变小，docker pull时间也大幅缩短。

唯品会 迎战11.11——六个设计要点

要点一——系统模块有效切分

重点解决业务系统在实际运作中业务耦合严重，模块划分不合理，导致模块之间边界不清楚问题。解决方案为，从整个系统角度出发，梳理整个流程，重新做系统定位，将不同业务子系统做物理分离，减少彼此之间的依赖，使各个子系统独立部署，出现问题后能快速采取措施，隔离出问题模块，将故障影响降到最低。

要点二——服务化解耦，集中服务治理

基于Spring的Java开发框架独立自主开发Venus系统, 降低开发复杂度, 提高开发人员开发效率, 提升代码质量, 规范开发流程。

『Venus框架涵盖以下内容』

• 数据库访问层封装，支持分库、分表，连接池优化

• 缓存（Redis/Memcached）接口封装，连接池优化

• CRUD服务代码自动生成（包含数据库操作）

• OSP/REST服务调用接口封装及异步支持

• ValidateInternals

• 单元／集成测试模版代码自动生成

• 配置中心

• 中央文档中心

『Tips』

开放服务平台（OSP）：其主要目标是提供服务化的核心远程调用机制，OSP提供了丰富的服务治理能力，如路由、负载均衡、服务保护和优雅降级等，通过OSP，有效的实现了流量控制。

服务限流：在系统流量达到极限时的情况，有自动熔断机制。熔断器是在服务或者周边环境（如网络）出现了异常后主动断开客户端后续的使用，从而避免服务崩溃无法恢复。但是在后续时间熔断将使用小量请求尝试侦测服务是否已经恢复，如果恢复则将服务再次提供给客户端调用。

服务降级：通过对不同业务级别定义不同的降级策略，对除核心主流程以外的功能，根据系统压力情况进行有策略的关闭，从而达到服务降级的目的，例如在线商品信息必须保证优先访问，对于下线的商品信息，可容许在访问容量受限情况下，容许关闭下线商品详情页面的访问等。

要点三——增加异步访问

对于系统间实时性要求不高的操作，如执行时比较耗时，可通过异步处理提高调用者性能，提高响应能力，尤其通过异步调用通知非主要流程，加快了系统主要业务流程的反应速度和性能，异步处理机制可起到缓冲的作用，被通知的下游系统可依据自身能力控制处理数据量，避免遭受超负荷的冲击，保证系统稳定运行，增加了系统可用性。

分布式异步消息队列服务器可在宕机后确保消息不丢失，异步系统有重试机制，从而提高系统可用性、健壮性和扩展性。

要点四——多阶段缓存，降低后端压力

• 动静分离，静态化：静态化可降低后端压力，通过用户浏览器缓存静态资源，失效时间通过cache-control来控制。通过CDN缓存到靠近用户的节点，提高CDN效率。

• 分布式缓存：引入分布式缓存，对缓存数据服务节点做统一集中管理，可支持缓存集群弹性扩展，通过动态增加或减少节点应对变化的数据访问负载，通过冗余机制实现高可用性，无单点失效，不会因服务器故障而导致缓存服务中断或数据丢失。应用端使用统一的API接口访问缓存服务器。

• 巧用应用服务器本地缓存：将基本不修改的配置数据、全局数据可以在应用服务器本地缓存，减少对后端缓存服务器实例的峰值冲击。本地缓存需要谨慎使用，如果大量使用本地缓存，可能会导致相同的数据被不同的节点存储多份，对内存资源造成较大的浪费。对于频繁修改的数据、没有热点的访问数据、数据一致性要求非常高的数据，不建议使用缓存。

要点五——优化数据库访问

• 优化复杂查询，提高数据库查询效率，找出关键模块的数据库慢查询进行优化。

• 保证在实现功能的基础上，减少对数据库的访问次数；通过查询参数，减少对表的访问行数，最小化结果集，减轻网络负担。

• 基于电商系统读写比很大的特性，采用读写分离技术，通过一主多从，写操作只发生在主表，多操作发生在从表上，缓解对主数据库的访问压力。

• 借助于分布式缓存，缓存提供了远大于数据库访问的性能。当某一应用要读取数据时，会首先从缓存中查找需要的数据，如果找到了则直接执行，找不到的话则从数据库中找。在设计时，需要防止缓存失效带来的缓存穿透压力。

• 容许一定程度的数据冗余，对于关键模块，为了防止对其它模块的依赖而影响当前模块的性能和可靠性，可适度保存其它模块的关键数据，减少由于访问其它模块服务带来的系统损耗和可靠性压力。

• 使用NoSQL数据库对海量大数据进行存储和处理。

要点六——加强系统监控

• 系统/网络层面监控：主要是对下列指标进行监控：服务器指标，如CPU、内存、磁盘、流量、TCP连接数等；数据库指标，如QPS、主从复制延时、进程、慢查询等。

• 业务层面监控：通过在指定页面做埋点，和从业务系统的数据库两种方法，将需要监控的数据抽取出来，做必要的分析处理，存入运维自己维护的数据库中；然后通过浏览器页面，展示监控数据，页面同时提供各种时间维度上的筛选、汇总。对一些业务的关键指标如PV、UV、商品展示、登录/注册、转化率、购物车、订单数量、支付量、发货量和各仓订单数据。可自定义告警范围，通知相关人以便做出响应。

• 应用层面监控系统Mercury：独立研发应用性能监控平台，通过在应用程序中植入探针逻辑来实现对应用代码、关系数据库、缓存系统的实时监控。Mercury通过收集日志、上报日志的方式即时获取相关性能指标并进行智能分析，及时发现分布式应用系统的性能问题以及异常和错误，为系统解决性能和程序问题提供方便可靠的依据。同时通过Mercury数据展现平台，用户可轻松便捷的获取应用360度监控信息。

如有收获，欢迎「分享 」

「点赞」「评论 」

看完本文有收获？请转发分享给更多人

---

欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，我们只聊互联网、只聊架构，不聊其他！打造最有价值的架构师圈子和社区。

本公众号覆盖中国主要首席架构师、高级架构师、CTO、技术总监、技术负责人等人 群。分享最有价值的架构思想和内容。打造中国互联网圈最有价值的架构师圈子。

• 长按下方的二维码可以快速关注我们

• 

  如想加群讨论学习，请点击右下角的“加群学习”菜单入群