emu in blogjava
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  171 随笔 :: 103 文章 :: 1052 评论 :: 2 Trackbacks
用腾讯云优化一个公益论坛
@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); @import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); @import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); 〇、背景

       几年前由于发起寻亲项目的关系，和B网站开展了合作。B网站是国内最大的寻亲网站，几年来通过该网站和家人团聚的案例已经达到1397例。B论坛是网站中最活跃的板块。当时论坛遇到一些不稳定的情况，因为B论坛是用Discuz！搭建的，而Discuz！当时刚好被腾讯收购，要获得专业支持相对容易，我们开始把B论坛迁移到腾讯云上面，由Discuz！的志愿者协助维护直到去年底离职，把论坛的管理权限交给我。

一、论坛出问题了

      我不对于php和linux都不熟，交接后看到论坛工作还算正常，也很长一段时间没有去关注，直到前几天，网站管理员突然发来了这个：




这是什么鬼？臣妾不懂啊……只好硬着头皮登上服务器去看看。



还好，大概可以猜到出什么事了：数据盘不够用了。那应该很好解决吧？扩数据盘？

二、COS

用腾讯云服务器而不是自己买服务器的一个好处就是，很多资源可以按需用，按需扩，包括硬盘。不过有个限制就是，买服务器的时候系统盘和数据盘都必须要买“云硬盘”而不能用本地盘。买云硬盘还有个附加的好处是可以申请开通硬盘快照功能，迁移复制服务器唰唰的。

但是云硬盘的性能跟本地硬盘是有差距的，处于性能考虑，志愿者选择了性能更好的本地硬盘，这样就导致硬盘满了以后没有办法扩了。几年来，寻亲的网友们每天上传大量的高清图片线索，终于在世纪寒流这几天把硬盘挤爆了。



不过扩硬盘本来也不是最佳选择，比扩硬盘更好的选择是：不用硬盘！

腾讯云为这种UGC文件提供的解决方案是COS（Cloud Object Service） ，当前版本是COS3.0。COS 大概的意思就是，你有一大堆文件（比如网站用户上传的照片），只知道量很大，不知道有多少，不但需要找个地方存着，还随时有可能需要在某个网页上引用它。那么平台提供一个服务器让你把文件放上去，并提供web访问和API上传和管理接口，你就不用把文件传到自己服务器了。

个人认为使用COS的好处是：
1 能够提供几乎无限量的文件存储空间，按存储量和访问量收费
2 很大的免费额度：50G的免费空间，每计费周期内10G的回源流量，每计费周期内100万次的免费访问次数（实际上COS通常在CDN后面提供服务，因此实际上每个计费周期可以提供10G和100万次回源服务，配合恰当的CDN缓存策略，已经可以满足很大的访问量）。
因此用cos不但从此不用纠结容量爆仓的问题，也不用为没有使用到的容量预先买单花冤枉钱，而且还不用自己的服务器的硬盘和网卡来扛这些流量，服务器的带宽和硬盘I/O压力也立刻就下来了。

COS的使用也很简单:
1 建个仓库（bucket），以后附件就往这个仓库里面传了。


2 修改上传附件页面，使用腾讯云提供的API把文件上传到COS……开玩笑了，作为懒人，当然是提工单申请开通COS的FTP权限啦



大概两个钟头后收到消息说ftp开通了。

3 用论坛创始人身份登录discuz，打开远程附件


远程访问url可以域名解析到COS源上，不过这样附件都要走IDC流量，不但贵，也没有实现静态文件就近访问的目标，因此实际使用的时候最好在COS服务的上面加一层CDN：
 



现在用户新上传的附件都自动到cos里面了。然后我们来对付旧的附件吧。这时我们要用到回源功能了。先准备好一个回源专用的域名，修改httpd.conf（apache）或者conf.d（nginx）添加一个新的server，documentroot（或者root）指向服务器上discuz的附件目录 data/attachment 并修改域名解析，浏览器里面访问一下确认回源域名可以访问到附件。然后修改cos的回源配置：




这样如果有人访问cos的时候cos上没有相应的文件，服务器就会到老的服务器上获取文件并缓存下来。通过浏览器访问附件确认回源成功后，登录数据库 update cdb_attachments set remote = '1' 把所有的附件都更新为远程的。这样数据就会随着用户的访问慢慢迁移到cos上了，这个过程平滑无感知，不过就是不知道迁移到什么时候成功。

可是我想释放硬盘空间出来啊怎么办？先装上ftp神器 lftp再说。不得不说，在linux下，lftp实在是个神器。打开lftp，open登上COS的ftp服务器，mirror -RL ..... 老附件通通迁移上COS咯。

偷懒用ftp而不是修改上传页面代码的一个代价是，有的时候ftp失败，会有一些附件仍然被扔在CVM硬盘上。可以定期update cdb_attachments set remote = '1' 把附件都改成远程的，让cos回源到CVM上。不过就算这样，冷门的附件仍然可能长时间没有办法同步到cos上。crontab一个lftp任务定期把附件同步上COS可以解决问题。不过如果懂一点点开发的话，写一点点脚本用inotify自动同步一下显得会看起来好点儿：







三、 CDN优化：动静分离

      内容分发网络（Content Delivery Network）大概的意思就是，我大腾讯在全国成百上千个机房里面屯有无数的服务器，如果某个边远地区的用户要访问你放在上海的一份数据，山长水远的跑到上海机房来拉数据肯定快不了，如果我把这份数据先放在这个边远地区里，离用户最近的一个机房呢？那速度就不一样了。而且这个边远地区的机房流量还比我大上海三通机房的流量便宜了一大截。不过有个前提是服务器要提前知道用户将要访问的数据，并提前拉取这份数据缓存在当地，因此一般只用来服务静态的图片、样式表、脚本、超文本、flash这些资源。



      B论坛其实去年就用上了CDN，不过用的是一个比较冷门的用法：动态加速。这个用法就是说，先假设我网站的所有请求都是静态的，这样用户所有的请求都访问在当地的服务器（边缘服务器），然后边缘服务器检查一下这个请求的资源我有没有缓存啊，没有的话边缘服务器再受累跑去你的服务器上拉这个数据，把数据返回给你，并且尝试缓存这个数据以备下次使用。然后对于不允许缓存的动态请求，只要声明一个策略，比如“php文件缓存时间0秒”这样，让边缘服务器直接访问源CVM服务器就好了。

    这样做的好处是配置简单，不需要关心动静分离，并且不但静态的文件都可以被边缘服务器缓存，动态的请求也可以获得cdn网络的传输加速 。坏处就是“流量double”。也就是说，你不但要给cvm购买外网带宽，cvm的动态数据送到边缘服务器以后，你还要再购买一次从边缘服务器到用户那里的cdn带宽（或者流量）。

    另外一个附加的“缺点”是，CDN网络总是尽可能快的从CVM服务器拉取全部数据，再按照访客用户网络的速度再把数据吐出去。这其实是最佳策略，因为CVM的带宽已经买单了，不跑慢也是浪费，但是带来的问题就是CVM监控上看起来，再多的带宽都会被跑满，好像带宽永远都不够用。因此前任的管理员购买了非常多的带宽来试图满足永远喂不饱的CDN网络，带宽成了B论坛最沉重的成本。
    

 
（15M的带宽，经常性的被CDN跑满） 

    贸然的减少带宽也是不合适的，最好的做法还是做尽量彻底的动静分离，静态的部分还是用cos托管源和FTP托管源来喂饱CDN网络，让用户尽可能体验好；动态的部分直接访问CVM，根据用户日常实际产生的带宽情况再加上足够充分的冗余来采购就可以。

    传统的动静分离手段是最好的：直接修改html、css和js，通过静态专用域名访问静态资源。但是这样做需要很多的开发工作量，作为懒人，我直接用上了大杀器：rewrite！




    懒得给每个域名打马赛克了，也不是什么机密。这几条规则是这样：
1 对于普遍图片超大的png图片，自动转向到优图系统进行jpg压缩。因为监控发现少数png图片占了很大的流量比重。
2 对于用户上传到附件，自动转向到attachment子目录（COS源），这样CVM就不需要承担附件文件的存储了（零星缺失的文件cos回源启用了回源专用的域名）
3 对于系统的静态文件，自动转向到static子目录（FTP源），不统一使用cos源的原因是，CDN回源到ftp源是免费的，但是ftp源只有6G的存储空间。回源到cos空间几乎是无限的，但是是有可能收费的。
这样就把CVM上出了favicon.ico之外的几乎所有静态文件都分离出去了。要注意的是如果盗链严重的话，原本nginx上的防盗链规则也要相应的设置到cdn上去。




动静分离后cdn的整体命中率从瓶颈50%以下一下提升到75%以上，对于cvm的压力大大减小了。看一下分域名的命中率数据




在不对论坛程序做细致的优化的情况下，只是通过策略调整达到这样的命中率，还算比较理想了。

不过这样做了以后，CDN的流量费用并没有下降啊。因为B论坛的CDN采用了峰值带宽计费模式，因此观察了一下cdn监控的带宽数据，发现了一个很有意思的问题：



CDN的峰值带宽按天波动非常大。细看到具体的带宽比较大的一天更明显：



这天是央视《感动中国2016》B论坛的两个发起人入选带来的一个访问波峰。

像这样的带宽曲线模式，按照带宽购买CDN是非常浪费的。果断切换到流量包计费模式，CDN费用从每月>￥500(每年大约￥6000~￥8000)下降到每年<6T(每年大约2000以内)

动静分离后CVM的实际动态带宽需求有多少呢？后面上了负载均衡之后没有地方可以截屏几台服务器完整的带宽总和曲线了，总体是2M带宽平常跑不满，但是偶发集中的访问会超，所以两台CVM做负载均衡，各开了2M的带宽，保证平常有超过一倍的带宽冗余。

四：memcache和云数据库

B论坛迁移到腾讯云的时候就使用了云数据库，数据量虽然不大，但是数据库访问量不小，购买的是能支撑2400QPS的50G/2000MB型号。


 （7天后到期，不需要续了） 

但是查看了一下discuz的优化选项，发现内存缓存优化项都没有打开。在CVM里装上一个memcached测试了一下，数据库请求可以有效的降低到100QPS以下。这样高配云数据库就太浪费了，换个10G/360MB/120QPS的就足够了。不过性能冗余够不够？discuz支持master/slave的，先提个工单申请一个免费的slave。



配置slave后观察了几天，即使在峰值查询接近700QPS的情况下数据库也没有出现访问瓶颈，腾讯云数据库的性能还是相当厚道的，这个性能冗余是足够的。
（某海量网站配置错误导致出现大量404页面，顺带给论坛带来了很大压力）

这样数据库费用从￥2240/年陡降到￥210/年了。已经省了这么多钱，再买个C型的memcached好了，每天2元，每年大概700元。
CVM本机运行一个memcached虽然性能不错，但是始终要和其他本机服务竞争各种资源，而且考虑到后面要做负载均衡，也希望把登录态（session）丢到云里面去。


（memcache很轻松的扛住了情人节的感动中国带来的访问量）

修改了一下discuz的配置文件指向memcached，再修改php.ini把session也指向了memcached，这下CVM就没有“状态”了，可以很容易的替换，或者集成多个做负载均衡。

五：CVM和负载均衡



B论坛在腾讯云上一共两台CVM，对外提供服务的是一台配置有点豪华的服务器：



这台每年费用是 ￥16450，当然主要的钱都花在买带宽去喂CDN了



另一台不对外服务，只是有一个大的硬盘做数据备份。


一年￥1550。

经过上面一系列优化以后，原本买的CVM性能就太过冗余了，文件都丢到COS上去了，大硬盘备份也没有必要了。已经迁移到cos的文件剔除后，整个系统只剩下了4G，全部回迁到系统盘上面，数据盘也不需要了：



因为数据库在云上，附件文件也在cos上，本地没有什么动态的数据，这样系统备份也简单的多了，定期对系统盘做一个“系统镜像”就成，除了有一个问题：做系统镜像要关机。

墨菲定律告诉我们，永远要防着机器宕机！前面该清理的清理干净了，是时候做双机热备了。先把备份机的论坛服务也启动起来，session也指向memcached，然后添加一个负载均衡：


访问低谷的时候把主服务器关掉，做镜像，备份机自动扛住了全部访问量。

有了镜像以后换机型就方便了。新购一台服务器




因为充分使用了云数据库、memcache、cdn、cos等paas服务，又做了动静分离，cpu现在已经清闲的很，1核的性能是足够的。内存使用率也很低，内存其实1G也足够，不过cpu不够了还可以负载均衡，内存不够了就只有干瞪眼，所以多加1G冗余。
，
购买的时候就可以直接指定安装镜像，支付每年￥1250的费用，10分钟后，有了一台全新的服务器，配置host验证成功，加入到负载均衡后端列表里面

把权重分几次从原来的高配服务器分配到新服务器上，运行指标都还好，就是负载有点儿高，访问速度可能不是最优，也许是mysql或者memcache要通过网络访问导致的？
反正要做双机热备的，再买一台一样的服务器，加入负载均衡后台分摊一半的访问量，观察了一下cpu利用率和负载都下来了，虽然偶尔有一些瞬间的毛刺，反问上已经感觉不到差别。



这样就有了两台一模一样的服务器，平常分摊访问压力，一台宕机的时候负载均衡会自动发现并把访问全部导向到正常工作的服务器。未来如果有更大的访问压力随时可以新购机器，安装上镜像后加入负载均衡后端。

正好原来购买的服务器和数据库这阵子都要过期了，就都不用续费了。

六、对公益捐赠负责 

看看优化后比原来节省了多少：

CVM: 原来16450+1550=18000 ， 优化后1250*2=2500



CDN+COS：原来：￥6000~￥8000，优化后约 ￥2000（COS回源流量暂时还没收费，附件迁到cos后也不足50G还不需要存储费用，不过未来有可能产生少量费用。）

mysql+memcache ：原来 ￥2240，优化后210+700=910

总体相比原来优化大约 ￥22000 /年。

  虽然腾讯云一直对于公益组织免费扶持云资源，但是我觉得云资源和公益捐赠善款一样，也要用负责的态度抠门的用好，才是对支持企业负责任的态度。

最后，感谢腾讯云对公益事业的慷慨支持。打完收工。
posted on 2016-02-19 17:56 emu 阅读(1193) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。
网站导航:
博客园   IT新闻   Chat2DB   C++博客   博问