文档章节

支撑千万级,大型电商分布式架构解析

李红欧巴
 李红欧巴
发布于 04/26 15:18
字数 5080
阅读 86
收藏 6

1. 大型分布式网站架构概述

1.1. 大型网站的特点

  • 用户多,分布广泛

  • 大流量,高并发

  • 海量数据,服务高可用

  • 安全环境恶劣,易受网络攻击

  • 功能多,变更快,频繁发布

  • 从小到大,渐进发展

  • 以用户为中心

  • 免费服务,付费体验

 

1.2. 大型网站架构目标

  • 高性能:提供快速的访问体验。

  • 高可用:网站服务一直可以正常访问。

  • 可伸缩:通过硬件增加/减少,提高/降低处理能力。

  • 安全性:提供网站安全访问和数据加密,安全存储等策略。

  • 扩展性:方便的通过新增/移除方式,增加/减少新的功能/模块。

  • 敏捷性:随需应变,快速响应;

 

1.3. 大型网站架构模式

  • 分层:一般可分为,应用层,服务层,数据层,管理层,分析层;

  • 分割:一般按照业务/模块/功能特点进行划分,比如应用层分为首页,用户中心。

  • 分布式:将应用分开部署(比如多台物理机),通过远程调用协同工作。

  • 集群:一个应用/模块/功能部署多份(如:多台物理机),通过负载均衡共同提供对外访问。

  • 缓存:将数据放在距离应用或用户最近的位置,加快访问速度。

  • 异步:将同步的操作异步化。客户端发出请求,不等待服务端响应,等服务端处理完毕后,使用通知或轮询的方式告知请求方。一般指:请求——响应——通知 模式。

  • 冗余:增加副本,提高可用性,安全性,性能。

  • 安全:对已知问题有有效的解决方案,对未知/潜在问题建立发现和防御机制。

  • 自动化:将重复的,不需要人工参与的事情,通过工具的方式,使用机器完成。

  • 敏捷性:积极接受需求变更,快速响应业务发展需求。

 

1.4. 高性能架构

以用户为中心,提供快速的网页访问体验。主要参数有较短的响应时间,较大的并发处理能力,较高的吞吐量,稳定的性能参数。

可分为前端优化,应用层优化,代码层优化,存储层优化。

前端优化:网站业务逻辑之前的部分;

浏览器优化:减少 Http 请求数,使用浏览器缓存,启用压缩,Css Js 位置,Js 异步,减少 Cookie 传输;

CDN 加速,反向代理;

应用层优化:处理网站业务的服务器。使用缓存,异步,集群

代码优化:合理的架构,多线程,资源复用(对象池,线程池等),良好的数据结构,JVM 调优,单例,Cache 等;

存储优化:缓存,固态硬盘,光纤传输,优化读写,磁盘冗余,分布式存储(HDFS),NOSQL 等;

 

1.5. 高可用架构

大型网站应该在任何时候都可以正常访问。正常提供对外服务。因为大型网站的复杂性,分布式,廉价服务器,开源数据库,操作系统等特点。要保证高可用是很困难的,也就是说网站的故障是不可避免的。

如何提高可用性,就是需要迫切解决的问题。首先,需要从架构级别,在规划的时候,就考虑可用性。行业内一般用几个 9 表示可用性指标。比如四个 9(99.99),一年内允许的不可用时间是 53 分钟。

不同层级使用的策略不同,一般采用冗余备份和失效转移解决高可用问题。

应用层:一般设计为无状态的,对于每次请求,使用哪一台服务器处理是没有影响的。一般使用负载均衡技术(需要解决 Session 同步问题),实现高可用。

服务层:负载均衡,分级管理,快速失败(超时设置),异步调用,服务降级,幂等设计等。

数据层:冗余备份(冷,热备[同步,异步],温备),失效转移(确认,转移,恢复)。数据高可用方面著名的理论基础是 CAP 理论(持久性,可用性,数据一致性[强一致,用户一致,最终一致])

 

1.6. 可伸缩架构

伸缩性是指在不改变原有架构设计的基础上,通过添加/减少硬件(服务器)的方式,提高/降低系统的处理能力。

应用层:对应用进行垂直或水平切分。然后针对单一功能进行负载均衡(DNS,HTTP[反向代理],IP,链路层)。

服务层:与应用层类似;

数据层:分库,分表,NOSQL 等;常用算法 Hash,一致性 Hash。

 

1.7. 可扩展架构

可以方便的进行功能模块的新增/移除,提供代码/模块级别良好的可扩展性。

模块化,组件化:高内聚,内耦合,提高复用性,扩展性。

稳定接口:定义稳定的接口,在接口不变的情况下,内部结构可以“随意”变化。

设计模式:应用面向对象思想,原则,使用设计模式,进行代码层面的设计。

消息队列:模块化的系统,通过消息队列进行交互,使模块之间的依赖解耦。

分布式服务:公用模块服务化,提供其他系统使用,提高可重用性,扩展性。

 

1.8. 安全架构

对已知问题有有效的解决方案,对未知/潜在问题建立发现和防御机制。对于安全问题,首先要提高安全意识,建立一个安全的有效机制,从政策层面,组织层面进行保障。比如服务器密码不能泄露,密码每月更新,并且三次内不能重复;每周安全扫描等。以制度化的方式,加强安全体系的建设。同时,需要注意与安全有关的各个环节。安全问题不容忽视。包括基础设施安全,应用系统安全,数据保密安全等。

基础设施安全:硬件采购,操作系统,网络环境方面的安全。一般采用,正规渠道购买高质量的产品,选择安全的操作系统,及时修补漏洞,安装杀毒软件防火墙。防范病毒,后门。设置防火墙策略,建立 DDOS 防御系统,使用攻击检测系统,进行 子网隔离等手段。

应用系统安全:在程序开发时,对已知常用问题,使用正确的方式,在代码层面解决掉。防止跨站脚本攻击(XSS),注入攻击,跨站请求伪造(CSRF),错误信息,HTML 注释,文件上传,路径遍历等。还可以使用 Web 应用防火墙(比如:ModSecurity),进行安全漏洞扫描等措施,加强应用级别的安全。

数据保密安全:存储安全(存在在可靠的设备,实时,定时备份),保存安全(重要的信息加密保存,选择合适的人员复杂保存和检测等),传输安全(防止数据窃取和数据篡改);

常用的加解密算法(单项散列加密[MD5,SHA],对称加密[DES,3DES,RC]),非对称加密[RSA]等。

 

1.9. 敏捷性

网站的架构设计,运维管理要适应变化,提供高伸缩性,高扩展性。方便的应对快速的业务发展,突增高流量访问等要求。

除上面介绍的架构要素外,还需要引入敏捷管理,敏捷开发的思想。使业务,产品,技术,运维统一起来,随需应变,快速响应。

 

1.10. 大型架构举例

以上采用七层逻辑架构,第一层客户层,第二层前端优化层,第三层应用层,第四层服务层,第五层数据存储层,第六层大数据存储层,第七层大数据处理层。

客户层:支持 PC 浏览器和手机 APP。差别是手机 APP 可以直接访问通过 IP 访问,反向代理服务器。

前端层:使用 DNS 负载均衡,CDN 本地加速以及反向代理服务;

应用层:网站应用集群;按照业务进行垂直拆分,比如商品应用,会员中心等;

服务层:提供公用服务,比如用户服务,订单服务,支付服务等;

数据层:支持关系型数据库集群(支持读写分离),NOSQL 集群,分布式文件系统集群;以及分布式 Cache;

大数据存储层:支持应用层和服务层的日志数据收集,关系数据库和 NOSQL 数据库的结构化和半结构化数据收集;

大数据处理层:通过 Mapreduce 进行离线数据分析或 Storm 实时数据分析,并将处理后的数据存入关系型数据库。(实际使用中,离线数据和实时数据会按照业务要求进行分类处理,并存入不同的数据库中,供应用层或服务层使用)。

 

2. 电商网站架构案例

2.1. 网站初级架构

一般网站,刚开始的做法,是三台服务器,一台部署应用,一台部署数据库,一台部署 NFS 文件系统。

这是前几年比较传统的做法,之前见到一个网站 10 万多会员,垂直服装设计门户,N 多图片。使用了一台服务器部署了应用,数据库以及图片存储。出现了很多性能问题。

如下图:

但是,目前主流的网站架构已经发生了翻天覆地的变化。一般都会采用集群的方式,进行高可用设计。至少是下面这个样子。

(1) 使用集群对应用服务器进行冗余,实现高可用;(负载均衡设备可与应用一块部署)

使用数据库主备模式,实现数据备份和高可用;

 

2.2. 系统容量预估

预估步骤:

(1) 注册用户数-日均 UV 量-每日的 PV 量-每天的并发量;

(2) 峰值预估:平常量的 2~3 倍;

(3) 根据并发量(并发,事务数),存储容量计算系统容量。

客户需求:3~5 年用户数达到 1000 万注册用户;

每秒并发数预估:

(1) 每天的 UV 为 200 万(二八原则);

(2) 每日每天点击浏览 30 次;

(3) PV 量:200*30=6000 万;

(4) 集中访问量:240.2=4.8 小时会有 6000 万0.8=4800 万(二八原则);

(5) 每分并发量:4.8*60=288 分钟,每分钟访问 4800/288=16.7 万(约等于);

(6) 每秒并发量:16.7 万/60=2780(约等于);

(7) 假设:高峰期为平常值的三倍,则每秒的并发数可以达到 8340 次。

(8) 1 毫秒=1.3 次访问;

没好好学数学后悔了吧?!(不知道以上算是否有错误,呵呵~~)

服务器预估:(以 tomcat 服务器举例)

(1) 按一台 web 服务器,支持每秒 300 个并发计算。平常需要 10 台服务器(约等于);[tomcat 默认配置是 150]

(2) 高峰期:需要 30 台服务器;

容量预估:70/90 原则

系统 CPU 一般维持在 70%左右的水平,高峰期达到 90%的水平,是不浪费资源,并比较稳定的。内存,IO 类似。

以上预估仅供参考,因为服务器配置,业务逻辑复杂度等都有影响。在此 CPU,硬盘,网络等不再进行评估。

 

2.3. 网站架构分析

根据以上预估,有几个问题:

  • 需要部署大量的服务器,高峰期计算,可能要部署 30 台 Web 服务器。并且这三十台服务器,只有秒杀,活动时才会用到,存在大量的浪费。

  • 所有的应用部署在同一台服务器,应用之间耦合严重。需要进行垂直切分和水平切分。

  • 大量应用存在冗余代码

  • 服务器 SESSION 同步耗费大量内存和网络带宽

  • 数据需要频繁访问数据库,数据库访问压力巨大。

大型网站一般需要做以下架构优化(优化是架构设计时,就要考虑的,一般从架构/代码级别解决,调优主要是简单参数的调整,比如 JVM 调优;如果调优涉及大量代码改造,就不是调优了,属于重构):

  • 业务拆分

  • 应用集群部署(分布式部署,集群部署和负载均衡)

  • 多级缓存

  • 单点登录(分布式 Session)

  • 数据库集群(读写分离,分库分表)

  • 服务化

  • 消息队列

  • 其他技术

 

2.4. 网站架构优化

业务拆分

根据业务属性进行垂直切分,划分为产品子系统,购物子系统,支付子系统,评论子系统,客服子系统,接口子系统(对接如进销存,短信等外部系统)。

根据业务子系统进行等级定义,可分为核心系统和非核心系统。核心系统:产品子系统,购物子系统,支付子系统;非核心:评论子系统,客服子系统,接口子系统。

业务拆分作用:提升为子系统可由专门的团队和部门负责,专业的人做专业的事,解决模块之间耦合以及扩展性问题;每个子系统单独部署,避免集中部署导致一个应用挂了,全部应用不可用的问题。

等级定义作用:用于流量突发时,对关键应用进行保护,实现优雅降级;保护关键应用不受到影响。

拆分后的架构图:

参考部署方案 2 

(1) 如上图每个应用单独部署

(2) 核心系统和非核心系统组合部署

 

应用集群部署(分布式,集群,负载均衡)

分布式部署:将业务拆分后的应用单独部署,应用直接通过 RPC 进行远程通信;

集群部署:电商网站的高可用要求,每个应用至少部署两台服务器进行集群部署;

负载均衡:是高可用系统必须的,一般应用通过负载均衡实现高可用,分布式服务通过内置的负载均衡实现高可用,关系型数据库通过主备方式实现高可用。

集群部署后架构图:

多级缓存

缓存按照存放的位置一般可分为两类:本地缓存和分布式缓存。本案例采用二级缓存的方式,进行缓存的设计。一级缓存为本地缓存,二级缓存为分布式缓存。(还有页面缓存,片段缓存等,那是更细粒度的划分)

一级缓存,缓存数据字典,和常用热点数据等基本不可变/有规则变化的信息,二级缓存缓存需要的所有缓存。当一级缓存过期或不可用时,访问二级缓存的数据。如果二级缓存也没有,则访问数据库。

缓存的比例,一般 1:4,即可考虑使用缓存。(理论上是 1:2 即可)。

根据业务特性可使用以下缓存过期策略:

(1) 缓存自动过期;

(2) 缓存触发过期;

 

单点登录(分布式 Session)

系统分割为多个子系统,独立部署后,不可避免的会遇到会话管理的问题。一般可采用 Session 同步,Cookies,分布式 Session 方式。电商网站一般采用分布式 Session 实现。

再进一步可以根据分布式 Session,建立完善的单点登录或账户管理系统。

流程说明

(1) 用户第一次登录时,将会话信息(用户 Id 和用户信息),比如以用户 Id 为 Key,写入分布式 Session;

(2) 用户再次登录时,获取分布式 Session,是否有会话信息,如果没有则调到登录页;

(3) 一般采用 Cache 中间件实现,建议使用 Redis,因为它有持久化功能,方便分布式 Session 宕机后,可以从持久化存储中加载会话信息;

(4) 存入会话时,可以设置会话保持的时间,比如 15 分钟,超过后自动超时;

结合 Cache 中间件,实现的分布式 Session,可以很好的模拟 Session 会话。

 

数据库集群(读写分离,分库分表)

大型网站需要存储海量的数据,为达到海量数据存储,高可用,高性能一般采用冗余的方式进行系统设计。一般有两种方式读写分离和分库分表。

读写分离:一般解决读比例远大于写比例的场景,可采用一主一备,一主多备或多主多备方式。

本案例在业务拆分的基础上,结合分库分表和读写分离。如下图:

(1) 业务拆分后:每个子系统需要单独的库;

(2) 如果单独的库太大,可以根据业务特性,进行再次分库,比如商品分类库,产品库;

(3) 分库后,如果表中有数据量很大的,则进行分表,一般可以按照 Id,时间等进行分表;(高级的用法是一致性 Hash)

(4) 在分库,分表的基础上,进行读写分离;

相关中间件可参考 Cobar(阿里,目前已不在维护),TDDL(阿里),Atlas(奇虎 360),MyCat(在 Cobar 基础上,国内很多牛人,号称国内第一开源项目)。

分库分表后序列的问题,JOIN,事务的问题,会在分库分表主题分享中,介绍。

 

服务化

将多个子系统公用的功能/模块,进行抽取,作为公用服务使用。比如本案例的会员子系统就可以抽取为公用的服务。

消息队列

消息队列可以解决子系统/模块之间的耦合,实现异步,高可用,高性能的系统。是分布式系统的标准配置。本案例中,消息队列主要应用在购物,配送环节。

(1) 用户下单后,写入消息队列,后直接返回客户端;

(2) 库存子系统:读取消息队列信息,完成减库存;

(3) 配送子系统:读取消息队列信息,进行配送;

目前使用较多的 MQ 有 Active MQ,Rabbit MQ,Zero MQ,MS MQ 等,需要根据具体的业务场景进行选择。建议可以研究下 Rabbit MQ。

 

其他架构(技术)

除了以上介绍的业务拆分,应用集群,多级缓存,单点登录,数据库集群,服务化,消息队列外。还有 CDN,反向代理,分布式文件系统,大数据处理等系统。

此处不详细介绍,大家可以问度娘/Google,有机会的话也可以分享给大家。

 

2.5. 架构总结

以上是本次分享的架构总结,其中细节可参考前面分享的内容。其中还有很多可以优化和细化的地方,因为是案例分享,主要针对重要部分做了介绍,工作中需要大家根据具体的业务场景进行架构设计。

以上是电商网站架构案例的分享一共有三篇,从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型。除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标)。

免费Java资料需要自己领取,涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程,一共30G。 
传送门: https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q

© 著作权归作者所有

李红欧巴

李红欧巴

粉丝 52
博文 152
码字总数 498454
作品 0
长沙
私信 提问
沙龙报名 | 探索新零售时代的数字化创新

互联网技术正在重塑新零售的消费场景,使顾客消费思维发生改变。消费习惯由价格时代转为价值时代。同时,体验需求得到升级。新零售在“人、货、场”数字化过程中,针对不同垂直领域需要不同的...

京东云技术新知
05/16
5
0
亿级流量电商详情页系统的大型高并发与高可用缓存架构实战

对于高并发的场景来说,比如电商类,o2o,门户,等等互联网类的项目,缓存技术是Java项目中最常见的一种应用技术。然而,行业里很多朋友对缓存技术的了解与掌握,仅仅停留在掌握redis/memca...

登录404
2017/06/05
1K
0
51CTO学院第一期技术沙龙—WEB开发专场

活动内容 去年发布的Android Lollipop和iOS 8都已经添加了像Web GL和Web Audio来提升HTML 5在各自设备上的处理能力。另外随着HTML5规范的正式定稿以及微软等巨头相继拥抱Html5 ,Web开发再一次...

51CTO学院
2015/07/22
341
2
SDCC 2016 中国软件开发者大会盛大开幕

2016年11月18-20日,由 CSDN打造的“SDCC 2016中国软件开发者大会”(以下简称SDCC 2016),在北京京都信苑饭店盛大开幕。大会为期三天,汇聚100多位国内外顶尖专家和知名讲师,全体大会探讨...

玄学酱
2018/05/08
0
0
51CTO学院第一期技术沙龙—WEB开发专场

活动内容 去年发布的Android Lollipop和iOS 8都已经添加了像Web GL和Web Audio来提升HTML 5在各自设备上的处理能力。另外随着HTML5规范的正式定稿以及微软等巨头相继拥抱Html5 ,Web开发再一次...

51CTO学院
2015/07/22
9
0

没有更多内容

加载失败,请刷新页面

加载更多

Shell学习记录(持续更新)

一、shell定时备份数据库任务通用脚本 目标:根据定时任务启动脚本,执行数据库备份任务,按照日期进行每日备份,如已经备份则脚本停止,备份任务完成后将结果发送邮件提醒 1.执行数据库备份...

网络小虾米
今天
3
0
PHP计算两个经纬度地点之间的距离

/** * 求两个已知经纬度之间的距离,单位为米 * * @param lng1 $ ,lng2 经度 * @param lat1 $ ,lat2 纬度 * @return float 距离,单位米 * @author www.Alixixi.com */function get...

子枫Eric
今天
14
0
Linux—day 4

ch2 需要掌握的命令 (1)cat -n 1.txt (2)more 1.txt (3)head -n 15 initial-setup-ks.cfg (4)tail -n 17 initial-setup-ks.cfg;tail -f initial-setup-ks.cfg (5)cat -n anaconda-ks.c......

呵呵暖茶
今天
31
0
【Kubernetes社区之路】我的PR被抢了

2019年11月的某天,我无意间发现一个PR作者在自己的PR中抱怨自己的PR没被合入,而另一个比自己提交晚且内容几乎一样的PR则被合入了。 字里行间透露些许伤感外加无奈,原文如下: 作为一名开源...

恋恋美食
今天
40
0
阻塞队列

对于许多线程问题, 可以通过使用一个或多个队列以优雅且安全的方式将其形式化。生产者线程向队列插人元素, 消费者线程则取出它们。 使用队列, 可以安全地从一个线程向另 一个线程传递数据...

ytuan996
今天
48
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部