免费注册
登录
中国站
登录社区
?云头条
?博客
?问答
?聚能聊
?直播
?论坛
?云栖大会
?公众号
?订阅NEW
?云大学
?更多
1.云栖社区>
2.博客列表>
3.正文
【技术干货】阿里云构建千万级别架构演变之路
驻云科技2016-06-16 17:01:21 浏览11342 评论2
摘要：随着云计算的到来，当前已经从IT时代向DT时代开始转型。在云端如何构建千万级架构，本文主要结合阿里云最佳实践经验，向大家分享如何从一个小型网站逐步演变到千万级架构的过程。
本文作者：乔锐杰，现担任上海驻云信息科技有限公司运维总监/架构师。曾任职过黑客讲师、java软件工程师/网站架构师、高级运维、阿里云架构师等职位。维护过上千台服务器，主导过众安保险、新华社等千万级上云架构。在云端运维、分布式集群架构等方面有着丰富的经验。
前言
一个好的架构是靠演变而来，而不是单纯的靠设计。刚开始做架构设计，我们不可能全方位的考虑到架构的高性能、高扩展性、高安全等各方面的因素。随着业务需求越来越多、业务访问压力越来越大，架构不断的演变及进化，因而造就了一个成熟稳定的大型架构。如淘宝网、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（mysqlsharding分布式解决方案） + OTS（基于列存储的分布式数据库）对应的分布式数据库来根本性的解决问题。
架构采用CDN+DNS轮询 + SLB + ECS + OSS + 云数据库memcache + DRDS+OTS：
杜绝抄袭，支持开源，我为自己呐喊，百分百原创作者：乔锐杰
好啦~本文到这里就结束了，同时，如果喜欢我们的话就赶紧订阅我们吧~~~每天定时推送新鲜干货~~~也可以关注我们的微信公众号：架构云专家频道每天同步更新哟~~~
版权声明：本文内容由互联网用户自发贡献，版权归作者所有，本社区不拥有所有权，也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：yqgroup@https://www.doczj.com/doc/9c307087.html,进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。
用云栖社区APP，舒服~
【云栖快讯】中办国办印发《推进互联网协议第六版（IPv6）规模部署行动计划》加快推进基于 IPv6 的下一代互联网规模部署，计划指出2025年末中国 IPv6 规模要达到世界第一,阿里云也第一时间宣布了将全面提供IPv6服务，那么在全面部署 IPV6 前，你需要了解都在这儿详情请点击
(13)(23)
分享到:
?上一篇：【技术干货】前端开发之IONIC移动端开发
?下一篇：【技术干货】浏览器工作原理和常见WEB攻击（上）
相关文章
?【云栖精选7月刊】抛开晦涩的算法、模型，让我们来谈谈互联…
?APMCon2017 | 一大波技术大神来袭，你要的性能…
?SDCC 2016 中国软件开发者大会盛大开幕
?映客直播技术实战：直播平台的数据库架构演变
?首届中国IT架构大师高峰论坛（十年架构之路汇成一句话！）
?解析日活从0到千万的数据库架构演进，揭秘阿里自研数据库原…?避免单点，云上应如何实现网站高可用和高性能架构设计（系列…?【云周刊】第137期：阿里知识图谱首次曝光：每天千万…
?阿里workshop北京站丨打造千万用户海量视频网站，不…
?【云周刊】第129期：探秘！双11背后的基础设施支撑网友评论
1F
萨瓦迪康2016-06-17 10:46:03
赞
00
2F
iwenfeng2017-05-09 11:06:22
如何让公司膨胀到需要最后的架构我的运营之道
阿里云办公
阿里绿网
阿里聚安全
云服务器ECS
?程序员中年危机，大家应该如何提升自己的技能
浙公网安备 33010002000099号
免费注册 登录 中国站 登录社区 ?云头条 ?博客 ?问答 ?聚能聊 ?直播 ?论坛 ?云栖大会 ?公众号 ?订阅NEW ?云大学 ?更多 1.云栖社区>
2.博客列表> 3.正文 【技术干货】阿里云构建千万级别架构演变之路 驻云科技2016-06-16 17:01:21 浏览11342 评论2 摘要：随着云计算的到来，当前已经从IT时代向DT时代开始转型。在云端如何构建千万级架构，本文主要结合阿里云最佳实践经验，向大家分享如何从一个小型网站逐步演变到千万级架构的过程。 本文作者：乔锐杰，现担任上海驻云信息科技有限公司运维总监/架构师。曾任职过黑客讲师、java软件工程师/网站架构师、高级运维、阿里云架构师等职位。维护过上千台服务器，主导过众安保险、新华社等千万级上云架构。在云端运维、分布式集群架构等方面有着丰富的经验。
前言 一个好的架构是靠演变而来，而不是单纯的靠设计。刚开始做架构设计，我们不可能全方位的考虑到架构的高性能、高扩展性、高安全等各方面的因素。随着业务需求越来越多、业务访问压力越来越大，架构不断的演变及进化，因而造就了一个成熟稳定的大型架构。如淘宝网、Facebook等大型网站的架构，无不从一个小型规模架构，不断进化及演变成为一个大型网站架构。 随着云计算的到来，当前已经从IT时代向DT时代开始转型。在云端如何构建千万级架构，本文主要结合阿里云最佳实践经验，向大家分享如何从一个小型网站逐步演变到千万级架构的过程。 架构原始阶段：万能的单机 架构的最原始阶段，即一台ECS服务器搞定一切。传统官网、论坛等应用，只需要一台ECS。对应的web服务器、数据库、静态文件资源等，部署到一台ECS上即可。一般5万pv到30万pv访问量，结
阿里云大数据计算平台的自动化、精细化运维之路 本文章来自于阿里云云栖社区 摘要：作者简介：范伦挺阿里巴巴基础架构事业群-技术专家花名萧一，2010年加入阿里巴巴，现任阿里巴巴集团大数据计算平台运维负责人。团队主要负责阿里巴巴各类离在线大数据计算平台（如MaxCompute、Analytic DB、StreamComput 免费开通大数据服务：https://https://www.doczj.com/doc/9c307087.html,/product/odps 作者简介： 范伦挺 阿里巴巴基础架构事业群-技术专家 花名萧一，2010年加入阿里巴巴，现任阿里巴巴集团大数据计算平台运维负责人。团队主要负责阿里巴巴各类离在线大数据计算平台（如MaxCompute、AnalyticDB、StreamCompute等）的运维、架构优化及容量管理等
1、前言 本文主要会从以下四个方面来写，分别是： 阿里大规模计算平台运维面临的一些挑战； 阿里自动化平台建设； 数据精细化运维； 我对运维转型的思考和理解； 2、在阿里我们面对的挑战 在讲挑战之前，我们可以简单看一下阿里大数据平台演进历史，我们的MaxCompute（原ODPS）平台是2011年4月上线的，2013年8月份单集群超过5K，2015年6月单集群超10K，目前在进行异地多活和离在线混布方面的事情。
首先是规模大、小概率事件常态化 对于小概率事件大家不能赌运气，基本每次都会踩中狗屎的。譬如各类硬件故障，规模小的时候觉得硬件故障概率比较低，即使坏了也比较彻底，但是规模大了后会有很多情况是将坏不坏，类似这种奇葩事件会越来越多。 还有网络链路不稳定，网络链路会有很多原因导致它不稳定。一方面是网络设备多了，网络设备出现故障的概率也大了，另一方面运营商日常割接、挖掘机施工等都会对我们带来挑战。 还有一部分是工具，机器的环境变得复杂以后，我们对工具稳定性就有更高要求，比如你要考虑到有些机器的SSH 会hang 住，还有某些机器yumdb是坏的，不能想当然的以为一条命令下去一定会执行成功。 其次是多机房多地域 几千公里距离会有几十毫秒的延时增加，大家在布置异地多机房应用的时候，要考虑到应用之间的超时设置是不是合理，需要重新review 尤其针对多次往返的请求，累加效应是非常明显的。
袋鼠云出品——阿里云高可用-容灾解决方案 这两天，一篇名为《IT之家因无法忍受阿里云而迁移至XX云》的文章引起了整个云计算行业的热议。（袋鼠云CTO江枫还专门写了一篇热评） 从目前得到的信息看，其应该是在青岛区域购买了一台云服务器ECS，基于.net和自建SQL Server，并且应用和数据库跑在同一台云服务器上。 IT之家，所有应用都部署在单台ECS上，不具备高可用的特性。 即便阿里云产品本身就有容灾、高可用的特征，但是因为一些用户对阿里云产品的不了解和自身应用架构不够合理，也根本无法使其发挥该优势。 其实，IT之家的事情不是个例，有很多其他企业在这方面很头疼。 所以，袋鼠云技术专家结合以往实践经验，总结出了一套切实可行的《阿里云高可用-容灾解决方案》，希望能和各位阿里云上用户一起探讨。 一、阿里云产品容灾-高可用介绍 1、SLB 容灾-高可用介绍 阿里云SLB产品使用开源软件LVS＋keeplived实现4层的负载均衡。 采用淘宝的Tengine实现7层的负载均衡。所有负载均衡均采用集群部署，集群之间实时会话同步，以消除服务器单点，提升冗余，保证服务稳定。在各个地域采用多物理机房部署，实现同城容灾。 SLB在整体设计上让其可用性高达99.99%。且能够根据应用负载进行弹性扩容，在任意一台SLB故障或流量波动等情况下都能做到不中断对外服务。
图一 2、ECS 容灾-高可用介绍 云服务器ECS实例是一个虚拟的计算环境，包含了CPU、内存、操作系统、磁盘、带宽等最基础的服务器组件，是ECS提供给每个用户的操作实体，就如同我们平时使用的虚机。 但需要确认的是，ECS自身是没有容灾和高可用方面的功能。 所以当我们在单台ECS服务器上部署各种应用时，特别是对于那些将应用服务，数据库服务等都打包安装在单台ECS服务器时就更要注意这点了。 那ECS自身没有容灾-高可用这样的功能，对于在单台ECS上部署各种服务，一旦ECS 故障就只能眼睁睁的看着它down机对外停止服务么？ 此时，如果产品自身没有容灾和高可用功能，我们可以从架构上来弥补这个短板。 比如：在应用前端购买SLB产品，后端相同应用部署至少两台ECS服务器，或者是使用阿里云的弹性伸缩技术，根据自定义ECS自身资源的使用规则来进行弹性扩容。这样即便其中一台ECS服务器down机或者资源利用超负荷，也不会使我们的服务对外终止。 ECS具备的一些优势： 稳定性：服务可用性高达99.95%，数据可靠性高达99.9999999%。