雲産品的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上搭建相應的服務。