创业型团队需要的云计算
对于创业型团队来说，服务器托管费用+带宽成费用+运维成本，是压在头上的三座大山。满足业务性能需要，又要降低成本，尽快实现收支平衡，是当务之急。
一、不靠谱的 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 配置示例：
(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 请一定记得开启。下面提供一个 MySQL 5.6 版本适合在 1GB 内存 VPS 上的 my.cnf 配置文件。
下载文件
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监控通知，短信的延迟速度是最小的），就用谁的。
一、不靠谱的 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:2 keys_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_name view.store.s135.com;
access_log off;
location / {
proxy_cache_valid 200 600s;
expires 600s;
proxy_pass http://view_store_server_pool;
}
location ~ /resize_width/(\d+)/(.*) {
set $width $1;
rewrite ^/resize_width/(\d+)/(.*) /$2 break;
image_filter resize $width -;
image_filter_jpeg_quality 90;
image_filter_buffer 10m;
proxy_cache cache_app;
proxy_cache_valid 200 600s;
expires 600s;
proxy_pass http://view_store_server_pool;
}
location ~ /resize_height/(\d+)/(.*) {
set $height $1;
rewrite ^/resize_height/(\d+)/(.*) /$2 break;
image_filter resize - $height;
image_filter_jpeg_quality 90;
image_filter_buffer 10m;
proxy_cache cache_app;
proxy_cache_valid 200 600s;
expires 600s;
proxy_pass http://view_store_server_pool;
}
}
......
{
proxy_cache_path /Data/cache/nginx/app levels=1:2 keys_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_name view.store.s135.com;
access_log off;
location / {
proxy_cache_valid 200 600s;
expires 600s;
proxy_pass http://view_store_server_pool;
}
location ~ /resize_width/(\d+)/(.*) {
set $width $1;
rewrite ^/resize_width/(\d+)/(.*) /$2 break;
image_filter resize $width -;
image_filter_jpeg_quality 90;
image_filter_buffer 10m;
proxy_cache cache_app;
proxy_cache_valid 200 600s;
expires 600s;
proxy_pass http://view_store_server_pool;
}
location ~ /resize_height/(\d+)/(.*) {
set $height $1;
rewrite ^/resize_height/(\d+)/(.*) /$2 break;
image_filter resize - $height;
image_filter_jpeg_quality 90;
image_filter_buffer 10m;
proxy_cache cache_app;
proxy_cache_valid 200 600s;
expires 600s;
proxy_pass http://view_store_server_pool;
}
}
......
(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 请一定记得开启。下面提供一个 MySQL 5.6 版本适合在 1GB 内存 VPS 上的 my.cnf 配置文件。
下载文件
点击这里下载文件
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监控通知，短信的延迟速度是最小的），就用谁的。