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

一个好的架构是靠演变而来;而不是单纯的靠设计。刚开始做架构设计;我们不可能考虑到架构的高性能;高扩展;高安全等各方面的因素。随着业务需求越来越多;业务的访问压力也越来越大;架构也在不断的演变及进化。

一; 架构的原始阶段
　　　　万能的单机
架构的最原始阶段;即一台ECS;Elastic Compute Service弹性计算服务;服务器搞定一切。对应的web服务;db;静态文件资源都部署到同一台ECS上就ok。
一般5万-30w的pv访问量;结合系统内核参数调优;web应用的性能参数调优;数据库调优;基本上能为稳定的运行

PV(访问量);即Page View, 即页面浏览量或点击量;用户每次刷新即被计算一次。UV(独立访客);即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。IP(独立IP);指独立IP数。00:00-24:00内相同IP地址之被计算一次。

二;架构基础阶段

web应用;数据库应用 物理分离
当访问量达到50万-100万pv的时候;部署在一台服务器上的web应用和数据库应用;会对服务器的cpu;内存;磁盘IO;带宽等系统资源进行竞争。;产生资源竞争;。这时候就出现了瓶颈。
解决方案;
　　　　将web应用和数据库应用进行物理隔离;单独部署。来解决性能问题

采用ECS;RDS模式

三; 架构动静分离阶段

静态缓存;文件存储　
　　　　通过将动态请求和静态请求的访问分离;有效解决服务器的cpu;内存 磁盘IO;以及带宽压力
当访问量到100万-300万pv的时候;这时候前端web服务出现性能瓶颈。大量的web请求阻塞;同时服务器的cpu;内存;磁盘IO;带宽都有压力。

解决方案;
　　　　1 将网站的静态资源 存储在oss上;静态资源包括;网站图片;html;js;css文件;
　　　　2 通过cdn将静态资源分布式缓存在各个节点上实现“”就近访问“”
　　　　架构采用;CDN;ECS;OSS;RDS

四; 架构分布式阶段 负载均衡

当访问量达到300万-500万pv的时候;虽然“”动静分离“”有效分离了静态请求的压力;但是动态请求的压力已经让服务器吃不消了。最直观的现象是;
瓶颈;
　　1 前端访问阻塞;延迟;服务器进程增多;cpu100%
　　2 出现常见的502,503 504 的错误码
单台web服务器已经无法满足需求;需要通过负载均衡技术增加多台web服务器;对应ECS可以选择不同可用区;进步一保障高可用; 告别单机时代;转变为分布式架构阶段
解决方案;
　　架构采用;CDN;SLB;;ECS1;ECS2;;;;;OSS;RDS

五; 架构数据缓存阶段

数据库缓存

当访问量到500万-1000万pv的时候

虽然负载均衡;多台ECS解决了动态请求的性能压力;但是这时候我们发现;数据库出现了
瓶颈:
　　1 RDS的连接数增加 并且阻塞;
　　2 cpu100% IO PS 飙升
解决方案;
　　通过数据库缓存;有效减少数据库访问压力;进一步提升性能
架构采用;
　　CDN;SLB;;ECS1;;;;;OSS;云数据库memchace;或者redis;;RDS

六; 架构扩展阶段

垂直扩展
当访问量到1000万-5000万pv。虽然这个时候我们可以看到通过分布式文件系统OSS已经解决了文件存储的性能问题
cdn也解决了静态资源访问的性能问题。但是当访问量再次增加;这个时候web服务器和数据库方面依然是瓶颈。
解决方案;
　　在此;我们通过垂直扩展;进一步切分web服务器和数据库的压力;解决性能问题
　　“”垂直扩展“”;按照不同的业务;或者数据库;;切分到不同的服务器;数据库;上;这种切分叫垂直扩展
垂直扩展第一招; 业务拆分
在业务层;可以把不同的功能模块拆分到不同的服务器上进行单独部署。比如;用户模块;订单模块;商品模块等;拆分到不同的服务器上部署
垂直扩展第二招;数据库读写分离
在数据库层;当结合结合数据库缓存;数据库压力还是很大的时候;我们可以通过读写分离的方式;进一步切分及降低数据库的压力
垂直扩展第三招;分库;分表
我们可以把用户模块;订单模块;商品模块分别存放到不同的数据库中;如用户模块库;订单模块库;商品模块库
架构采用;
　　　　CDN;SLB;;ECS;;);OSS;云数据库memcache;redis;;RDS读写分离

七;架构分布式;大数据阶段;水平扩展

当访问量达到5000万pv以及以上的时候;垂直扩展的框架也已经开始“”山穷水尽了“”

瓶颈;

1 读写分离仅解决 读 的压力; 面对高访问量的时候;数据库在“”写“”的压力上面“”力不从心了“”;

2 分库虽然将压力拆分到不同的数据库中。但单表达到TB级别以上;显然已经达到传统关系型数据库处理的极限

水平扩展第一招; 增加更多的web服务器

通过业务垂直拆分部署在不同的服务器后;当后续压力进一步增大;增加更多的webservice 进行水平扩展

水平扩展第二招;增加更多的SLB

单台SLB也存在单点故障的风险;即slb也存在性能极限;如qps最大值5w;通过DNS轮询;将请求轮询转发至不同可用区的SLB上面;实现SLB水平扩展

水平扩展第三招;采用分布式缓存

单台存在性能极限 ;最大吞吐峰值为512Mbps

我们可以部署多台memcache;在代码层通过hash算法将数据分别缓存至不同的云数据库中

水平扩展第四招; sharding;nosql

面对高并发;大数据的需求;传统的关系型数据库已不在适用。

采用; DRDS;mysql sharding 分布式解决方案;;OTS;基于列存储的分布式数据库; 对应的分布式数据库来根本性的解决问题。

架构采用CDN;DNS轮询;SLB;ECS;OSS;云数据库memcache;DROS;OTS;现在已更名为表格存储Table Store;