现在的位置: 首页 > 自动控制 > 工业·编程 > 正文

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

2016-01-01 21:34 工业·编程 ⁄ 共 6683字 ⁄ 字号 暂无评论

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

给我留言

留言无头像?