本文摘自于阿里云MVP、“乔帮主”乔锐杰所撰写的《阿里云运维架构实践秘籍》一书，选好云平台后，接下来要考虑的是在这个云平台上选择什么样的云产品进行业务部署及规划。可是在面对云平台上的两三百款产品时，难免会眼花缭乱。如何选择对应的产品？选择的重点是什么？我们又要注意哪些事项呢？

云产品的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上搭建相应的服务。