基于亞馬遜云的快速架構設計,適用于創業型互聯網公司

AWS 架構設計: 需求

概要

有這么一個小公司,處在創業階段的起步期。他們正在使用的架構是 LAMP 環境。在他們狹小的辦公室里,一臺 PC 運行了所有的 MySQL、Apache 和 PHP。雖然如此,他們還是和許多創業者一樣,心懷遠大,深信自己就是下一個谷歌或蘋果。他們期待幾個月后,業務就會發生翻天覆地的高速增長,那增長大到他們無法衡量。野心和幻想的交織下,他們開始用心考慮如下問題:

-如何擴展系統,才能跟上需求的增長,又能兼顧到各種不確定因素。實際上,他們根本不知道需求什么時候會來,又會有多大。所以,他們一方面不想過早購買太多的設備,另一方面又擔心設備不足后悔莫及。

-災難恢復上,缺乏措施和方案。

-在高效和高容量系統上,他們缺乏配置數據庫和數據庫訪問層的能力。

-如何讓用戶通過瀏覽器訪問時,保持極低的系統延遲。要考慮到他們大部分的用戶距離極遠。

-有效的負載均衡。

-基礎設施如何實現自我修復。能夠將失效的服務實例恢復運行。

-在存儲和傳輸中,數據的安全問題。

-交付團隊擴大后,對環境的訪問能夠保證安全。

-歸檔策略,針對閑置超過6個月的對象。

-輕松管理多個環境,并根據藍圖架構復制環境的能力。

目標

要支持創業公司的快速增長,我們所建議的架構必須滿足:便于管理、安全、可擴展、高性能、高效率、彈性、高可用、容錯、可恢復。這種架構必須解決上面所述的各種需求及顧慮。

解決方案:

下面所描述的,乃是一個概要層次的架構設計,對于期待快速增長的創業型互聯網公司,有著很強的針對性。所建議的架構,基于亞馬遜的 AWS,因此完全可以滿足各種不同的企業應用。設計方案的目標讀者,是公司CTO,研發總監/經理和其他參與技術決策的負責人。

為何推薦?AWS 給創業公司?

AWS 解決方案的彈性特征,給創業公司提供了企業云計算能力。

要考慮到創業公司的所謂增長,都還是沒影的事。為了追求投入的性價比,解決方案就必須可以方便的伸縮,以適合業務的增長趨勢。AWS 的組件,全部都是彈性的,可以在運行時根據負載,進行自動伸縮。比如,當服務器上的負載增加或者減小時,可以使用 EC2 增加更多的服務器,或者減少服務器。AWS 按量付費的定價模式,讓用戶的投入也是彈性的。 這樣一來,負載增加,用戶增加資源,付更多的費用;負載減少,用戶縮減資源,則費用降低。AWS 給解決方案帶來良好的彈性,可以應對任何時候的任意負載。

在處理突發流量負載上,AWS 解決方案的彈性極強

互聯網系統在高峰負載時,常常性能下降。這都是因為資源無法實現伸縮,難以滿足突發負載。AWS 可以自動配置 VM 實例,幫助用戶在負載增加時添加更多的web服務器。當負載回歸正常后,又可以關閉或取消這些服務器。這個功能,讓整體解決方案在面對隨時變化的流量負載時,具備足夠的彈性。

部署和維護的便捷性

創業型的公司,系統需求變更頻繁,系統的部署更新也就非常頻繁。在開發、測試、集成測試和生產各個階段,都需要和一致的運行環境。AWS 對資源進行按需配置的特性,便于用戶在每個階段輕松的部署和測試系統更新,最終保證順利的生產發布。這就極大的減少了在開發環節需要投入的硬件和維護成本。

創業型互聯網公司的 AWS 云計算架構:

在此架構中,我們將關鍵組件進行分類。

下面所列分層,每個層次的管理都需要相應的技能。這樣的分層,幫助企業在增長時,合理分派員工,對訪問權限、安全和組件的所有權進行管理。

基于管理技能對關鍵組件進行分類:

1. ?網絡層:

a.? 管理外部/內部網絡配置和安全,可使用的工具包括 AWS Route 53,ELB,多可用區,Elastic IPs, Security Groups 等。

AWS Route 53?是一種可用性高、可擴展性強的云域名系統 (DNS) Web 服務。它的目的是為開發人員和企業提供一種非常可靠且經濟高效的方式,把名稱(如 www.example.com)轉換為計算機用于互相連接的數字 IP 地址(如 192.0.2.1),從而將最終用戶路由到 Internet 應用程序。

ELB (Elastic Load Balancing) 在多個 Amazon EC2 實例間自動分配應用程序的傳入流量。使用 Elastic Load Balancing,您可以提高應用程序的容錯性能,同時提供持續響應應用程序傳入流量所需要的負載均衡容量。Elastic Load Balancing 可以檢測出池內的不健壯實例,并自動更改路由,使其指向健壯實例,直到不健壯實例恢復健壯為止。客戶可以在單個可用區域或多個可用區域中啟用 Elastic Load Balancing,以提高應用程序性能的一致性。在 Amazon Virtual Private Cloud (VPC) 中也可以使用 Elastic Load Balancing 來在不同的應用程序層內部分配流量。

多可用區 (Multi-Availability Zones) 亞馬遜在全球11個地區(region)擁有數據中心。 每一個地區擁有最少2個可用區(Multi-Availablity Zone),一個可用區由一個或多個數據中心構成。

Elastic IPs,彈性 IP 地址是專為動態云計算設計的靜態 IP 地址。彈性 IP 地址與您的 AWS 賬戶關聯。借助彈性 IP 地址,您可以快速將地址重新映射到您的賬戶中的另一個實例,從而屏蔽實例故障。彈性 IP 地址是公有 IP 地址,可通過 Internet 訪問。

安全組(Security Group):在EC2環境中啟動的實例都屬于某一個安全組。每個安全組定義自己的防火墻規則,為在組中運行的實例指定訪問限制。可以根據IP地址或無類域間路由(CIDR)規則授予或限制訪問權,CIDR規則允許指定端口范圍和傳輸協議。

b. ?保證來自全世界的訪問,都能夠正常到達網站。并實現各種層次的負載均衡,比如在 web 服務器層和 app 服務器層進行負載均衡。

2.? Web 服務器層:

a. ?管理 Web 服務器,可用的組件包括 AWS EC2, AMI 鏡像等

b. ?配置和維護 web 服務器實例,保證對 web 請求的處理。

Amazon Elastic Compute Cloud (Amazon EC2) 是一種 Web 服務,可在云中提供大小可調的計算容量。該服務旨在降低開發人員進行網絡規模級云計算的難度。

亞馬遜機器鏡像(AMI)是啟動一個實例時,所要提供的信息。實例實際上就是云端運行的一個虛擬服務器。AMI 包括實例 root 卷的模板(例如,操作系統、應用服務器、應用),使用權限,啟動實例時要掛載卷的塊設備映射。

3.? App 服務器層:

a. ?使用 AWS EC2,AMI 鏡像等,管理 App 服務器,

b.? 配置和維護 App 服務器實例,保證對 web 請求的處理。

4. ?數據庫層:

a.? 使用 AWS RDS, IOPS Volumes 等,對數據庫服務器和數據進行管理,

b. ?負責對后臺數據庫訪問、安全、性能和可用性的配置及維護。

Amazon Relational Database Service (Amazon RDS) 讓您能夠在云中輕松設置、操作和擴展關系數據庫。它在管理耗時的數據庫管理任務的同時,可提供經濟實用的可調容量,使您能夠騰出時間專注于應用程序和業務。Amazon RDS 提供 6 種熟悉的數據庫引擎供您選擇:Amazon Aurora、Oracle、Microsoft SQL Server、PostgreSQL、MySQL 和 MariaDB。

Amazon Elastic Block Store(EBS)可作為EC2實例的持久性數據塊級存儲。
Amazon EBS共提供三種硬盤類型,SSD(固態硬盤), Provisioned IOPS SSD(特供IOPS固態硬盤)和Magnetic(普通硬盤)。SSD是默認的EC實例的硬盤格式,Provisioned IOPS SSD具有高一致性及超低延遲的性能,專門設計用于I/O密集型操作,比如數據庫。IOPS全稱為Input/Output Operations Per Second,即每秒進行讀寫(I/O)操作的次數,用來衡量隨機訪問的性能。

最終用戶側:

無宕機的系統/網站: 獲得更多用戶并保留住他們的關鍵是保證網站永遠可用。達到高可用性,就需要在各個層次為故障制定防備策略。亞馬遜為互聯網產品在各個層面,提供了防備故障的能力。例如使用“多可用區”,這樣用戶就會被分發到處于某個選定地區的有效實例。


如上圖結構所示,www.mywebapp.com 的用戶訪問“區域”(region)是新加坡,使用了兩個“可用區”,一個是ap-southeast-1,一個是ap-southeast-1a。當來自新加坡的用戶進入 www.mywebapp.com,則系統分發這個訪問請求到ap-southeast-1或者ap-southeast-1a。若是其中一個“可用區”失效,則用戶請求自動轉移到另一個“可用區”。當故障恢復后,用戶請求再次分發到兩個“可用區”。 這些動作,用戶不受任何影響,甚至覺察不到。網絡運營小組,也無需干涉,一切都是自動執行的。

更快的網頁速度:互聯網用戶可能來自世界上的任何地方,必須保證網頁和應用的加載是快速的。實現這個目標,最簡單的方法是將互聯網產品部署到靠近用戶的地理位置。亞馬遜在全球主要的地區都擁有多個“區”。 通過將網站托管在亞馬遜 Route 53 托管區,便可以將用戶訪問分發到最靠近他們的區,從而保證網站的訪問速度。還可以使用亞馬遜 CloudFront 和 S3,對靜態文件的訪問進行加速。其他加速措施還包括,為 RDS,網頁和應用數據增加更大的 IO 性能。

Amazon CloudFront 是由Amazon提供的一套覆蓋全球的CDN網絡。該服務擁有云計算服務特點,可以根據流量和請求數量進行收費,并且相對來說費用還算低廉,因此適合小型公司或個人。

Amazon Simple Storage Service (Amazon S3) 為開發人員和 IT 團隊提供安全、耐久且擴展性高的云存儲。Amazon S3 可輕松使用對象存儲,具有簡單的 Web 服務接口,可用于在 Web 上的任何位置存儲和檢索任意數量的數據。使用 Amazon S3,您只需按您實際使用的存儲量付費。沒有最低費用和準備成本。

用戶數據安全:用戶的業務數據非常重要,需要極致的保護,防止未經授權的訪問。在選擇互聯網服務時,安全就成了首要考慮因素。亞馬遜“安全組”(Security Groups)可以用來在系統的各個層次對訪問規則進行配置。以上圖的架構為例,在“Security Group: Web Servers”(安全組:web 服務器)上,可以定義規則,只允許 https/http 協議可以訪問 web 服務器。在 “Security Group: App Servers”(安全組:應用服務器)上,可以定義規則,只允許自己的web 服務器,從固定的端口,用固定的協議,去訪問應用服務器。同樣的方法,可以去定義數據庫訪問策略到“Security Group: DB Access”(安全組:數據庫訪問)。這樣一來,對資源的外部訪問就被總體上定義清楚,只有滿足了每個層次上的所有安全要求,才能夠獲得對數據的訪問。 通過使用 HTTPS,也保證了數據在傳輸過程中的安全。

基礎架構側:

快速的服務器調配:服務器資源的高可用性,對每一 IT 公司來說,都是持久不變的追求。可用性不理想,提供給客戶的服務質量就會降低。 使用 AWS EC2 實例,可以瞬間啟動多個 VM 實例。而通過 AMI 設置,更進一步,可以將所需的個性化配置存在鏡像里,然后通過這種鏡像啟動實例。帶來的好處是,隨時可以在流量高峰時,啟動更多的 VM 實例。如果還不滿足,則可以使用 Auto Scaling 服務創建“容量組”,可以隨著容量需求變化而自動的增長和縮小。

Auto Scaling服務,EC2實例可以被放置在被稱為Auto Scaling Group的邏輯組中,經過簡單的、適當的設置,這些EC2實例將立即具備高可用性、自動橫向擴展能力、定時橫向擴展能力。

負載的自動分發: AWS ELB可以對來自用戶的web請求,執行自動負載均衡,將請求分發到不同的web 服務器組。這樣,負載平均的發送到服務器上,保證用戶體驗的質量。一切都是自動實現的。

簡化的 IT 網絡運營:實現了對資源進行自動擴張,還需要考慮整體系統的可靠性和運營能力。為了簡化這個工作,亞馬遜提供了 CloudWatch 功能,實現對 EC2 實例的健康狀況監控。 Auto Scaling 便可以基于監控獲得的數據,執行 EC2的擴張和縮減。 這就保證了快速伸縮的同時,無損服務可靠性。

Amazon CloudWatch 是一項針對 AWS 云資源和在 AWS 上運行的應用程序進行監控的服務。您可以使用 Amazon CloudWatch 收集和跟蹤各項指標、收集和監控日志文件、設置警報以及自動應對 AWS 資源的更改。

簡化的存儲管理: 使用 AWS Elastic Block Store 功能管理存儲卷。用戶為實例創建一個持久的存儲卷,這樣系統重新啟動后,重啟的實例自動掛載正確的硬盤/存儲設備。 這個特性保證了應用和系統能夠訪問一致的數據。

Amazon Elastic Block Store (Amazon EBS) 可在 AWS 云中提供用于 Amazon EC2 實例的持久性數據塊級存儲卷。每個 Amazon EBS 卷在其可用區內自動復制,以保護您免于組件故障的威脅,同時提供高可用性和持久性。

簡化的數據庫維護:AWS 支持幾乎所有的主流數據庫,包括 Oracle, MySQl, MS SQL。有了 RDS,數據庫可以實現自動備份,并能夠進行任意時間點的恢復。RDS 在多個可用區的部署,帶來了最關鍵的好處是保護數據庫不受意外故障的破壞。在上面的架構示意圖中,選擇了 "M" RDS 數據庫實例作為"主/首要“數據庫。 不論從那個可用區訪問網站,所有的請求在數據庫層次,都被分發到位于ap-southeast-1區的主數據庫實例。 然后,為主數據庫創建一個拷貝,配置到其他的可用區,例如ap-southeast-1a中,作為備份數據庫運行。 當主數據庫實例出現宕機,則系統自動切換到位于ap-southeast-1a的備份數據庫。當主數據庫再次恢復運行后,又可以從備份數據庫切換回主數據庫。如果更進一步,使用了 EBS 部署數據庫文件,即便在數據庫主機宕機時,還可以獲得和持久的數據庫文件一樣的高性能。

總結:以上建議的架構中,所用的 AWS 特性及功能,完全可以幫助創業公司實現云計算,在基礎架構上獲得低成本、高擴展性和容錯等好處。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,461評論 6 532
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,538評論 3 417
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,423評論 0 375
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,991評論 1 312
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,761評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,207評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,268評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,419評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,959評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,782評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,983評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,528評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,222評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,653評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,901評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,678評論 3 392
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,978評論 2 374

推薦閱讀更多精彩內容