云产品的8/2选择原则

在云端应用场景下，80%的企业（默认情况）会选择云产品，只有20%的企业会考虑自行搭建对应服务。比如，有SLB，企业肯定不会自己去搭建Nginx做负载均衡；再如，有RDS，企业也定不会自己去搭建MySQL。
对于云产品的选择，有件事情让我印象深刻。一次去北京出差，与同事一起拜访了一家公司。这家公司在云领域有十几台服务器，由一位运维人员负责维护。该公司的数据库都是在ECS上搭建MySQL来运行的，于是我问那位运维人员，“为什么不选择RDS？”那位运维人员不假思索地说，“在ECS上搭建也挺方便的，为什么要用RDS？”听到这个回答，我有点不高兴了，比较严肃且强势地说，“使用RDS就不用你考虑安装配置、调优、备份、扩展等问题，拿来就用，为什么还要自己去折腾搭建！”所以选择合适的云产品，相比自行搭建，有以下技术方面及非技术方面的优势。

五个技术优势

安装配置方面

一些软件的编译安装，比如PHP，经常会有依赖包、版本兼容等问题，其安装配置没有想象中那么简单。而对于云产品，我们不用再去官网找安装包，也不用自己手动安装、配置，这一切云产品都默默地替你做了。

调优方面

对于云产品，我们也不用关心一些性能参数要如何去优化，这一切云产品也会默认替你实现。比如，MySQL的配置优化对细节、技术、经验都有较大的挑战，如果你对其性能要求较高，只需要在管理界面选择更高规格的配置型号，或者选择集群版本即可。

备份方面

在传统运维过程中，我们需要搭建主从、编写备份脚本以及操作Binlog来进行对应的备份及恢复，这方面对运维人员来说都是较大的挑战。但使用云产品时，我们也不用关心冷备、热备方面的问题了，因为这一切云产品都默认帮你实现了，你只需要“傻瓜式”地操作即可，哪里不会点哪里。

高可用方面

使用云产品，我们不用担心出现高可用方面的问题，也担心什么时候挂了没办法提供服务。在ECS、SLB、RDS、OSS等阿里云产品中，都是采用集群的方式部署对应的云产品，保证我们使用对应云产品的高可用性。比如，ECS和OSS都是三副本的数据冗余，而RDS，则是采用DNS+双Master架构来保障高可用性。除了开放给用户的一个RDS库以外，还有一个隐藏的从库未开放给客户（举例：进入RDS MySQL，通过“show slave statusG”可以看到隐藏的从库）。

安全性方面

对于安全性方面，使用云产品，不用关心软件版本的安全性问题，也不用关心这个版本的软件有哪些补丁、漏洞要去修复，更不用关心这个软件会被攻击的问题，这都是云产品默认会做到的。

两个非技术优势

责任方面

在非技术方面，云产品有一个很大的优势，即如果是自己搭建维护的平台出了问题，那么对客户、对领导都要负责，对应的损失也得自己承担；相反，如果使用云产品出现了对应问题（当然主要是云产品稳定性、性能、安全性、高可用等本身问题，不包括因用户不会使用及对应误操作等导致的问题），那么对应的损失甚至可以找云厂商进行索赔。

部分企业在面向客户服务的时候，想要自己招聘运维人员，而不想找第三方服务公司，觉得不安全，怕数据被第三方公司窃取，或者出现安全性问题。众所周知，企业招聘员工，本身在成本和管理上就有很大的困难，这里先不谈这方面的挑战。换个角度，企业招聘员工本身就是安全风险非常高的事情，比如，怎么保障这个员工不泄密？其实很多企业的数据泄露，不是因为被黑客窃取，而往往是因为公司内部人员泄密。有时候，我们也会看到一些有意思的故事，比如“从删库到跑路”。虽然大家把这些故事都当成笑话，但殊不知这都是真实的案例。比如，一个运维人员因加班而失恋，之后格式化了所在公司的所有服务器并离职。因此员工造成的问题，结果只能是企业自己扛。若面对的是第三方专业团队，那么这些问题就可由第三方专业团队解决，甚至向其索赔。

费用方面

当然，云产品责任方面的优势只是从特定的某个方面来说，具体情况还得看业务需求和业务场景。在实际应用中，很多用户会觉得使用云产品成本较高，不如自建平台。单纯使用高规格的云产品的费用的确不低，但是深入了解后你会发现，想自行在ECS上搭建出和云产品具备相同性能的环境，所采用的ECS台数和ECS配置的费用加起来也不比使用云产品的费用低多少，如下表所示。

这里有一个需要注意的地方，RDS的8核16GB配置只是一个规格配置参考，并不代表我们自己ECS上部署的MySQL也要采用8核16GB配置，这是个细节误区。RDS最主要的规格性能参数是：“最大连接数：4000; IOPS：8000”。所以在实际部署中，要让数据库达到如此性能。我们一般采用CPU和内存配比为1∶4的ECS配置（数据库偏向内存型应用，具体实践参考第5章），如4核16GB、8核32GB、16核64GB。在上述ECS的配置清单中，默认推荐选择8核32GB是为了保障自建数据库的性能和稳定性。而且RDS的高可用版是双机高可用版，我们在ECS上自建的MySQL是单机版，这里还需要再开一台做主从，以保障数据库数据的安全性和高可用。这样一来，成本就进一步增加了。

选择自建环境的条件

那么，具体在什么场景下我们才需要自己搭建对应的服务呢？对此主要从功能性和灵活性等方面来考虑，这也是自行搭建服务平台的相对优势。阿里云的很多云产品，如SLB、RDS、CDN等，其核心都是基于开源技术进行了封装并做了相应优化，然后形成对应的云产品。相应的封装给我们带来了相应的优势，但同时也给我们带来了相应的缺陷，比如，做了封装，必然会使很多原生态的功能和特性存在一定的使用限制，下面我们具体来看。

七层SLB的功能限制

何为七层负载均衡？更多地称之为反向代理，大家最为熟悉的就是Nginx。何为七层反向代理/负载均衡？是因为它不只是能做七层转发，而更多的是能在七层上做很多Rewrite的七层控制等。而早期的SLB产品，连虚拟主机功能都不支持，只是可以简单地七层转发。当然，当前SLB产品已经支持虚拟主机，具有七层代表性的核心功能。如果想用Rewrite等更多七层功能，我们只能自行在ECS上搭建Nginx。

连接Redis，有密码鉴权

有些客户问这个密码鉴权能不能去掉，代码中采用了一个老的Ruby框架，不支持这个鉴权，也没办法改代码。所以这时候我们只能无奈地在ECS上自己搭建主从Redis，然后结合Console+DNS做高可用。

RDS MySQL对Myisam存储引擎的支持

在用户的业务中，需要MySQL支持Myisam存储引擎。而RDS MySQL版默认只支持Innodb的存储引擎，所以我们只能在ECS上搭建MySQL来满足业务需求。

云数据库MongoDB对跨地域多副本冗余的支持

若客户对数据的安全性要求较高，并且云端和他们线下IDC做了专线打通，他们需要将云端的MongoDB数据在线下IDC中做个副本，当前云数据库MongoDB结合DTS还不支持此功能。所以我们在云端搭建了两个副本，在IDC上同步一个副本，组成MongoDB的副本集。

综上可见，有些功能是云产品没办法支持的，且当前企业没办法调整自己的业务架构及代码。这个时候基于灵活性和功能性方面的考虑，只能选择在ECS上搭建相应的服务。