如何使用阿里云 前言大家好。我們是成都瑞小博科技 (www.rippletek.com)。自從去年10月在阿里云購買了第一臺ECS 并部署服務后，到現(xiàn)在已過去了一年。在這一年間，隨著業(yè)務的擴張和用戶規(guī)

如何使用阿里云 前言

大家好。我們是成都瑞小博科技 (www.rippletek.com)。

自從去年10月在阿里云購買了第一臺ECS 并部署服務后，到現(xiàn)在已過去了一年。在這一年間，隨著業(yè)務的擴張和用戶規(guī)模的增長。我們的ECS 數(shù)量從1臺增長為20臺，并開通了SLB , RDS , OSS, CDN,OCS, SLS, MQS等多項業(yè)務。在這一年中，通過工單系統(tǒng)得到了阿里云的技術(shù)支持團隊和開發(fā)團隊的大量幫助和指導。在" 應該如何使用阿里云" 這個問題上，也積累了一些心得和經(jīng)驗，希望和大家分享，拋磚引玉。

初探ECS

使用阿里云的第一步， 當然是購買一臺ECS(后面稱為ecs1) 。這臺ECS 應該是什么樣的配置呢？一般情況下，我們建議的最低配置是單核，2G 內(nèi)存。如果只有1G 的內(nèi)存，運行阿里云的一鍵lamp 安裝腳本可能會oom 。操作系統(tǒng)，如果是從頭開始建站，建議使用Ubuntu 14.04. 相比CentOS 6.5, Ubuntu的內(nèi)核版本更高，能玩的花樣也更多(比如

docker) 。帶寬的話，1M 其實就夠了。無論如何，不要超過5M 。根據(jù)阿里云的帶寬階梯計價公式，1M 帶寬的月單價是21元，2M 比1M 多23(即44元，后面類推) ，3M 比2M 多25， 4M 比3M 多27， 5M 比4M 多29， 而一旦超過5M ， 每多1M 帶寬，價格就多100元! 所以，帶寬越高，每M 的單價也越高。同時，對于需要高可用的服務，根本不可能通過ECS 的外網(wǎng)帶寬開出去。所以，購買1M 帶寬，獲得一個外網(wǎng)IP ，就足夠了。至于數(shù)據(jù)盤，一般情況下，你不會需要它。ECS 購買完成后，你會收到阿里云的短信通知，發(fā)給你root 密碼。用那個密碼登入ECS 后，應該做的第一件事是加入authorized_key并刪除root 密碼:

復制代碼

1.

2.

3.

4.

5. mkdir .ssh chmod 700 .ssh vi .ssh/authorized_keys #加入自己的id_rsa.pub chmod 600 .ssh/authorized_keys passwd -d root

這樣，可以在根本上杜絕root 密碼被猜中的可能性。

初探SLB

第二步，購買一個公網(wǎng)的負載均衡器SLB(后面稱為slb1) 。如果你的域名已申請好，可以把域名指向slb1了。為了保證服務的高可用性，服務一定要通過SLB 開出去。設想一下，如果你的服務是走單臺ECS 出去，某天你需要修改一下apache 的配置，修改完畢后，service httpd restart卻發(fā)現(xiàn)httpd 進程沒有起來 (由于httpd.conf 里有個小小的筆誤..) 。事實上，這個時候你就已經(jīng)停服了！這也是為什么前面建議不必購買高帶寬ECS 的原因。

為了避免出現(xiàn)上面提到的那種尷尬的情況，SLB 的后端服務器至少要有兩臺ECS 并配置好health check。 盡管我們現(xiàn)在只有ecs1，如果上面的服務環(huán)境已經(jīng)部署ok, 就先把它加入到slb1的后端服務器組里，然后在瀏覽器里輸入我們的域名開始測試吧！然后，我們還需要另一臺ECS 。

再探ECS

第三步，再購買一臺ECS （后面稱為ecs2）。這一次，如果我們的業(yè)務代碼本身不用從internet 上獲取數(shù)據(jù)的話，我們可以試試內(nèi)網(wǎng)ECS ，即0M 帶寬的機器。這樣的機器沒有帶寬費用，會便宜一些，更重要的是，它沒有公網(wǎng)IP ，所以也更安全。下面問題來了： ?

? 它沒有公網(wǎng)IP ，我如何ssh 上去？ 它無法訪問internet ，我如何使用yum, apt這類包管理器來搭建業(yè)務環(huán)境？ 對于第一個問題，有兩個解決辦法：

1.

2.

?

? 先ssh 到有公網(wǎng)IP 的ecs1上，然后再ssh ecs2的內(nèi)網(wǎng)IP ，搞定 也可以通過一些配置，實現(xiàn)內(nèi)外網(wǎng)無感知的直接ssh 上去，方法如下： 在ecs1上安裝nc 工具，并修改/etc/hosts, 加入 ecs2 的解析 修改本地終端的.ssh/config, 加入配置

復制代碼

1. [li][li][li][li][li][li][li][li][li]Host ecs2[/li][li] Proxy

Command ssh root@ecs1 exec nc h p[/li][/li][/li][/li][/li][/li][/li]

[/li][/li]

在本地終端的/etc/hosts中加入 ecs1 的解析

然后，ssh root@ecs2 即可直接登錄ecs2

對于第二個問題，也有兩個解決辦法: ?

1. 在ecs1上架設如privoxy 一類的http 代理，然后在ecs2的/etc/bashrc文件中加入這

行代碼 export http_proxy="http://ecs1:"，然后ecs2就可以走ecs1的代理使用curl, yum等工具像外網(wǎng)ECS 一樣工作了。

2. 給ecs1的系統(tǒng)盤做個磁盤快照，并建立一個自定義鏡像，然后對ecs2使用“替換系

統(tǒng)盤”的操作把系統(tǒng)盤替換為我們剛剛創(chuàng)建的自定義鏡像就可以立即獲得和ecs1完全一樣的系統(tǒng)環(huán)境！

我們一般是把上面兩個辦法結(jié)合起來使用，快速搭建環(huán)境。在ecs2環(huán)境ok 后，也將它加入slb 的后端服務器組。至此，我們消除了ecs1的單點，再也不用為重啟web server這種事情糾結(jié)了。

但是ecs2并沒有公網(wǎng)IP ，如何才能訪問它以確認服務OK? 有兩種辦法:

1.

2. ssh tunnel. 在測試機器test 和ecs2分別建立ssh tunnel到ecs1的同一端口對接起來. 建一個測試用的公網(wǎng)SLB 作為代理網(wǎng)關，里面只放ecs2一個節(jié)點。用公網(wǎng)SLB 的

IP 就能訪問ecs2了。顯然，第2種辦法要簡單得多，所以我們一般用這種辦法 :) 在系統(tǒng)設計上，方便性和安全性存在沖突，內(nèi)網(wǎng)ECS 亦是一例。在進階篇 中，我們會進一步討論內(nèi)網(wǎng)ECS 的優(yōu)缺點。

分布式計算的幾個基本概念

在繼續(xù)我們后面的云端飛行旅程之前，我先介紹幾個分布式計算的基本概念。阿里云平臺提供的幾個基礎服務正是為了解決這幾個問題才開放出來的。

1. Single Point Failure (SPF), 單點故障。在一個服務系統(tǒng)中，因為一個節(jié)點的故障，導

致整個系統(tǒng)不可用。例如上面提到的網(wǎng)站域名指向ecs1的IP ，但ecs1上的web server restart 失敗的情形

2. Redundancy ，冗余。為了解決SPF ，在系統(tǒng)的關鍵路徑上，必須存在兩個或更多的

選擇。即當一個節(jié)點失效后，仍有其他的節(jié)點可以繼續(xù)提供服務。

3.

4. Stateless Node，無狀態(tài)節(jié)點。為了讓多個計算節(jié)點具有完全一致的行為，單個節(jié)點上面一定不能有自己獨有的狀態(tài)信息。 Load Balance, 負載均衡。多個計算節(jié)點共同承擔系統(tǒng)負載。

SLB 這一工具已經(jīng)解決了1,2,4這三點。那么，我們?nèi)绾螐腅CS 上抽離狀態(tài)信息以實現(xiàn)無狀態(tài)節(jié)點呢？為此，阿里云提供了另外兩個工具：RDS 抽離動態(tài)數(shù)據(jù)和OSS 抽離靜態(tài)數(shù)據(jù)將ECS 變?yōu)闊o狀態(tài)的計算節(jié)點?？梢园裄DS 當成一個超大型的Mysql 數(shù)據(jù)庫集群，OSS 當成一個超大型的文件存儲集群。

RDS 和OSS

我們先討論RDS 。雖然阿里云提供了lamp 的一鍵安裝包sh-1.3，但事實上，本地的mysql 服務是不需要的。RDS 的可靠性，易用性和可擴展性都比自己搭建的mysql 服務器要好很多。如果你仍在使用自己的mysql 數(shù)據(jù)庫，強烈建議遷移到RDS 。

再說說OSS 。ECS 的本地磁盤上只應存放業(yè)務代碼和配置，20G 的系統(tǒng)盤完全夠用，這就是為什么前面不建議購買數(shù)據(jù)盤的原因。用于下載或用戶上傳的數(shù)據(jù)文件都可以存到OSS 中。

對于一個基本的建站業(yè)務而言， 將動態(tài)數(shù)據(jù)存RDS ，靜態(tài)文件存OSS ，就實現(xiàn)了ECS 的無狀態(tài)。在這樣的框架下，可以方便的對系統(tǒng)擴容:

1.

2. 當訪問量變大，現(xiàn)有計算資源緊張時，對ECS 進行橫向(增加ECS 的節(jié)點個數(shù)) 或縱向(增加單個節(jié)點的CPU 核心和內(nèi)存) 擴展 如果數(shù)據(jù)庫訪問出現(xiàn)瓶頸，升級RDS 實例至更高配額

CDN 和OCS

后面，很自然的可以開通CDN 為OSS 的訪問加速。這一點，從定價上不難看出OSS CDN是阿里云希望用戶使用的方式。OSS 的流量是0.8元/GB,而CDN 是0.4. OSS通過CDN 出去，不僅訪問速度更快，還能降低成本。

如果RDS 中有一部分數(shù)據(jù)的讀取頻率比更新頻率高很多，可以通過將這部分數(shù)據(jù)緩存入OCS ，在提升系統(tǒng)響應速度的同時緩解RDS 的讀取壓力。RDS OCS業(yè)務代碼的實現(xiàn)邏輯:

1.

2.

3. 如果要從RDS 的表table0中讀取主鍵為id 的數(shù)據(jù)項，先嘗試從OCS 中讀取key="table0_id"的數(shù)據(jù)，如果命中，則使用從緩存中讀取的數(shù)據(jù)，不用再訪問RDS 如果緩存不命中，訪問RDS 讀出數(shù)據(jù)v ，以key="table0_id", value=v寫入OCS 當table0中的id 數(shù)據(jù)項被變更或刪除的同時，刪除OCS 中key="table0_id"的數(shù)據(jù)

小結(jié)

綜上，我們介紹了如何使用阿里云提供的ECS,SLB,RDS,OSS,CDN 和OCS 這6個業(yè)務來構(gòu)建我們自己的高可用業(yè)務網(wǎng)站系統(tǒng)。它的基本結(jié)構(gòu)如下圖所示：

幾點說明:

1.

2.

3.

通過外網(wǎng)SLB 的IP 向外提供服務，用戶請求通過SLB 分發(fā)到后端的幾個ECS 來計算處理 利用RDS 和OSS 來抽離狀態(tài)數(shù)據(jù)，使得ECS 成為無狀態(tài)的計算節(jié)點 可以利用OCS 緩存RDS 的數(shù)據(jù)， CDN 緩存OSS 的數(shù)據(jù)，提高訪問速度

前情提要及概述

在基礎篇中，我們介紹了如何利用阿里云的幾個基礎服務: ECS , SLB, RDS, OSS, CDN 和OCS 來構(gòu)建一個高可用的業(yè)務網(wǎng)站系統(tǒng)。在本篇中，我們將進一步介紹上面這些基礎工具，以及如何從單業(yè)務系統(tǒng)拓展到多業(yè)務系統(tǒng)，和日常開發(fā)和運維的一些常用技巧。

多業(yè)務系統(tǒng)之間的交互手段

我們從幾個具體的case 說起吧 :)

case #1 利用消息隊列實現(xiàn)的固件定制系統(tǒng)

如上圖所示，先是由一個web 前端的表單系統(tǒng)將用戶的輸入?yún)?shù)組裝為一條消息放入固件生成的請求隊列中，后面由固件構(gòu)建集群取得用戶的配置參數(shù)，生成固件后存入OSS ，再將生成的結(jié)果放入結(jié)果消息對列中，前端系統(tǒng)獲取結(jié)果后更新RDS 的狀態(tài)。

我們可以利用阿里云提供的MQS 服務非常方便的在兩個業(yè)務系統(tǒng)之間實現(xiàn)用消息隊列異步傳輸小尺寸數(shù)據(jù)。如果尺寸較大，亦可以通過往RDS/OCS或OSS 中寫入臨時數(shù)據(jù)，用消息隊列傳輸key 或url 來解決。

case #2 利用ODPS/RDS實現(xiàn)的非實時數(shù)據(jù)分析系統(tǒng)

ODPS 是一個阿里云上的接口類似Hadoop Hive的數(shù)據(jù)分析系統(tǒng)。我們可以部署多個數(shù)據(jù)收集節(jié)點，將數(shù)據(jù)存入ODPS 。再搭建一個數(shù)據(jù)分析集群，定期對寫入ODPS 的新數(shù)據(jù)進行提取，然后將提取的結(jié)果放入RDS 。最后由一個web 前端系統(tǒng)讀取RDS 中的數(shù)據(jù)生成報表呈現(xiàn)給最終用戶。

這種reader/writer的模式是兩個業(yè)務系統(tǒng)之間通信的常見方式，只要是兩個系統(tǒng)之間可以共享的系統(tǒng)資源，都可以通過一端寫入，另一端讀出來實現(xiàn)通信。而在阿里云的系統(tǒng)設計中，同一賬戶下的ECS 可以共享RDS ，OCS, MQS, OSS, ODPS這些資源。我們應當針對不同的應用場景選擇合適的資源類型加以利用。

case #3 利用OCS/內(nèi)存數(shù)據(jù)庫構(gòu)建實時數(shù)據(jù)分析系統(tǒng)

web 前端系統(tǒng)接受用戶查詢請求后，先查找OCS 是否有緩存的結(jié)果，如果cache 命中則直接返回結(jié)果。如果cache 不命中，調(diào)用后端數(shù)據(jù)存儲集群的web api. web api負責查詢分布式內(nèi)存數(shù)據(jù)庫并計算分析后返回統(tǒng)計結(jié)果。前端系統(tǒng)拿到查詢結(jié)果后，用查詢參數(shù)hash 出一個key ，將查詢結(jié)果作為value 存入OCS 中。注意：該系統(tǒng)的實時性在很大程度上取決于OCS 緩存的expiration. 應依據(jù)業(yè)務特點設置合適的expiration 值。如果對結(jié)果的實時性要求很高并且后端數(shù)據(jù)存儲集群的計算性能有充分安全邊際的情況下，也可以移除OCS ，每次都重新提取數(shù)據(jù)計算結(jié)果。

同樣，web api系統(tǒng)也務必消除單點。在這里，我們可以使用內(nèi)網(wǎng)SLB 解決。

再探SLB

在基礎篇中我們介紹過外網(wǎng)SLB ，并強調(diào)一切對外服務一定要通過外網(wǎng)SLB 開放出去以消除單點。同樣的，所有的系統(tǒng)內(nèi)部通信web api也一定要通過內(nèi)網(wǎng)SLB 訪問。內(nèi)網(wǎng)SLB 和外網(wǎng)SLB 的區(qū)別在于內(nèi)網(wǎng)SLB 只有內(nèi)網(wǎng)IP ，沒有外網(wǎng)IP ，所以無法從internet 上訪問到。另外，內(nèi)網(wǎng)SLB 沒有實例費和流量費，所以一定要多多的用起來！

SLB 有兩種監(jiān)聽轉(zhuǎn)發(fā)方式， TCP 和HTTP ，一般情況下，web 服務都采用http 的轉(zhuǎn)發(fā)方式，使用cookie 來保持會話，這樣即使在應用中使用本地文件來保存session ，也不會成為問題。唯一的例外是給網(wǎng)站開啟CDN 時，為了消除CDN 回源的單點，自然的，我們不能用單臺ECS 來回源，應考慮使用SLB ，然而，如果使用HTTP cookie保持會話，

CDN 會由于頁面帶了cookie 而拒絕緩存。這種情況下，只能使用無會話保持的HTTP 轉(zhuǎn)發(fā)或TCP 轉(zhuǎn)發(fā)。

小結(jié)

至此我們展示了幾個多業(yè)務系統(tǒng)的具體架構(gòu)。云計算的組件組合方式可以是多種多樣的。然而，在構(gòu)建高可用系統(tǒng)這個問題上，有幾個基本原則可以參考:

1.

2. 務必消除單點。(如果讀到這里您仍不理解什么是單點，請再看一遍基礎篇 ) 盡量使用阿里云提供的系統(tǒng)服務，不要自己用ECS 進行重復建設。例如，使用RDS ，

而不是自己搭建mysql 集群; 使用OCS ， 而不是自己搭建memcached 集群；使用OSS ， 而不是自己搭建文件服務器；使用ODPS ， 而不是自己搭建Hadoop Hive; 使用MQS, 而不是自己架RabbitMQ... 一是可以大幅降低投入，二是盡可能的把高可用問題交給阿里云的運維團隊，而不是自己的運維團隊解決，會有更佳的效果。

3. 設計異?；謴蜋C制。任何系統(tǒng)都有可能會出現(xiàn)各種異常，阿里云也不例外。例如: ECS

的宕機遷移會使ECS 實例重啟，最好在系統(tǒng)啟動時即自動啟動服務；RDS 和SLB 都有可能出現(xiàn)閃斷的情況，需要自動重連；甚至云服務節(jié)點間的內(nèi)網(wǎng)通信也有可能中斷，導致內(nèi)網(wǎng)SLB 失效以及分布式數(shù)據(jù)庫brain-split 這類對服務質(zhì)量有很大影響的問題，所幸在這一年里我們只遇到過一次這樣的故障。

4. 安全平穩(wěn)的線上代碼變更。不管基礎系統(tǒng)架構(gòu)多么完美穩(wěn)定，如果運行在上面的業(yè)

務代碼劇烈震蕩，系統(tǒng)的可用性也還是個問題。所以在本篇的最后，我再介紹一下 RippleTek 的上線流程

我們的每一個服務都是通過至少一個外網(wǎng)SLB 開放出去的。在每個SLB 的后面，至少有兩個主服務節(jié)點SRV1和SRV2。另外，還有一個線上引流測試節(jié)點pilot 。當需要線上代碼進行變更的時候，先將pilot 下線 (使用slb api將它從slb 中移除，或者在控制臺中將它的權(quán)重設為0. 這時你可能會問兩個問題: 1) 把節(jié)點的權(quán)重設為0和直接將節(jié)點從slb 中移除的區(qū)別是什么? 2) 為什么不用slb api將它的權(quán)重設為0? 這兩個問題的答案請見下方的Q&A)，在pilot 中的代碼或配置變更不會對線上服務產(chǎn)生影響。同時，我們有一個測試專用的SLB_TEST，后端服務器就只有一個pilot ，自己測試就用SLB_TEST的IP 來做。功能測試OK 后，把pilot 重新加入線上服務的SLB ，導入5流量，持續(xù)觀察日志5分鐘看是否有異常情況。如無異則一小時后再觀察。如一切正常，就將變更部署到該業(yè)務的全部主服務器上。部署后密切觀察線上日志和監(jiān)控，如有異常，先回退變更，再結(jié)合異常日志調(diào)查原因。該流程的有效性在很大程度上依賴于pilot 的環(huán)境配置和SRV1/2的一致性，務必保證它們的環(huán)境是完全一樣的!

到這里我們的旅程也暫告一段落了。稍事休息，更多精彩和樂趣將在 應該如何使用阿里云？(高級篇) 中呈現(xiàn)。 敬請期待。

Q&A

? 把節(jié)點的權(quán)重設為0和直接將節(jié)點從slb 中移除的區(qū)別是什么?

把節(jié)點A 的權(quán)重設為0可以讓SLB 不再轉(zhuǎn)發(fā)新的請求到A ，但已經(jīng)調(diào)度到這個服務器的連接繼續(xù)保持，直到這些連接全部結(jié)束。而直接將節(jié)點A 從slb 中移除會導致已經(jīng)調(diào)度到這個服務器的連接中斷，可能會對服務質(zhì)量有細微影響。

? 為什么不用slb api將它的權(quán)重設為0?

目前最新的slb api v20140515 尚未提供后端分發(fā)節(jié)點的權(quán)重設置。