本议题是我们在OWASP杭州区2013年岁末年初安全沙龙中进行分享的内容，在此我们对这个议题的整体内容进行了重新归纳梳理，形成了文字版。 在本文中，DDoS的案例与应对经验均来自于某市场占有率很高的客服系统所遇到的实际场景，分别从成本、效率和具体架构设计（选型、配置、优化等）角度来分析通过自建CDN来应对不同类型的DDoS攻击。 背景介绍 客服系统的主要业务是提供基于网页的实时动态的文字聊天，主要应用在各类网络商品销售、网站在线客服等领域，总用户数58万，同时在线活跃的用户约12万/天。 这些应用领域通常行业之间的竞争比较激烈，其中包括在线下无法名正言顺的灰色+暴利产业，导致竞争对手之间经常发动DDoS恶意攻击。但营销网站往往是单面加速，加上推广时效性很强，很难被彻底打击，于是一些自作聪明的黑客通过攻击网站的在线客服系统，导致网站无法跟访客沟通，不能交易，从而达到恶意攻击的目的。因此客服系统这个原本有助于网站营销的工具反而成了被攻击的主要对象，虽然伤得委屈，但也不得不面对挑战。 我们遭遇的DDoS攻击类型包括：延缓性的CC攻击和致命的大流量攻击。下面将对两种攻击方式的攻击特点、防御思路和我们用过的一些防御方案进行简单的介绍。 延缓性的CC攻击 攻击特点 攻击者借助网络上提供的大量代理服务器IP，利用攻击软件，生成指向受害主机的合法请求。 这类攻击对攻击者来说成本低，而且网上现成的软件多，攻击的风格相对比较”温柔谨慎”，其目的是通过逐渐增多的垃圾请求，消耗服务器的正常应用开销如CPU,内存,网卡压力，甚至是网络拥堵，然后请求无响应，无出口流量，导致网站变慢，达到网站无法访问的目的。 防御思路 对于这类攻击，有两个漏洞特点可以被我们利用，从而阻止这类恶意的CC攻击，关键是响应一定要快。 第一个特征，由于是人为生成了大量的非法请求，引发网络的incoming流量会异常增大（正常情况下，incoming流量小，outgoing流量大）；第二个特征，攻击力度有一个渐增过程，我们要充分利用这个宝贵的时间，让机器第一时间智能的做出反应，调用日志分析脚本做决策，加以防御或者引流。 具体的方法有多种，这里只列举我们所使用的两种： 使用监控软件的流量监控图来触发日志分析脚本，如图所示（zabbix为例）： 利用bash脚本来统计incoming流量，发现异常时，调用相应日志分析脚本，实现阻击。 #!/bin/bash DEV=$1 # 定义监听网卡 LIMIT=$2 # 定义触发阙值 WARN=$3 #定义报警阙值 TIME=$4 # 定义网卡数据采集频率 mobile_num="13xxxxxxxxxx" # 定义接收报警短信手机号码 LOCK="/tmp/.exchange_proxy.lock" [ -z $DEV ] && echo "$0 ethx limit_band(kbps) warn_limit(kbps) seconds" && exit 0 [ -z $LIMIT ] && LIMIT=800000 # 800 kbps [ -z $WARN ] && WARN=900000 # 900 kbps [ -z $TIME ] && TIME=10 # 10s send_fetion() { #定义飞信报警短信接口 } while : ; do net_flood=`ifconfig $DEV|sed -n "8"p` rx_before=`echo $net_flood|awk '{print $2}'|cut -c7-` sleep $TIME net_flood=`ifconfig $DEV|sed -n "8"p` rx_after=`echo $net_flood|awk '{print $2}'|cut -c7-` rx_result=$[(rx_after-rx_before)/$TIME] over_bw=$[(rx_result-LIMIT)] if [ $over_bw -gt 0 ];then BOOL=`echo "$rx_result>$WARN"|bc` #判断是否为攻击 if [ $BOOL -eq 1 ];then # 确认为攻击，执行策略并发送短信 send_fetion $mobile_num "$STR" else # 流量超标，发送短信，请留意 send_fetion $mobile_num "$STR" fi fi sleep $TIME done 过滤脚本实现原理就是在服务器上启动日志分析机制，在第一时间找出异常的IP、Agent，URL或者其它特征码，从内核层利用iptables对恶意IP进行过滤，在应用层上利用nginx的http关键词进行过滤，直接返回badcode 444进行拦截。 方案缺点 无论是从内核级别还是应用级别，对服务器本身的CPU和内存的依赖度高，如iptables的过滤本身对服务器的CPU压力很大，在阻止IP超过15K个，服务器基本不可用了；Nginx在阻止HTTP请求时，由于nginx会给每个http请求分配内存和处理链规则，内存资源耗尽；随着流量的不断增大和攻击时间的持续，网卡压力也大，资源最终被耗尽。 所以，这个方案治标不治本。 致命的大流量攻击 攻击特点 这种攻击通常以tcp syn，icmp和UDP（尤其是UDP包，单UDP的数据包可以很大）方式为主。客服系统遭遇到的最大的一次为16G的攻击流量，整个机房都被影响到。攻击者通常控制大量肉鸡或者直接勾结IDC里的服务器和带宽资源，对目标进行流量打击。此时流量会快速占满服务器的网络带宽，导致无法响应任何用户请求。 这类攻击需要购买大量带宽资源，对于攻击方来说，成本挺高，但是下手“快狠准”，目的是让网站在短时间内彻底无响应。 由于这类攻击会引起流量陡增，IDC里的流量监控设备也会很明显的察觉到这个现象。IDC通常采取的措施一般是丢车保帅，直接将这个被攻击的IP拉黑名单甚至直接拔线，让攻击对象自杀。这对本应该需要帮助的客户无疑是落井下石，雪上加霜。 防御思路 应付此类流量攻击的防御方式有： 架设硬防火墙 租用高防节点 租用CDN分散目标流量 方案缺点 架设硬防火墙：市面上2G硬防单价在10W左右，集群防御代价更大，虽然硬件级的防御性能较高，但面对流量洪水也是杯水车薪，且副作用也不容小觑。 租用高防节点：高防节点有防御带宽，防御流量，共享独享区分，各个套餐的组合价格相差很大，分流策略也不同，超过高防承诺的流量后，防御失效或者再加钱，但都有性能损耗和副作用。 租用CDN分散目标流量：市面上的CDN提供商都是以流量为收费标准，这对于经常遭受流量攻击的网站来说，反而要为攻击流量买单，这着实让人哭笑不得。 无论是采购的硬件成本和高防资源还是CDN加速，都成本昂贵，闲时资源利用率低，攻击高峰时面对有组织有规模的流量时又捉襟见肘，还伴有副作用（参见绿盟黑洞防火墙的原理），并非长久之计。 处于弱势的被打击方 综上所述，我们无论做哪个抉择都很痛苦。 我们跟发起攻击的人有过长达近一年的交流，目前了解到这是一个非常完整的产业链（上游人员早已身居海外，远程遥控指挥行动，根本无法查处），他们手上控制了大量的攻击资源，并且攻击资源本身就来自于IDC。攻击者为了快速牟利，本身也喜欢和推荐这种直接了当的方式来对目标进行打击，在发动攻击时，他们能够调集到多个IDC的带宽资源来对目标打击（这一现象也折射出了当前国内不规范的IDC管理）。 从这一角度来看，被打击方永远都处于弱势地位，以势单力薄的架构和极其有限的资源，根本无法抵抗强大的集群资源攻击。 我们一直思考一个问题：如果我们持续投入这些资金，危机过去或者若干年后，能给我们留下些什么？因此，我们跳出了单节点防御和租用CDN的思路，综合上述方案的优点，转而自建CDN的方案。 长久之计：自建CDN 自建CDN的好处有几个方面： 旁路做流量清洗（痘痘长在别人脸上最好） 资源充分利用：无攻击的时候，做路由加速，有攻击的时候，做节点切换（一物多用） 随着投入的资金增加，防御DDoS攻击的能力增强（长远规划，资金回报率高） 有关自建CDN具体建设的思路如何，成本多少，我们会在系列的下一篇文章中进行介绍。 作者简介 邵海杨（个人页面），来自杭州Linux用户组。网名“海洋之心”，系统架构师，业余撰稿人，致力于开源软件及前沿科技的研究和探索。 张磊（微博，博客），来自杭州谷歌开发者社区。专注于信息安全技术领域，曾主导多项银行/证券行业网站安全测试和入侵取证分析项目，为四大银行提供安全防护技术支持。目前创业做互联网安全防护     在本系列的第一篇文章中，我们介绍了我们客服系统遇到DDoS攻击的情况，以及我们为什么决定采用自建CDN的方式来解决这个问题的原因。 下面，我们将介绍自建CDN的具体建设规划，主要从以下几个方面进行考量：硬件成本、带宽成本、架构设计、实际部署。 硬件成本 在硬件上，我们选型的需求是在1U的基础上具有强劲的性能，同时性价比要高。 我们选择了（强氧）双子星服务器，其硬件规格为：1U机身+支持双路至强CPU+最大支持48G内存+双千兆网口x2+H3C S1208八口千兆，提供三年质保服务，总价约1.5万。 带宽成本 单线机房的机房和带宽资源，由于不需要经过第三方拉线撮合，直接从运营代理商购买，因此选择余地大，性价比高。以租用电信、联通单线资源为例，每条线独享100M带宽，提供8个IP，有些机房自带硬防，能够防御5G-10G流量。 平均费用，每个节点带宽成本基本在1.6~2.5万/年。 架构设计 CDN架构上要充分体现出抗攻击能力和灵活应变的原则。因此，我们将CDN节点分解成反向代理+缓存加速+攻击防御这三个不同层次的功能结构。 反向代理功能（作用：路由加速，隐藏主节点，负载均衡） 缓存加速功能（作用：静态推送，节省后端主节点带宽） 攻击防御功能（作用：快速解析，匹配过滤恶意攻击） 开源世界里能够担当反向代理及缓存的软件不少，而且各有优劣。作为架构师，要考虑如何选型，我们从性能、功能、配置上来进行比较筛选。   软件名称 性能 功能 过滤规则配置 Squid 不能多核是硬伤，磁盘缓存容量有优势，性能中等 多，支持ACL角色控制，也支持ICP缓存协议 支持外部规则文件读取及热加载，支持热启动 Varnish 多核支持，内存缓存，性能强 够用，不支持集群，支持后端存活检查 不支持外部文件读取，需要转义，支持热启动 Nginx 多核支持，支持代理插件，性能较强 多，通过插件可以充当多角色服务器 不支持外部文件读取，需要转义，支持热启动 ATS 多核支持，磁盘/内存缓存，性能强 够用，支持插件开发，也支持ICP协议 支持外部规则文件读取及热加载，支持热启动，但缺乏文档 HAProxy 多核支持，无缓存，HTTP头支持语法操作，性能强 少，只专注HTTP头部解析和转发功能，支持ACL角色控制，支持后端存活检查 支持外部规则文件读取及热加载，支持热启动，支持会话粘滞和长连接   我们对这三层功能结构分别进行了测试调优及生产线的实践检验，从以下方面评估： HTTP防御性能：HAProxy在应对大流量CC攻击时，做正则匹配及头部过滤时，CPU消耗只占10%~20%。其它软件均狂占CPU资源约90%以上，容易成瓶颈导致整个系统无响应。 反向代理性能：单纯转发效率以内存缓存型的Varnish性能最强，ATS和Nginx次之，考虑大容量缓存因素，ATS也是个不错的选择，但文档缺乏，需要持续关注。Nginx是专门针对C10K的产物，性能不错，配合众多插件，改造性很强。 过滤规则的可配置性：HAProxy，ATS，Squid均支持规则文件读取、ACL定制和热加载、热启动。Nginx则不支持外部文件正则匹配，略差一点，但可塑性强。 因此，综合上述考虑，最终我们采用的架构是HAProxy+Varnish/ATS/Nginx的组合，即防御型反向代理缓存方案，功能角色如下： 前面由HAProxy全力负责动静资源分离，实现会话粘滞，节点负载均衡，故障转移，遇到危急时承担基于Http协议的CC类型攻击防御。 后面为可插拔替换的反向代理缓存引擎：根据生产线上的实际应用场景及缓存对象的容量来决定使用内存型的varnish或者是磁盘型的ats，如果需要定制功能很强（防盗链）的反向代理如Nginx+plugins。 这个组合最大的特点是： 支持外部过滤规则的读取，尤其是关键字符串无需转义，可直接追加到文件中。 支持配置文件热加载生效，都支持reload，服务平滑生效。 可插拔式的缓存组件灵活应对各种业务需求。 部署简单，节点失效/生效切换方便。 LVS缺席：为什么这里没有提及LVS，因为LVS是个重量级、高效稳定的四层转发，不能作七层HTTP协议的识别，但完全可以架设在七层之前。所以，LVS的使用并不会影响网络结构，后续仍然可以想上就上，只是前提要兼顾到LVS的单点故障。 实际部署 最终我们在主节点周围一共部署了8个CDN节点（节点数量根据自身公司实力及实际生产环境要求而灵活调整，此数字仅作参考），这些节点又按照地域划分成了四个大区：北方（以山东，河北为主）、西南（以四川为主）、华东（以宁波，嘉兴为主） 华南（以福建，湖南为主 ）兼顾全国各个省份。 总体成本情况 8个单线加速节点，每个节点100Mx8，8台双子星服务器，总共投资约30W（后续费用只考虑带宽支出，约15W/年），我们应急拨款为10W，每个月CDN预算为2W。 项目进度安排： 1～4个月抓进度：特点是快速部点。这里有个诀窍，前期可以先跟IDC按月或者季度签约，然后通过监控看连续的节点质量，如果节点质量不佳，更换提供商，这样损失不会太大，如果节点质量好，就半年付或者年付，这样就可以保证质量和性价比最高； 5～8个月为完善期：根据预算，有节奏的加点，加带宽，保证带宽的冗余度； 8个月以后为稳定期：根据实际情况保证节点的最大可用性，同时也提升了整体防御能力。 如何做防护策略 开启HAProxy的httplog功能，记录日志。 HAProxy的配置策略： global nbproc 24 pidfile /var/run/haproxy.pid daemon quiet user nobody group nobody chroot /opt/haproxy spread-checks 2 defaults log 127.0.0.1 local5 mode http option forwardfor option httplog option dontlognull option nolinger # reduce FIN_WAIT1 option redispatch retries 3 option http-pretend-keepalive option http-server-close option accept-invalid-http-request timeout client 15s timeout connect 15s timeout server 15s timeout http-keep-alive 15s timeout http-request 15s stats enable stats uri /stats stats realm 53KF\ Proxy\ Status stats refresh 60s stats auth admin:adminxxx listen Web_FB 0.0.0.0:80 option httpchk GET /alive.php HTTP/1.0 acl invalid_referer hdr_sub(referer) -i -f /opt/haproxy/etc/bad_ref.conf acl invalid_url url_sub -i -f /opt/haproxy/etc/bad_url.conf acl invalid_methods method -i -f /opt/haproxy/etc/bad_method.conf block if invalid_referer || invalid_url || invalid_methods acl dyn_host hdr(host) -i -f /opt/haproxy/etc/notcache_host.conf acl static_req path_end -i -f /opt/haproxy/etc/allow_cache_file.conf use_backend img_srv if static_req !dyn_host # acl shaohy acl geek hdr_dom(host) -i 17geek.com use_backend geek if geek # backend shaohy backend geek mode http balance source cookie SESSION_COOKIE insert indirect nocache option tcpka server geek_1 127.0.0.1:81 cookie geek_1 maxconn 10000 weight 8 backend img_srv mode http option tcpka server img_srv 127.0.0.1:88 maxconn 30000 weight 8 Varnish的配置策略： backend h_17geek_com_1 { .host="127.0.0.1"; .port="81"; .connect_timeout=300s; .first_byte_timeout=300s; .between_bytes_timeout=300s; } director geek srv { { .backend=h_17geek_com_1; .weight=3;} } sub vcl_recv { if (req.http.host~"^(www).?17geek.com$"){ set req.backend=geek_srv; if (req.request != "GET" && req.request != "HEAD") { return (pipe); } if(req.url ~ "\.(php|jsp)($|\?)") { return (pass); } else { return (lookup); } } } 对于CC类型的DDoS攻击，通过第一篇当中介绍的监控异常流量的方法依然适用，而且优势更明显，因为： 节点各自承担相应的日志记录，分析日志的系统开销，发现异常请求后直接在haproxy前端做ACL规则 过滤，因此，攻击压力不会传递给后端服务器，保证后端安全。 节点受到的攻击流量过大，机房可以拉黑IP或者引流，后端智能DNS会自动把这个节点剔除，后续请求不要通过此节点。 在本系列的下一篇文章中，我们会介绍这个CDN架构的一些后续改进工作，包括智能DNS、大规模日志分析、利用OpenCDN改善后台管理等。 作者简介 邵海杨，来自杭州Linux用户组。网名“海洋之心”，系统架构师，业余撰稿人，致力于开源软件及前沿科技的研究和探索。 张磊，来自杭州谷歌开发者社区。专注于信息安全技术领域，曾主导多项银行/证券行业网站安全测试和入侵取证分析项目，为四大银行提供安全防护技术支持。目前创业做互联网安全防护  

1.2　弹性计算的价值弹性计算到底解决了什么问题，或者说，它的价值在哪里？一言以蔽之，弹性计算就是要把计算力变成普惠的公共资源，让个人、企业、政府和各种机构——无论体量大小，无论何时何地都能够以亲民的价格享受高可用、高安全、高性能、大容量、高效率的基础IT 计算服务。这种对IT 资源消费门槛的革命性降低，对整个社会的运作效率、运行成本和创新能力的影响都是极其深远的。以前需要经过冗长的采购过程、花费数十万元甚至上千万元的高端服务器，现在每月花几百元至几千元，坐在家里等几十秒就可以用起来了，试想这对于那些初创企业意味着什么？而这只是弹性计算带来的价值的一个小小缩影。下面就让我们细数一下弹性计算带来的价值。1.2.1　高可用和高可靠应用的高可用对于用户的意义不言而喻，没有人想要一台经常宕机的服务器，也没有人想让自己的应用常常不可用。数据的高可靠则更加至关重要，数据丢失了，损失不可估量，有时候对于用户的业务是致命的。弹性计算的高可用和高可靠，可以从产品侧和用户侧来解读。在产品侧，主流云服务提供商都承诺了云服务器的可用性。SLA 单机可用性达到99.975%、跨可用区（Availability Zone，AZ）的多机可用性则达到99.995%。99.975% 意味着一年365 天只有2.19 个小时不可用！这就是弹性计算的担当。阿里云为了实现稳定性世界第一和“永不停机的弹性计算”，做了大量的技术投资和创 新，如：8 高可用的数据中心电力供应：独立双路市电引入、UPS 热备，以及随时待命的柴油发电机，当出现故障时能在一分钟内自动拉起。高可用网络架构：数据中心三路出口光纤，内部双冗余网络架构。百万级服务器智能运维能力：大数据+ 机器学习+ 智能运维闭环体系。阿里云提供的“云盘”形态的块存储产品，采用分布式三副本机制，实现了99.9999999% 的数据可靠性。在用户侧，弹性计算为用户提供了包括部署集、自动恢复、多Region 多AZ 部署、块存储的快照等能力，让用户可以构建高可用性和高可靠性的应用。部署集确保这些云服务器分布在不同的物理服务器甚至机柜上，以规避单台物理服务器的故障带来的影响。自动恢复能力则在探知某台云服务器发生宕机时，将其迁移到另一台物理服务器上重新拉起。多Region 多AZ 部署则为应用提供了终极可用性。Region 即地域，是指一个独立的地理区域，例如截至2019 年9 月，阿里云有华东1（杭州）、华东2（上海）、华南1（深圳）、华北1（青岛）、华北2（北京）、西南1（成都）、中国香港等10 个中国地域，以及亚太东南1（新加坡）、亚太东南2（悉尼）、亚太南部1（孟买）、亚太东北1（东京）、美国东部1（弗吉尼亚比奇）、美国西部1（硅谷）、欧洲中部1（法兰克福）等12 个国际地域。这些地域都部署了弹性计算产品，电力、网络等设施完全独立，并且因为距离相隔远，即使发生地震、台风等天灾，也不会同时都出现问题。而同一个地域又由多个可用区组成。每个可用区也相互独立，包含一个或多个数据中心。同一个地域内的可用区之间使用低时延网络链路相连。地域和可用区的关系如图1-1 所示。用户如果想拥有极致的高容灾能力，则可以在同一个区域的多个可用区，甚至多个地域购买云服务器，再把应用部署在这些高度分布的云服务器上，规避单个可用区或单个地域的大型故障。块存储的快照是其在某一时间点的数据状态文件，可以用作数据备份，在需要时从快照中还原历史数据。快照可以跨可用区多备份存储，提供更高的可靠性保障。 图1-1 　地域与可用区的关系综上可见，公共云上的弹性计算能提供的可用性和可靠性是线下物理服务器望尘莫及的。根据阿里云的测算，阿里云弹性计算提供的云服务器的宕机率仅为线下物理服务器的五分之一以下。1.2.2　更安全一直以来，很多用户对云计算的安全最为担心，但事实上，靠谱的云服务提供商提供的云服务器比用户自己的服务器更安全。用户的担心通常有以下几点： 云服务提供商及其系统、人员会不会偷窥我的应用的信息。由于与其他用户共享了一些物理设备，这些“邻居”会不会盗取我的秘密。黑客们是不是更容易攻击我的云服务器。如果将弹性计算提供的服务比喻为银行提供的存款服务，那么就很容易解释为什么这些担心都是可以消除的。时至今日，几乎没有人会把大把的现金存放在自己家里了，而是存到了银行里。银行是如何赢得用户信任的呢？ 对于第一个担心，为了防止员工监守自盗，银行有非常完善的资金管理体系。任何操作都需要认证和授权，任何交易都有记录，确保可追踪、可审计；现金放在保险柜里，密码或者钥匙掌握在极少数员工手里，当进行重大的操作时通常还需要多人在场，等等。弹性计算与之类似，云服务提供商通常都有一套严格的线上操作管理体系，这些流程、制度和工具自动化的支撑使得云服务提供商能约束自己的员工不越界。当然，云服务提供商自己来声明可能信服力不够，所以很多云服务提供商都通过第三方认证来证明自己是达到合规标准的，这些认证包括MTCS Level3、ISO 20000、ISO 27001、ISO 22301、TRUSTe、Trusted Cloud、CSA STAR Gold 和国家等保四级等。除此之外，弹性计算还提供多种独特的技术手段来进一步保障用户的隐私，例如，允许用户加密自己的块存储里的数据、使用SGX 加密计算、使用TPM 等设备确保可信（系统不能被篡改）的启动过程，等等。对于第二个担心，银行为每个用户设立了独立的账号，账号之间完全独立，这些账号中的资金是互相“隔离”的。弹性计算采用的虚拟机、虚拟网络和存储隔离等技术，从系统设计的源头确保各个用户的“世界”是严格隔离的。再加上给用户提供的加密手段，相当于又上了一道保险——这意味着即便“邻居”看到了物理设备上的裸数据，但如果没有主人的密钥，也无法获得真实的数据。最后，对于部分确实有物理隔离需求的用户（例如需要满足法律的合规要求），云服务提供商还提供了类似独立物理分区的产品形态，例如阿里云的专有宿主机、全托管专有云等，让用户独享物理设备，相当于银行为有需要的用户提供专用的保险箱，实现更高程度的隔离。对于第三个担心，银行金库的安保级别明显是高于个人和企业的金库的，让小偷或者强盗得逞的可能性小很多。对于弹性计算，更加专业的数据中心、更加专业的安全流程、更加专业的安全技术人员和更加专业的安全工具，合在一起达到的安全水准通常要比绝大部分用户自己管理数据中心和服务器高得多。再加上提供给云服务器的各种配套的安全加固功能，例如阿里云提供的DDoS 高防IP 服务，具备防勒索、防病毒、防篡改、合规检查等能力，更是让云服务器的安全锦上添花。总之，作为用户上云的首要前提，安全是云服务提供商必须要满足的承诺。从结果上看，云服务器通常比大多数用户自建的服务器更安全。1.2.3　高性能弹性计算由于广泛采用虚拟化等技术，本身有一定的资源开销，所以以前的云服务器常被人们诟病比物理服务器性能差一些。时至今日，弹性计算的底层技术不断更新换代，不仅其性能突飞猛进，更重要的是，弹性计算为用户提供了各种高性能计算产品的选项，让高性能变得更加平民化。在计算指标上，最新的软硬一体的虚拟化技术让其开销接近于零。像阿里云提供的“神龙弹性裸金属”这样的新生代产品，与物理服务器的计算性能相比，基本已经没有差别了。在存储指标上，使用分布式存储架构的“云盘”块存储产品，其吞吐量和每秒可处理的读写操作数轻松碾压本地SATA 硬盘，与本地NVMe SSD 盘相比也毫不逊色。当然，云盘的时延通常要比物理服务器的本地盘大；但是云服务器也提供了本地盘的选项，对于追求极低时延的存储场景，完全可以选用带本地盘的云服务器。在网络方面，高规格的云服务器可以提供超过25Gbit/s 的带宽，每秒收发包能力达到几百万PPS，甚至上千万。有些云服务提供商还提供了超低延迟的网络选项，例如阿里云的超级计算集群SCC 产品，就支持超高性能的RDMA 协议。此外，由于云服务提供商通常有自己的骨干网并且购买了超大带宽接入多路电信运营商的骨干网， 其可用区之间的互联、接入Internet 的带宽和时延都是一流的。然而，这种指标上简单的比拼并不能反映弹性计算“高性能”真正的价值，因为弹性计算更大的意义在于让公众获得高性能计算力的门槛变得前所未有的低。主流云服务提供商每年都紧跟业界最新的硬件产品，例如Intel 最新的CPU 很快就被搭载在云服务器产品中；存储设备、网络设备每年都升级换代。同时，云服务提供商还提供了各种场景化的高性能计算产品，例如GPU、FPGA，甚至能运行大型超算任务的云超算产品。用户如果自购这些层出不穷、不断翻新的硬件，那么投资将是巨大的。可以说，弹性计算让高性能触手可及。1.2.4　大弹性从广义上讲，弹性让IT 能力能轻松跟上用户的业务发展；从狭义上讲，弹性则带给用户无与伦比的灵活性。广义弹性的价值，意味着“无限索取”的供给能力。IT 计算力已经成为很多业务的支撑性能力。当业务迅猛发展时，如果计算力跟不上，那么业务必然会受到严重的制约。但是计算力的建设并不是一蹴而就的，从地、电、水到机房建造，从数据中心网络铺设到Internet 接入，从服务器选型、定制、采购到部署、上线和运维，从单机房、多机房到跨地域甚至跨大洲，安全性、稳定性、容灾、备份，以及优秀人才的招聘、培训和保有，等等，无一不是耗时、耗力、耗财的事项。而弹性计算的出现， 则让计算力的获取变得简单而从容。图1-2 展示了某云平台用户随着业务的极速扩张所购买的计算力的增长曲线，短短15 个月，计算力需求从零爆发式增长到了数百万核。弹性计算充裕的计算力供给，让用户业务的发展如虎添翼。图1-2 　某云平台用户计算力需求从零迅猛增长到数百万vCPU12 狭义弹性的价值，即灵活性。灵活的弹性是多维度的，涵盖了空间、时间、大小和数量。空间上，弹性计算的多地域多可用区的部署，让用户可以灵活选择其云服务器所在的位置。例如，可以根据其所服务的客户群体所在的国家、省份或城市来就近选择可用区，加快客户的访问速度。时间上，弹性计算全年7×24 小时无休，随时可以购买；同时提供了各种灵活的购买选项，灵活的按量付费方式让用户随时可以释放购买的云服务器。大小上，弹性计算提供了小到0.1 个、1 个vCPU（虚拟CPU），大到100 个以上vCPU 的云服务器规格。更重要的是，用户可以灵活地对云服务器进行升配、降配， 即实现所谓的垂直伸缩（Vertical Scaling）。数量上，弹性计算允许用户根据需要动态地增加或者减少云服务器的数量。这种水平伸缩（Horizontal Scaling）能力非常适合应对短时间的业务高峰，使得用户无须长期维持一个超出日常容量需求的服务器资源池来支持只有几个小时甚至几分钟的高峰期。从图1-3 中可以看到，某云平台用户临时增加了一倍的云服务器容量，来应对春节期间的突发流量。为了让用户更加方便地享受弹性带来的灵活性，弹性计算还提供了一系列工具帮助用户自动进行容量管理，如阿里云提供的弹性伸缩服务（Auto-Scaling Service）、弹性供应（Auto-Provisioning）等。图1-3 　某云平台用户春节期间的计算力需求不难看出，“弹性”绝对是弹性计算的独门绝技，而其背后的终极秘密其实很简单：一个海量用户共享的巨型资源池。共享模式和巨型规模，是单个用户自建IT 基础设施所无法做到的。1.2.5　高效率弹性计算实现了IT 基础资源的供给、管理和运维效率的巨大提升。这种效率的提升，一方面节省了人力和金钱，另一方面关键是节省了时间——而时间对于业务的敏捷性至关重要。首先是计算力的供给效率。以前用户采购服务器的周期至少以周计，甚至以月计；现在用弹性计算购买云服务器是以分钟计，甚至以秒计，真正做到了“呼之即来”。以前想要更改服务器的配置或者进行更新换代，那必是一场持久战；现在用云服务器，只需在控制台进行变配或升级操作，几分钟即可完成。如果只是加个块存储设备或者网卡，则连重启都省了！ 其次是计算力的管理和运维效率。以前用户需要自己安装很多管理工具；现在弹性计算配套的Web 控制台、开放Open API、SDK 等一应俱全，部署、监控、运维等自动化工具唾手可得，几乎所有管理和运维动作都可以用代码驱动。而且，以前极其耗费人力的服务器和网络维护、维修等工作也都消失了，这些对于人效的提升，显而易见。如果使用“无服务器”的容器服务或者函数计算，那么用户需要承担的任务就更少了，资源购买和配置、服务器操作系统维护和升级、容量管理等大量工作都不再需要了。弹性计算带来的高效率，是革命性的。1.2.6　省成本如今IT 已成为各行各业的支柱，所需的开销也越来越大。而弹性计算能全方位降低计算力成本。首先， 弹性计算提供的计算力租赁模式让IT 支出从资本性支出（Capital Expense）变成了运营性支出（Operation Expense）。用户无须再按业务高峰期的容量， 一次性支付大量资金来购买“过量”的IT 设备，而是可以根据每天甚至每小时的实际情况租赁云服务器，按需进行灵活的弹性伸缩，计费周期精确到秒，大大减少了资源闲置造成的成本浪费。其次，弹性计算可以带来IT 效率的极大提升，也就意味着大大降低了IT 相关的人力成本。再次，弹性计算还解决了一个很大的隐性成本，即风险成本。数据中心特别是跨数据中心的高可用、容灾、高性能等设计，最新服务器的选型、适配研发，大规模集群的运维，安全防护，无一不是具有高度技术挑战的工作。如果技术决策失误，用户要承担的投资浪费和业务损失将难以估量。而有实力的云服务提供商通过大量的技术投入、广泛大规模的实践和经验积累，可以规避很多技术风险，带给用户真正经过实践检验的产品。阿里巴巴集团内的所有业务，如淘宝、支付宝、菜鸟物流、优酷、饿了么，等等，本身就是阿里云弹性计算的大规模使用者，他们各种类似双11 的极端场景对云计算的历练是无价的，是任何测试都无法替代的。最后，云服务提供商的规模效益和技术红利也降低了单位计算力的成本，从而可以为用户提供更优惠的价格。弹性计算是典型的规模经济型（Economy of Scale）业务。通过集约化的服务器和关键部件采购、大规模数据中心和网络的建设及运营、统一专业化的集群运维等，云服务提供商不仅能拿到更低的设备采购价格，而且运营成本更低。同时，尖端的研发投入带来的性能优化、利用率提升等技术红利，可以让单位成本进一步降低。弹性计算不仅节省了很多看得见的成本，更节省了一些看不见的成本。