阿里云构建千万级架构演变之路

前言

一个好的架构是靠演变而来,而不是单纯的靠设计。刚开始做架构设计,我们不可能全方位的考虑到架构的高性能、高扩展性、高安全等各方面的因素。随着业务需求越多越多、随着业务访问压力越多越大,架构不断的演变及进化,因而造就了一个成熟稳定的大型架构。如淘宝网、如Facebook等大型网站的架构,无不从一个小型规模架构,不断进化及演变成为一个大型网站架构。

随着云计算的到来,当前已经从IT时代向DT时代开始转型。在云端如何构建千万级架构,本文主要结合阿里云最佳实践经验,向大家分享如何从一个小型网站逐步演变到千万级架构的过程。

架构原始阶段:万能的单机

架构的最原始阶段,即一台ECS服务器搞定一切。传统官网、论坛等应用,只需要一台ECS。对应的web服务器、数据库、静态文件资源等,部署到一台ECS上即可。一般5万pv到30万pv访问量,结合内核参数调优、web应用性能参数、数据库调优,基本上能够稳定的运行。
架构采用单台ECS:

阿里云构建千万级架构演变之路_第1张图片
万能的单机

架构基础阶段:物理分离web和数据库

当访问压力达到50万pv到100万pv的时候,部署在一台服务器上面的web应用及数据库等服务应用,会对服务器的CPU/内存/磁盘/带宽 等系统资源进行竞争。显然单机已经出现性能瓶颈。我们将web应用和数据库物理分离单独部署,解决对应性能问题。
架构采用ECS+RDS:

阿里云构建千万级架构演变之路_第2张图片
物理分离web和数据库

架构动静分离阶段:静态缓存 + 文件存储

当访问压力达到100万pv到300万pv的时候,我们看到前端web服务出现性能瓶颈。大量的web请求被堵塞,同时服务器的CPU、磁盘IO、带宽都有压力。这时候我们一方面将网站图片、js、css、html及应用服务相关的文件存储在oss中,另外一方面通过CDN将静态资源分布式缓存在各个节点实现“就近访问”。通过将动态请求、静态请求的访问分离(“动静分离”),有效解决服务器在磁盘IO、带宽方面的访问压力。
架构采用CDN + ECS + OSS + RDS:

阿里云构建千万级架构演变之路_第3张图片
静态缓存 + 文件存储

架构分布式阶段:负载均衡

当访问压力达到300万pv到500万pv的时候,虽然“动静分离“有效分离了静态请求的压力,但是动态请求的压力已经让服务器”吃不消“。最直观的现象是,前端访问堵塞、延迟、服务器进程增多、cpu100%,并且出现常见502/503/504的错误码。显然单台web服务器已经满足不了需求,这里需要通过负载均衡技术增加多台web服务器(对应ECS可以选择不同可用区,进一步保障高可用)。因而告别单机的时代,转变分布式架构的阶段。
架构采用CDN+SLB + ECS + OSS + RDS:

阿里云构建千万级架构演变之路_第4张图片
负载均衡

架构数据缓存阶段: 数据库缓存

当访问压力达到500万pv到1000万pv,虽然负载均衡结合多台web服务器,解决了动态请求的性能压力。但是这时候我们发现,数据库出现压力瓶颈,常见的现象就是RDS的连接数增加并且堵塞、CPU100%、IOPS飙升。这个时候我们通过数据库缓存,有效减少数据库访问压力,进一步提升性能。
架构采用CDN+SLB +ECS +OSS + 云数据库memcache +RDS :

阿里云构建千万级架构演变之路_第5张图片
数据库缓存

架构扩展阶段:垂直扩展

当访问量达到1000万pv到5000万pv,虽然这个时候我们可以看到通过分布式文件系统OSS已经解决了文件存储的性能问题,虽然通过CDN已经解决静态资源访问的性能问题。但是当访问压力再次增加,这个时候web服务器和数据库方面依旧是瓶颈。在此我们通过垂直扩展,进一步切分web服务器和数据库的压力,解决性能问题。
“何为垂直扩展,按照不同的业务(或者数据库)切分到不同的服务器(或者数据库)之上,这种切分称之为垂直扩展。”

垂直扩展第一招:业务拆分
在业务层,可以把不同的功能模块拆分到不同的服务器上面进行单独部署。比如,用户模块、订单模块、商品模块等,拆分到不同服务器上面部署。

垂直扩展第二招:读写分离
在数据库层,当结合数据库缓存,数据库压力还是很大的时候。我们通过读写分离的方式,进一步切分及降低数据库的压力。

垂直扩展第三招:分库
结合业务拆分、读写分离,在数据库层,比如我们同样可以把用户模块、订单模块、商品模块等。所涉及的数据库表:用户模块表、订单模块表、商品模块表等,分别存放到不同数据库中,如用户模块库、订单模块库、商品模块库等。然后把不同数据库分别部署到不同服务器中。

架构采用CDN+SLB +ECS +OSS+ 云数据库memcache + RDS读写分离:

阿里云构建千万级架构演变之路_第6张图片
垂直扩展

架构分布式+大数据阶段:水平扩展

当访问量达到5000万pv及以上时,当真真达到千万级架构以上访问量的时候,我们可以看到垂直扩展的架构也已经开始“山穷水尽”。比如,读写分离仅解决读的压力,面对高访问量,在数据库“写”的压力上面“力不从心”,出现性能瓶颈。另外,分库虽然将压力拆分到不同数据库中。但单表的数据量达到TB级别以上,显然已经达到传统关系型数据库处理的极限。

水平扩展第一招:增加更多的web服务器
通过业务垂直拆分分布部署在不同服务器后,当后续压力进一步增大,增加更多的webserver进行水平扩展。

水平扩展第二招:增加更多的SLB
单台SLB也存在单点故障的风险,及SLB也存在性能极限,如QPS最大值为50000。通过DNS轮询,将请求轮询转发至不同可用区的SLB上面,实现SLB水平扩展。

水平扩展第三招:采用分布式缓存
虽然阿里云memcache内存数据库已经是分布式结构,但是同样单一的入口也存在单点故障的风险可能。并且也存在性能极限,如最大吞吐量峰值为512Mbps。所以我们部署多台云数据库memcache版,可以在代码层通过hash算法将数据分别缓存至不同的云数据库memcache版中。

水平扩展第四招:sharding + nosql
面对高并发、大数据的需求,传统的关系型数据库已不再适合。需要采用DRDS(mysql sharding分布式解决方案) + OTS(基于列存储的分布式数据库)对应的分布式数据库来根本性的解决问题。

架构采用CDN+DNS轮询+SLB +ECS+OSS + 云数据库memcache+DRDS+OTS:

阿里云构建千万级架构演变之路_第7张图片
水平扩展

我为自己带盐,原创作者:乔锐杰

你可能感兴趣的:(阿里云构建千万级架构演变之路)