移动互联网初创型团队需要什么样的云计算服务？

【编者按】时至今日，借助云服务以小规模团队获得巨额回报的移动应用已比比皆是，比如：13人的Instagram团队借助AWS创造10亿美元的价值；14个人的Mailbox使用AWS发布3周后就卖了1亿美元；基于SoftLayer仅50名员工的WhatsApp被Facebook以190亿美元收购。相比国内，国外有着太多成熟的公有云可供选择，比如AWS、GCE、Windows Azure等，国内移动创业团队又该如何选择自己赖以生存的合作伙伴，这里我们看张宴带来的解析。

云计算大数据推动智慧中国 ”为主题的第六届中国云计算大会将于5月20-23日在北京国家会议中心隆重举办。产业观察、技术培训、主题论坛、行业研讨，内容丰富，干货十足。需要购买的朋友，请抓住这最后的机会，点击报名！

关于作者：张宴，网名回忆未来，现苏州热拍信息技术有限公司合伙人/副总裁；曾担任北京世纪一家网技术总监，金山游戏运营技术中心网站开发部技术经理/架构师，新浪播客系统工程师，有着丰富的架构经验。

以下为博文

对于创业型团队来说，服务器托管费用+带宽成费用+运维成本，是压在头上的三座大山。满足业务性能需要，又要降低成本，尽快实现收支平衡，是当务之急。

一、不靠谱的 App Engine

1.Google App Engine 云服务在国外的成功，不代表国内巨头们各种 *AE 仿造品的成功。在微博上搜搜就可以看到小伙伴们吐槽的各种不稳定，另外，*AE们对资源使用最大数各种规定限制，加上为了计费、阉割功能的各种限制，使它的价格优势成为鸡肋。*AE们就好比100M共享带宽的小区宽带，以低价卖给每个上网用户5M的带宽，前几十个用户感觉这网速真不错，等他卖了100个以上用户5M带宽，而这部分用户白天上班去了，晚上下班回来都在上网，其中又有一部分看视频、BT下载，于是乎，白天网速快，晚上慢得要死，连200K带宽都达不到。要知道，不怕神一样的对手，就怕猪一样的队友，在国内的 App Engine 环境下，水平参差不齐的开发者的代码质量、习惯性的资源滥用、别人网站被攻击殃及池鱼对*AE性能的影响，导致*AE的稳定性非常差。

2.所以，*AE们也意识到公共 App Engine 不稳定，所以又推出专用 App Engine，但费用一下就翻了很多倍。所以，*AE只是个人博客、个人开发者玩玩的工具，真正用作项目，还是需谨慎。根据实际的经验，*AE们还真不如VPS稳定。

二、成本低的小而美VPS

1.对于初创团队来说，购买服务器、交换机，托管服务器费用、带宽月使用费，是极其昂贵的。购买可以弹性升级硬件配置的云服务VPS，是降低成本不错的选择。国内VPS，1G内存、1~2核CPU、1M带宽、多线BGP，大概价格在100元/月左右，支持备案，可以作为最低入门选择，有条件可以购买两台互为热备，阿里云主机可以作为参考。大多数VPS服务商使用的都是廉价的SATA磁盘。如果你对磁盘IO要求较高，可以选择提供有SAS磁盘的IAAS云主机服务商，比如UCloud。

2.市场上的VPS商家主要有 Xen、OpenVZ、KVM 三种开源的虚拟化技术。全虚拟化的 Xen 更像独立主机，服务器资源按VPS实际大小平均分配，一般无法超售。半虚拟化的 OpenVZ 在同样的性能测试下，会比 Xen 高一些，但是，一台物理内存16G的服务器，可以分配出总内存大小超过16G很多倍的VPS，服务商可以超售，想卖多少台VPS就可以卖多少台，所以不推荐使用。KVM 在最新的 Linux 发行版中，已经是集成，但是，商业化应用还不成熟，基于 KVM 的 VPS 服务商很少。

3.VPS的操作系统，建议选择64位的Linux。在32位Linux下，PHP能给处理的整数不能超过正负2^31=2147483648，如果以后接入新浪微博、淘宝、腾讯等第三方开放平台，他们的接口里会有超过32位的整数（比如新浪用户ID、淘宝商品ID）。如果不幸使用32位Linux，你只能将这些整数当成字符串处理了，以后配合Sphinx等搜索引擎，会非常麻烦。

4.现在，可以在北京进行备案的域名有：国际域名 .com .net .org，国内域名 .cn .com.cn .中国，国别域名 .cc，其他的域名均不能进行备案。仅北京有限制，其它省市正常提交备案即可。我们原来申请的 .me 域名，在北京无法备案，后来只好拿到苏州去备案了。所以，在选择域名的时候，需要慎重。

5.使用 VPS，一定要定期在本地，做好数据备份，不要相信所谓的 7*24服务，99.99%安全稳定性，只要有人的VPS出问题了，都归为那 0.01%。

三、应对峰值带宽的云存储
1.对于DAU（日活跃用户）过十万的网站、APP应用来说，CDN或云存储是必需品。使用云存储不是因为存储空间，因为一块几TB的SATA磁盘很便宜，使用云存储是因为高出平均带宽值几倍至几十倍的峰值带宽。做手机APP应用，峰值带宽更集中，当你向所有用户群发PUSH一条消息，用户被唤醒打开APP应用，几分钟的时间，会消耗几十倍的带宽峰值。图片、下载，是最主要的带宽消耗者。也许，数据接口API只需不到1M的带宽，而图片对带宽的峰值需求则会达到100M。为了几分钟的峰值，去购买100M昂贵的带宽，其他时间带宽都空闲，是一件非常奢侈的事。
2.国内提供云存储服务的商家有很多，真正好用得却不多，提供FTP等公共通用协议的云存储更是微乎其微。使用第三方云服务，切忌千万不要吊死在一棵树上。支持FTP等公共协议，如果将来有问题，能够方便的进行数据迁移和技术替代。如果云服务厂商一直能够提供优质的服务，那么，也就可以长期使用他们的云服务。相信优秀的云存储提供商，是不会惧怕这一点的。

3.之前，我用过阿里云的开放存储服务OSS，但是，稳定性比起阿里云主机ECS等其他服务，要差多了。下面是用阿里云自家的云监控，监控最近一个月阿里云主机和OSS上的文件，云主机的可用性99.99%，而OSS可用性只有97.83%，月宕机累积时间31.27小时。而OSS每次一遇到升级，就更坑爹了，不多说，自己看他们的公告吧（ http://bbs.aliyun.com/read.php?tid=146819 、 http://bbs.aliyun.com/read.php?tid=141828 、 http://bbs.aliyun.com/read.php?tid=139381 )：

4.后来，本博客的图片、附件下载，改用了又拍云存储。相比于其他的云存储，又拍云支持FTP上传、下载管理文件，同时对于图片类文件的处理功能，也比较强大：

(1)支持缩略图&水印，可以支持自定义版本：限定宽度，高度自适应；限定高度，宽度自适应；限定最长边，短边自适应；限定最短边，长边自适应；限定宽高；等比缩放等多种缩略模式。

示例：

原图：http://yphoto.b0.upaiyun.com/test/gzhd.jpg
限定宽度(600px)，高度自适应：http://yphoto.b0.upaiyun.com/test/gzhd.jpg_b
限定最长边(100px)，短边自适应：http://yphoto.b0.upaiyun.com/test/gzhd.jpg_100

当然，通过 Nginx 的 image_filter 也可以实现其中的限宽或限高自适应功能、并缓存在本地，只是功能要少，缺少了又拍云存储的CDN加速功能。Nginx image_filter 配置示例：

http{proxy_cache_path /Data/cache/nginx/app levels=1:2keys_zone=cache_app:200m inactive=7d max_size=10g; upstream view_store_server_pool{server 192.168.1.2:80;server 192.168.1.3:80;}server {server_nameview.store.s135.com;access_logoff;location / {proxy_cache_valid200 600s;expires 600s;proxy_pass <a href="http://view_store_server_pool;">http://view_store_server_pool;</a>}location ~ /resize_width/(/d+)/(.*) {set $width $1;rewrite ^/resize_width/(/d+)/(.*) /$2 break;image_filter resize$width -;image_filter_jpeg_quality90;image_filter_buffer 10m;proxy_cache cache_app;proxy_cache_valid200 600s;expires 600s;proxy_pass <a href="http://view_store_server_pool;">http://view_store_server_pool;</a>}location ~ /resize_height/(/d+)/(.*) {set $height $1;rewrite ^/resize_height/(/d+)/(.*) /$2 break;image_filter resize- $height;image_filter_jpeg_quality90;image_filter_buffer 10m;proxy_cache cache_app;proxy_cache_valid200 600s;expires 600s;proxy_pass <a href="http://view_store_server_pool;">http://view_store_server_pool;</a>}}......

로그인 후 복사

(2)又拍云存储支持 Token 防盗链。对于图片类防盗链来说，判断域名、Reffer就够了。但是对于软件下载等防盗链来说，Reffer等信息都可以伪造，比较靠谱的方法，还是Token防盗链。

四、可选的关系型数据库服务（即 MySQL 服务）
1.资源消耗的大户在于 MySQL，影响整体性能的因素也在于 MySQL。对于创业型团队来说，不要过度依赖 MySQL，不要将高并发业务逻辑都用 MySQL 来处理。在 MySQL 前加个 Memcached 做 SQL 查询缓存，跟 MySQL 的 Query Cache 区别不大，治标不治本，命中率不高，还降低了实时性。现在的移动应用，交互性比较强，实时性要求非常高，Web 时代缓存几分钟的老方法，已经不能适合移动互联网时代的需求。因此，MySQL 只适合存储一些并发查询量不大的核心数据，或作为数据的备份，只写入不查询。我遇到过很多创业团队，用户飞速增长时，最后都是被 MySQL 数据库的性能瓶颈蹩了脚，最后不得不减缓产品功能开发的脚步，来做性能调优，失去了与竞争者、模仿者、山寨大王腾讯的竞争优势。创业团队靠什么和大公司竞争，靠得就是灵活与速度，跑赢大公司。
2.在不依赖 MySQL 的条件下，那么，最低配的关系型数据库服务（比如阿里云的最低配内存 240M、磁盘IOPS 150、最大连接数 60，70元/月），就能适合自己的需求了，不然，勉强满足一般业务配置的关系型数据库服务的费用，就得 700~3000 元/月了。
3.如果购买最低配的关系型数据库服务，还不如省掉 70元/月的费用，在自己 1GB 以上内存的 VPS 上，自己搭建一个 MySQL 数据库，磁盘IOPS、最大连接数、存储空间还不受限制。自己做好 MySQL 的主主、主从同步备份，定时dump备份就可以了。需要注意的是，很多VPS默认没有开启sawp，使用 MySQL 请一定记得开启。

4.如果说 VPS 云服务是必选项的话，关系型数据库服务则是可选项。

五、结构化存储 NoSQL 数据库

1.既然不依赖 MySQL 数据库，那么，对于高并发访问，就需要依赖结构化存储 NoSQL 数据库了。虽然一些云计算服务商，也提供了结构化存储服务，但是，不推荐使用。因为他们使用的都是私有协议，你无法在他们的服务质量、稳定性变差了，价格变贵了，或出现别的更好服务商时，快捷地迁移数据。数据迁移、代码修改的成本太高，还要收到一些服务商规定的单个键值对数据大小不能超过多少、数据导出单个文件大小不能超过多少，使用了，就等于被绑架了。当你准备迁移时，发现不能停服务、数据量太大导入导出速度慢、数据一致性问题受影响，你会发现，早知如此，何必当初。

2.所以，对于 NoSQL 来说，本着使用软件，而不使用服务的原则。寻找开源、免费、付费 NoSQL 软件，安装在自己的 VPS 上，做到多机备份，要好得多。现在的 NoSQL 已经超越了单纯的 Key-Value，对于 List、结构化存储的支持，已经可以取代 MySQL 的大部分功能。

3.对于我们团队来说，NoSQL（自行开发的BigSea数据库）与 MySQL 在业务中的使用比例为 80% 比 20%，MySQL 主要用于给内部编辑、销售人员使用的后台管理系统。而对于APP、网站流量，95% 的数据库访问为 NoSQL，5% 为 MySQL。

4.如果用 MySQL 数据库，一条联合查询的SQL，也许就可以处理完业务逻辑，但是，遇到大量并发请求，就歇菜了。如果用 NoSQL 数据库，也许需要十次查询，才能处理完同样地业务逻辑，但每次查询都比 MySQL 要快，十次循环NoSQL查询也许比一次MySQL联合查询更快，应对几万次/秒的查询完全没问题。PHP 从 5.3 版本开始，已经可以真正地支持多线程。如果加上PHP多线程，通过十个线程同时查询NoSQL，返回结果汇总输出，速度就要更快了。关于 PHP 多线程的使用，我接下来会再写篇文章细说。

六、防DDOS、CC、Web注入攻击

1.世界上总会有人看你不爽，于是就想着利用不对称的服务器、带宽资源，DDOS、CC攻击你。在云计算时代之前，小规模的攻击可以依靠iptable，大规模的攻击只能依靠昂贵的专业防火墙了。在云计算时代，可以使用一些专业的防DDOS、CC攻击服务商，比如：与腾讯云合作的安全宝、跟百度合作的加速乐。

2.使用这类服务，有一点需要注意，对于域名的@记录，CNAME别名记录和MX邮件记录会冲突，如果将@记录由A记录改为CNAME记录，可能会导致该域名下绑定的企业邮箱服务器收不到邮件。

七、云监控

1.对于一家没有专门系统运维人员的创业企业来说，可以使用第三方云监控来代替运维人员。使用云主机，硬件故障找云计算服务商解决；操作系统故障，云监控中的服务器监控项目很细，通过故障报警就可以定位出问题；剩下的就剩下Web程序代码问题了，使用Nginx+PHP语言运行服务的，将PHP慢日志打开，如果云监控报Web服务502、504错误，快速检测一下PHP慢日志，看看那个PHP文件的哪行代码导致的，作为源头查下去（比如慢日志中显示是MySQL Query查询的代码执行慢，则进一步追查能否正常连接MySQL服务器，没问题则再追查MySQL自身的问题），一步步快速去解决。

2.用过阿里云监控、盛大云监控、监控宝，功能大相径庭。谁的免费版本功能越多、赠送的免费短信通知越多（对于故障的第一时间告知，相比邮件监控通知、手机APP监控通知，短信的延迟速度是最小的），就用谁的。