首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >盘点电商大战背后的技术力量支撑

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

作者头像
Java高级架构
发布2018-08-03 11:45:46
13.1K0
发布2018-08-03 11:45:46
举报
文章被收录于专栏:JAVA高级架构JAVA高级架构

当当

迎战11.11——两大举措

举措一——重构促销系统

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

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

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

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

『解决方案』

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度监控信息。

为了保证系统在高并发、大流量访问下工作,并且使系统有较强的扩展性,唯品会围绕以上六个系统设计要点在重点实施上做了哪些具体实践,于公众号后台回复“唯品会”获取全文查看。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-07-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 JAVA高级架构 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档