大型分布式电商系统架构是如何从0开始演进的?

  • 时间:
  • 浏览:1

常用的负载均衡技术硬件的有F5,价格比较贵,软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡,根据目标地址和端口挑选内控 服务器,Nginx和HAProxy是七层负载均衡,还后能 根据报文内容挑选内控 服务器,后后LVS埋点路径优于Nginx和HAProxy,性能要高些,而Nginx和HAProxy则更具配置性,如还后能 用来做动静分离(根据请求报文底部形态,挑选静态资源服务器还是应用服务器)。

请输入描述

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

以上预估仅供参考,完后 服务器配置,业务逻辑多样化度等后会影响。在此CPU,硬盘,网络等不再进行评估。

10、大型架构举例

大型网站的架构是根据业务需求不断完善的,根据不同的业务底部形态会做特定的设计和考虑,本文要是讲述那我常规大型网站会涉及的一点技术和手段,希望能给一点人儿带来启发。

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

请输入描述

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

相关中间件可参考Cobar(阿里,目前已沒有维护),TDDL(阿里),Atlas(奇虎3300),MyCat。

需求管理传统的做法,会使用用例图或模块图(需求列表)进行需求的描述。那我做常常忽视掉那我很重要的需求(非功能需求),后后推荐一点人儿使用需求功能矩阵,进行需求描述。

4、使用集群改善应用服务器性能

7、可扩展架构

请输入描述

分布式大型网站,目前看主要有几类:

1、最后后刚开始了了的网站架构

除中间介绍的架构主次外,还须要引入敏捷管理,敏捷开发的思想。使业务,产品,技术,运维统同去来,随需应变,快速响应。

6、网站架构优化

缓存实现常见的土方式是本地缓存、分布式缓存。当然还有CDN、反向代理等,你你有一种中间再讲。本地缓存,顾名思义是将数据缓居于应用服务器本地,还后能 居于内存中,也还后能 居于文件,OSCache要是常用的本地缓存组件。本地缓存的特点是带宽快,但完后 本地空间有限太大太大太大太大有缓存数据量后会限。分布式缓存的特点是,还后能 缓存海量的数据,后后扩展非常容易,在门户类网站中常常被使用,带宽按理只能本地缓存快,常用的分布式缓存是Memcached、Redis。

请输入描述

客户要是客户,不想告诉你具体要有哪些,只会告诉你他你要有哪些,一点人儿太大太大太大太大有完后 要引导,挖掘客户的需求。好在提供了明确的参考网站。后后,下一步要进行大量的分析,结合行业,以及参考网站,给客户提供方案。

6.8 一点架构(技术)

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

6.1 业务拆分

根据客户需求:3~5年用户数达到30000万注册用户,还后能 做每秒并发数预估:

伸缩性是居于不改变原有埋点的基础上,通过添加/减少硬件(服务器)的土方式,提高/降低系统的解决能力。

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

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

最初的架构,应用任务管理器、数据库、文件都部署在一台服务器上,如图:

后后,目前主流的网站架构完后 居于了翻天覆地的变化。一般后会采用集群的土方式,进行高可用设计。共要是下面你你有一种样子:

请输入描述

6.6 服务化

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

这时一点人儿发现各个业务应用后会使用到一点基本的业务服务,同类用户服务、订单服务、支付服务、安全服务,有有哪些服务是支撑各业务应用的基本主次。一点人儿将有有哪些服务抽取出来利用分部式服务框架搭建分布式服务。阿里的Dubbo是那我不错的挑选。

随着业务的扩展,一台服务器完后 只能满足性能需求,故将应用任务管理器、数据库、文件每本人部署在独立的服务器上,后后根据服务器的用途配置不同的硬件,达到最佳的性能效果。

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

此处不完整版介绍,一点人儿还后能 问度娘/Google,有完后 得话也还后能 分享给一点人儿。

这是前几年比较传统的做法,完后 见到那我网站十五万多会员,垂直服装设计门户,N多图片。使用了一台服务器部署了应用,数据库以及图片存储。突然出现了太大太大太大太大有性能什么的什么的问题。

6.3 多级缓存

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

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

大型网站应该在任何完后 都还后能 正常访问,正常提供对外服务。完后 大型网站的多样化性,分布式,廉价服务器,开源数据库,操作系统等特点,要保证高可用是很困难的,也要是说网站的故障是不可解决的。

2、应用、数据、文件分离

预估步骤:

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

请输入描述

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

请输入描述

一点人后会每本人的业务底部形态,系统架构后会所不同。尽管只能一点人儿也还后能 从有有哪些不同的网站背景中,找出其中共用的技术,有有哪些技术和手段广泛运用在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识有有哪些技术和手段。

8、安全架构

5、高可用架构

假若一点人儿的服务器都部署在成都的机房,对于四川的用户来说访问是较快的,而对于北京的用户访问是较慢的,这是完后 四川和北京分别属于电信与生通的不同发达地区,北京用户访问须要通过互联路由器经过较长的路径并能访问到成都的服务器,返回路径也一样,太大太大太大太大有数据传输时间比较长。对于你你有一种请况,常常使用CDN解决,CDN将数据内容缓存到运营商的机房,用户访问时先从最近的运营商获取数据,那我大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。

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

那我心智成熟的句子的句子的句子的大型网站(如淘宝、天猫、腾讯等)的系统架构并后会一后后刚开始了了设计时就具备完整版的高性能、高可用、高伸缩等底部形态的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在你你有一种过程中,开发模式、技术架构、设计思想也居于了很大的变化,就连技术人员也从几一点人发展到那我部门甚至每根产品线。

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

大型门户一般是新闻类信息,还后能 使用CDN,静态化等土方式优化,开心网等交互性比较多,后后会引入更多的NoSQL,分布式缓存,使用高性能的通信框架等。电商网站具备以上两类的特点,比如产品详情还后能 采用CDN,静态化,交互性高的须要采用NoSQL等技术。后后,一点人儿采用电商网站作为案例,进行分析。

随着业务进一步扩展,应用任务管理器变得非常臃肿,这时一点人儿须要将应用任务管理器进行业务拆分,如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信完后 共享数据库来实现。

在硬件优化性能的同去,同去也通过软件进行性能优化,在大主次的网站系统中,后会利用缓存技术改善系统的性能,使用缓存主要源于热点数据的居于,大主次网站访问都遵循28原则(即3000%的访问请求,最终落在20%的数据上),太大太大太大太大有一点人儿还后能 对热点数据进行缓存,减少有有哪些数据的访问路径,提高用户体验。

参考部署方案2:

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

3、大型网站架构模式

请输入描述

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

请输入描述

2、电商网站需求

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

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

请输入描述

请输入描述

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

用户一天天增加,业务量只能大,产生的文件太大,单台的文件服务器完后 只能满足需求,这时就须要分布式文件系统的支撑。常用的分布式文件系统有GFS、HDFS、TFS。

请输入描述

7、使用分布式文件系统

需求功能矩阵

如下图:

请输入描述

请输入描述

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

对于海量数据的查询和分析,一点人儿使用NoSQL数据库添加搜索引擎还后能 达到更好的性能。并后会所有的数据后会装进关系型数据中。常用的NoSQL有MongoDB、HBase、Redis,搜索引擎有Lucene、Solr、Elasticsearch。

拆分后的架构图:

6、使用CDN和反向代理提高网站性能

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

请输入描述

10、搭建分布式服务

容量预估:70/90原则

8、使用NoSQL和搜索引擎

请输入描述

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

点赞  分享

目前使用较多的MQ有Active MQ、Rabbit MQ、Zero MQ、MS MQ等,须要根据具体的业务场景进行挑选。建议还后能 研究下Rabbit MQ。

3、利用缓存改善网站性能

2、大型网站架构目标

5、网站架构分析

请输入描述

太大太大太大太大有心智成熟的句子的句子的句子的系统架构是随着业务的扩展而逐步完善的,并后会一蹴而就;不同业务底部形态的系统,会有每本人的侧重点,同类淘宝,要解决海量的商品信息的搜索、下单、支付;同类腾讯,要解决数亿用户的实时消息传输;百度它要解决海量的搜索请求。

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

集群部署后架构图:

5、数据库读写分离和分库分表

6、可伸缩架构

请输入描述

请输入描述

4、系统容量预估

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

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

3、网站初级架构

1、大型网站的特点

请输入描述

请输入描述

本电商网站的需求矩阵如下:

根据业务底部形态可使用以下缓存过期策略:

本文是学习大型分布式网站架构的技术总结。对架构那我高性能、高可用、可伸缩及可扩展的分布式网站进行了概要性描述,并给出那我架构参考。文中一主次为读书笔记,一主次是一点人经验总结,对大型分布式网站架构有较好的参考价值。

6.7 消息队列

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

请输入描述

如上图每个应用单独部署,核心系统和非核心系统组合部署

请输入描述

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

应用服务器作为网站的入口,会承担大量的请求,一点人儿往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求,根据埋点策略将请求埋点到多个应用服务器节点。

客户需求:

请输入描述

1、电商案例的是是因为

4、高性能架构

根据以上预估,有十几只 什么的什么的问题:

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

9、将应用服务器进行业务拆分

请输入描述

请输入描述

流程说明

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

随着用户量的增加,数据库成为最大的瓶颈,改善数据库性能常用的手段是进行读写分离以及分库分表,读写分离顾名思义要是将数据库分为读库和写库,通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分,水平切分则是对那我数据库特大的表进行拆分,同类用户表。垂直切分则是根据业务的不同来切分,如用户业务、商品业务相关的表装进不同的数据库中。

9、敏捷性

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

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

6.4 单点登录(分布式Session)

7、架构汇总

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

而反向代理,则是部署在网站的机房,当用户请求达到时首先访问反向代理服务器,反向代理服务器将缓存的数据返回给用户,完后 只能缓存数据才会继续访问应用服务器获取,那我做减少了获取数据的成本。反向代理有Squid、Nginx。