MYR00
一个好的架构是靠演变而来，而不是单纯的靠设计。刚开始做架构设计，我们不可能全方位的考虑到架构的高性能、高扩展性、高安全等各方面的因素。随着业务需求越来越多、业务访问压力越来越大，架构不断的演变及进化，因而造就了一个成熟稳定的大型架构。如淘宝网、Facebook等大型网站的架构，无不从一个小型规模架构，不断进化及演变成为一个大型网站架构。
随着云计算的到来，当前已经从IT时代向DT时代开始转型。在云端如何构建千万级架构，本文主要结合自身的最佳实践经验，向大家分享如何从一个小型网站逐步演变到千万级架构的过程。
架构原始阶段：万能的单机
架构的最原始阶段，即一台ECS服务器搞定一切。传统官网、论坛等应用，只需要一台ECS。对应的web服务器、数据库、静态文件资源等，部署到一台ECS上即可。一般5万pv到30万pv访问量，结合内核参数调优、web应用性能参数调优、数据库调优，基本上能够稳定的运行。
架构采用单台ECS：
架构基础阶段：物理分离web和数据库
当访问压力达到50万pv到100万pv的时候，部署在一台服务器上面的web应用及数据库等服务应用，会对服务器的CPU/内存/磁盘/带宽等系统资源进行竞争。显然单机已经出现性能瓶颈。我们将web应用和数据库物理分离单独部署，解决对应性能问题。这里的架构采用ECS+RDS：
架构动静分离阶段：静态缓存 + 文件存储
当访问压力达到100万pv到300万pv的时候，我们看到前端web服务出现性能瓶颈。大量的web请求被堵塞，同时服务器的CPU、磁盘IO、带宽都有压力。这时候我们一方面将网站图片、js、css、html及应用服务相关的文件存储在oss中，另外一方面通过CDN将静态资源分布式缓存在各个节点实现“就近访问”。通过将动态请求、静态请求的访问分离（“动静分离”），有效解决服务器在磁盘IO、带宽方面的访问压力。
架构采用CDN + ECS + OSS + RDS：
架构分布式阶段：负载均衡
当访问压力达到300万pv到500万pv的时候，虽然“动静分离”有效分离了静态请求的压力，但是动态请求的压力已经让服务器“吃不消”。最直观的现象是，前端访问堵塞、延迟、服务器进程增多、cpu100%，并且出现常见502/503/504的错误码。显然单台web服务器已经满足不了需求，这里需要通过负载均衡技术增加多台web服务器（对应ECS可以选择不同可用区，进一步保障高可用）。因而告别单机的时代，转变分布式架构的阶段。
架构采用CDN+SLB + ECS + OSS + RDS：
架构数据缓存阶段：数据库缓存
当访问压力达到500万pv到1000万pv，虽然负载均衡结合多台web服务器，解决了动态请求的性能压力。但是这时候我们发现，数据库出现压力瓶颈，常见的现象就是RDS的连接数增加并且堵塞、CPU100%、IOPS飙升。这个时候我们通过数据库缓存，有效减少数据库访问压力，进一步提升性能。
架构采用CDN+SLB +ECS +OSS + 云数据库memcache +RDS ：
当访问量达到1000万pv到5000万pv，虽然这个时候我们可以看到通过分布式文件系统OSS已经解决了文件存储的性能问题，CDN也已经解决静态资源访问的性能问题。但是当访问压力再次增加，这个时候web服务器和数据库方面依旧是瓶颈。在此我们通过垂直扩展，进一步切分web服务器和数据库的压力，解决性能问题。
“何为垂直扩展，按照不同的业务（或者数据库）切分到不同的服务器（或者数据库）之上，这种切分称之为垂直扩展。”
垂直扩展第一招：业务拆分
在业务层，可以把不同的功能模块拆分到不同的服务器上面进行单独部署。比如，用户模块、订单模块、商品模块等，拆分到不同服务器上面部署。
垂直扩展第二招：读写分离
在数据库层，当结合数据库缓存，数据库压力还是很大的时候。我们通过读写分离的方式，进一步切分及降低数据库的压力。
垂直扩展第三招：分库
结合业务拆分、读写分离，在数据库层，比如我们同样可以把用户模块、订单模块、商品模块等。所涉及的数据库表：用户模块表、订单模块表、商品模块表等，分别存放到不同数据库中，如用户模块库、订单模块库、商品模块库等。然后把不同数据库分别部署到不同服务器中。
架构采用CDN+SLB +ECS +OSS+ 云数据库memcache + RDS读写分离：
架构分布式+大数据阶段：水平扩展
当访问量达到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：
云计算那些事儿
当今技术的发展日新月异，系统架构也跟随技术的发展不断升级和改进，从传统的单一架构演变为如今的微服务分布式架构，我们来看看技术架构的演变过程。
NO.1 初期网站架构
网站建设初期，访问人数有限，数据量不大，只需要一台服务器足矣，这时应用程序、文件、数据库等所有资源全部集中在这台服务器上，网站架构请看下图：
![]()
NO.2 应用和数据分离
随着网站业务的不断发展，一台服务器已经不能满足要求，用户访问量越来越大，数据量也越来越大，此时对网站的要求也逐渐变大，这就需要将应用和数据分离，变成应用服务器、文件服务器和数据库服务器。架构图如下：
![]()
NO.3 缓存数据以改善网站性能
随着用户逐渐的不断增加，数据库访问压力变大，导致访问延迟，性能较低，这时就需要缓存技术，将查询较多或者改动不大的数据缓存起来，以加快应用访问速度，下面是基本的架构图：
![]()
NO.4 应用集群
在网站访问高峰，并发量大的情况下，应用服务器就成为了整个网站的瓶颈，单一的应用服务器资源有限，高并发情况下连接很快就会超限，这时，我们就需要部署应用服务器集群，利用负载均衡器分散访问流量，减少单台服务器的压力，网站架构图如下：
![]()
NO.5 数据库读写分离
这个阶段，数据继续增加，请求数量继续加大，单个数据库已然不能满足要求，这个时候需要部署多个数据库进行读写分离，请看架构图：
![]()
NO.6 部署 CDN 节点
用户访问量的增加意味着用户地域的分散请求，如果所有请求都直接发送中心服务器的话，距离越远，响应速度越差，这时就需要用到 CDN 技术，通过 CDN 加速，保证用户访问每次都从最近的服务器获取数据，架构图如下：
![]()
NO.7 分布式数据库
分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。
不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上，如下图所示：
![]()
NO.8 使用非关系型数据库
当网站数据足够庞大，达到PB甚至更高时，关系型数据库已经达到瓶颈，这时就需要考虑采用非关系型数据库了，请看下图：
![]()
NO.9 微服务架构
随着网站业务的不断扩大，我们需要将各个业务进行拆分，形成不能的产品线，每个产品线由不同的业务团队负责，各个产品之间需要通信，这时就要用到微服务架构，请看下图：
![]()
目前，最流行的 JavaEE 框架就是 Spring 框架，该框架是最古老也就是最成熟的 Java 技术框架之一。
为了适应技术的高速发展，Spring Cloud 出现了，它的出现带给了我们微服务的解决方案。
通过 Spring Cloud，我们很容易部署一套高性能高可用的微服务架构。
青莲网络云服务
我这里写了一篇关于我们公司系统架构从0～1的架构演变情况，希望能对您有所借鉴
https://m.toutiaocdn.com/i6624862486354985476/?iid=51515366066&app=news_article×tamp=1542766033&group_id=6624862486354985476&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share&from=singlemessage
關鍵字:
架构
演变
科技
