如何使用阿里云_第1頁
如何使用阿里云_第2頁
如何使用阿里云_第3頁
如何使用阿里云_第4頁
如何使用阿里云_第5頁
全文預(yù)覽已結(jié)束

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

如何使用阿里云前言大家好。我們是成都瑞小博科技(rippletek)。自從去年10月在阿里云購置了第一臺ECS并部署效勞后,到現(xiàn)在已過去了一年。在這一年間,隨著業(yè)務(wù)的擴張和用戶規(guī)模的增長。我們的ECS數(shù)量從1臺增長為20臺,并開通了SLB,

RDS,OSS,CDN,OCS,SLS,MQS等多項業(yè)務(wù)。在這一年中,通過工單系統(tǒng)得到了阿里云的技術(shù)支持團隊和開發(fā)團隊的大量幫助和指導(dǎo)。在"應(yīng)該如何使用阿里云"這個問題上,也積累了一些心得和經(jīng)驗,希望和大家分享,拋磚引玉。初探ECS使用阿里云的第一步,當(dāng)然是購置一臺ECS(后面稱為ecs1)。這臺ECS應(yīng)該是什么樣的配置呢?一般情況下,我們建議的最低配置是單核,2G內(nèi)存。如果只有1G的內(nèi)存,運行阿里云的一鍵lamp安裝腳本可能會oom。操作系統(tǒng),如果是從頭開始建站,建議使用Ubuntu14.04.相比CentOS6.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后,應(yīng)該做的第一件事是參加authorized_key并刪除root密碼:復(fù)制代碼mkdir.sshchmod700.sshvi.ssh/authorized_keys#參加自己的id_rsa.pubchmod600.ssh/authorized_keyspasswd-droot這樣,可以在根本上杜絕root密碼被猜中的可能性。初探SLB第二步,購置一個公網(wǎng)的負載均衡器SLB(后面稱為slb1)。如果你的域名已申請好,可以把域名指向slb1了。為了保證效勞的高可用性,效勞一定要通過SLB開出去。設(shè)想一下,如果你的效勞是走單臺ECS出去,某天你需要修改一下apache的配置,修改完畢后,servicedrestart卻發(fā)現(xiàn)d進程沒有起來(由于d.conf里有個小小的筆誤..)。事實上,這個時候你就已經(jīng)停服了!這也是為什么前面建議不必購置高帶寬ECS的原因。為了防止出現(xiàn)上面提到的那種為難的情況,SLB的后端效勞器至少要有兩臺ECS并配置好healthcheck。盡管我們現(xiàn)在只有ecs1,如果上面的效勞環(huán)境已經(jīng)部署ok,就先把它參加到slb1的后端效勞器組里,然后在瀏覽器里輸入我們的域名開始測試吧!然后,我們還需要另一臺ECS。再探ECS第三步,再購置一臺ECS〔后面稱為ecs2〕。這一次,如果我們的業(yè)務(wù)代碼本身不用從internet上獲取數(shù)據(jù)的話,我們可以試試內(nèi)網(wǎng)ECS,即0M帶寬的機器。這樣的機器沒有帶寬費用,會廉價一些,更重要的是,它沒有公網(wǎng)IP,所以也更平安。下面問題來了:它沒有公網(wǎng)IP,我如何ssh上去?它無法訪問internet,我如何使用yum,apt這類包管理器來搭建業(yè)務(wù)環(huán)境?對于第一個問題,有兩個解決方法:先ssh到有公網(wǎng)IP的ecs1上,然后再sshecs2的內(nèi)網(wǎng)IP,搞定也可以通過一些配置,實現(xiàn)內(nèi)外網(wǎng)無感知的直接ssh上去,方法如下:在ecs1上安裝nc工具,并修改/etc/hosts,參加ecs2<ecs2內(nèi)網(wǎng)ip地址>的解析修改本地終端的.ssh/config,參加配置復(fù)制代碼[li][li][li][li][li][li][li][li][li]Hostecs2[/li][li]

ProxyCommandsshroot@ecs1execnc%h%p[/li][/li][/li][/li][/li][/li][/li][/li][/li]在本地終端的/etc/hosts中參加ecs1<ecs1外網(wǎng)ip地址>的解析然后,sshroot@ecs2即可直接登錄ecs2對于第二個問題,也有兩個解決方法:在ecs1上架設(shè)如privoxy一類的代理,然后在ecs2的/etc/bashrc文件中參加這行代碼export_proxy="://ecs1:<proxy_port>",然后ecs2就可以走ecs1的代理使用curl,yum等工具像外網(wǎng)ECS一樣工作了。給ecs1的系統(tǒng)盤做個磁盤快照,并建立一個自定義鏡像,然后對ecs2使用“替換系統(tǒng)盤〞的操作把系統(tǒng)盤替換為我們剛剛創(chuàng)立的自定義鏡像就可以立即獲得和ecs1完全一樣的系統(tǒng)環(huán)境!我們一般是把上面兩個方法結(jié)合起來使用,快速搭建環(huán)境。在ecs2環(huán)境ok后,也將它參加slb的后端效勞器組。至此,我們消除了ecs1的單點,再也不用為重啟webserver這種事情糾結(jié)了。但是ecs2并沒有公網(wǎng)IP,如何才能訪問它以確認效勞OK?有兩種方法:sshtunnel.在測試機器test和ecs2分別建立sshtunnel到ecs1的同一端口對接起來.建一個測試用的公網(wǎng)SLB作為代理網(wǎng)關(guān),里面只放ecs2一個節(jié)點。用公網(wǎng)SLB的IP就能訪問ecs2了。顯然,第2種方法要簡單得多,所以我們一般用這種方法:)在系統(tǒng)設(shè)計上,方便性和平安性存在沖突,內(nèi)網(wǎng)ECS亦是一例。在進階篇

中,我們會進一步討論內(nèi)網(wǎng)ECS的優(yōu)缺點。分布式計算的幾個根本概念在繼續(xù)我們后面的云端飛行旅程之前,我先介紹幾個分布式計算的根本概念。阿里云平臺提供的幾個根底效勞正是為了解決這幾個問題才開放出來的。SinglePointFailure(SPF),單點故障。在一個效勞系統(tǒng)中,因為一個節(jié)點的故障,導(dǎo)致整個系統(tǒng)不可用。例如上面提到的網(wǎng)站域名指向ecs1的IP,但ecs1上的webserverrestart失敗的情形Redundancy,冗余。為了解決SPF,在系統(tǒng)的關(guān)鍵路徑上,必須存在兩個或更多的選擇。即當(dāng)一個節(jié)點失效后,仍有其他的節(jié)點可以繼續(xù)提供效勞。StatelessNode,無狀態(tài)節(jié)點。為了讓多個計算節(jié)點具有完全一致的行為,單個節(jié)點上面一定不能有自己獨有的狀態(tài)信息。LoadBalance,負載均衡。多個計算節(jié)點共同承當(dāng)系統(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當(dāng)成一個超大型的Mysql數(shù)據(jù)庫集群,OSS當(dāng)成一個超大型的文件存儲集群。RDS和OSS我們先討論RDS。雖然阿里云提供了lamp的一鍵安裝包sh-1.3,但事實上,本地的mysql效勞是不需要的。RDS的可靠性,易用性和可擴展性都比自己搭建的mysql效勞器要好很多。如果你仍在使用自己的mysql數(shù)據(jù)庫,強烈建議遷移到RDS。再說說OSS。ECS的本地磁盤上只應(yīng)存放業(yè)務(wù)代碼和配置,20G的系統(tǒng)盤完全夠用,這就是為什么前面不建議購置數(shù)據(jù)盤的原因。用于下載或用戶上傳的數(shù)據(jù)文件都可以存到OSS中。對于一個根本的建站業(yè)務(wù)而言,將動態(tài)數(shù)據(jù)存RDS,靜態(tài)文件存OSS,就實現(xiàn)了ECS的無狀態(tài)。在這樣的框架下,可以方便的對系統(tǒng)擴容:當(dāng)訪問量變大,現(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)響應(yīng)速度的同時緩解RDS的讀取壓力。RDS+OCS業(yè)務(wù)代碼的實現(xiàn)邏輯:如果要從RDS的表table0中讀取主鍵為id的數(shù)據(jù)項,先嘗試從OCS中讀取key="table0_id"的數(shù)據(jù),如果命中,那么使用從緩存中讀取的數(shù)據(jù),不用再訪問RDS如果緩存不命中,訪問RDS讀出數(shù)據(jù)v,以key="table0_id",value=v寫入OCS當(dāng)table0中的id數(shù)據(jù)項被變更或刪除的同時,刪除OCS中key="table0_id"的數(shù)據(jù)小結(jié)綜上,我們介紹了如何使用阿里云提供的ECS,SLB,RDS,OSS,CDN和OCS這6個業(yè)務(wù)來構(gòu)建我們自己的高可用業(yè)務(wù)網(wǎng)站系統(tǒng)。它的根本結(jié)構(gòu)如下列圖所示:幾點說明:通過外網(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ù)網(wǎng)站系統(tǒng)。在本篇中,我們將進一步介紹上面這些根底工具,以及如何從單業(yè)務(wù)系統(tǒng)拓展到多業(yè)務(wù)系統(tǒng),和日常開發(fā)和運維的一些常用技巧。多業(yè)務(wù)系統(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è)務(wù)系統(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è)務(wù)系統(tǒng)之間通信的常見方式,只要是兩個系統(tǒng)之間可以共享的系統(tǒng)資源,都可以通過一端寫入,另一端讀出來實現(xiàn)通信。而在阿里云的系統(tǒng)設(shè)計中,同一賬戶下的ECS可以共享RDS,OCS,MQS,OSS,ODPS這些資源。我們應(yīng)當(dāng)針對不同的應(yīng)用場景選擇適宜的資源類型加以利用。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ù)存儲集群的webapi.webapi負責(zé)查詢分布式內(nèi)存數(shù)據(jù)庫并計算分析后返回統(tǒng)計結(jié)果。前端系統(tǒng)拿到查詢結(jié)果后,用查詢參數(shù)hash出一個key,將查詢結(jié)果作為value存入OCS中。注意:該系統(tǒng)的實時性在很大程度上取決于OCS緩存的expiration.應(yīng)依據(jù)業(yè)務(wù)特點設(shè)置適宜的expiration值。如果對結(jié)果的實時性要求很高并且后端數(shù)據(jù)存儲集群的計算性能有充分平安邊際的情況下,也可以移除OCS,每次都重新提取數(shù)據(jù)計算結(jié)果。同樣,webapi系統(tǒng)也務(wù)必消除單點。在這里,我們可以使用內(nèi)網(wǎng)SLB解決。再探SLB在根底篇中我們介紹過外網(wǎng)SLB,并強調(diào)一切對外效勞一定要通過外網(wǎng)SLB開放出去以消除單點。同樣的,所有的系統(tǒng)內(nèi)部通信webapi也一定要通過內(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和,一般情況下,web效勞都采用的轉(zhuǎn)發(fā)方式,使用cookie來保持會話,這樣即使在應(yīng)用中使用本地文件來保存session,也不會成為問題。唯一的例外是給網(wǎng)站開啟CDN時,為了消除CDN回源的單點,自然的,我們不能用單臺ECS來回源,應(yīng)考慮使用SLB,然而,如果使用+cookie保持會話,CDN會由于頁面帶了cookie而拒絕緩存。這種情況下,只能使用無會話保持的轉(zhuǎn)發(fā)或TCP轉(zhuǎn)發(fā)。小結(jié)至此我們展示了幾個多業(yè)務(wù)系統(tǒng)的具體架構(gòu)。云計算的組件組合方式可以是多種多樣的。然而,在構(gòu)建高可用系統(tǒng)這個問題上,有幾個根本原那么可以參考:務(wù)必消除單點。(如果讀到這里您仍不理解什么是單點,請再看一遍根底篇

)盡量使用阿里云提供的系統(tǒng)效勞,不要自己用ECS進行重復(fù)建設(shè)。例如,使用RDS,而不是自己搭建mysql集群;使用OCS,而不是自己搭建memcached集群;使用OSS,而不是自己搭建文件效勞器;使用ODPS,而不是自己搭建Hadoop+Hive;使用MQS,而不是自己架RabbitMQ...一是可以大幅降低投入,二是盡可能的把高可用問題交給阿里云的運維團隊,而不是自己的運維團隊解決,會有更佳的效果。設(shè)計異?;謴?fù)機制。任何系統(tǒng)都有可能會出現(xiàn)各種異常,阿里云也不例外。例如:ECS的宕機遷移會使ECS實例重啟,最好在系統(tǒng)啟動時即自動啟動效勞;RDS和SLB都有可能出現(xiàn)閃斷的情況,需要自動重連;甚至云效勞節(jié)點間的內(nèi)網(wǎng)通信也有可能中斷,導(dǎo)致內(nèi)網(wǎng)SLB失效以及分布式數(shù)據(jù)庫brain-split這類對效勞質(zhì)量有很大影響的問題,所幸在這一年里我們只遇到過一次這樣的故障。平安平穩(wěn)的線上代碼變更。不管根底系統(tǒng)架構(gòu)多么完美穩(wěn)定,如果運行在上面的業(yè)務(wù)代碼劇烈震蕩,系統(tǒng)的可用性也還是個問題。所以在本篇的最后,我再介紹一下RippleTek的上線流程我們的每一個效勞都是通過至少一個外網(wǎng)SLB開放出去的。在每個SLB的后面,至少有兩個主效勞節(jié)點SRV1和SRV2。另外,還有一個線上引流測試節(jié)點pilot。當(dāng)需要線上代碼進行變更

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論