附上原圖連結點選開啟連結，並推薦大家使用Drawio這個工具繪圖。以下是我為初創公司設計的架構圖，多有不對，希望大家拍磚，努力學習AWS中，希望和大家分享交流，有意向過AWS認證的夥伴，請聯絡我。閒言少敘，進入主題。

這是一個四層結構的應用架構，其中包括網路層，web伺服器層，Redis叢集層，資料儲存層。另外該架構圖中還包括Devops和伺服器執行情況指標監控元件和相關流程。

首先是網路層：通過構建VPC虛擬網路，藉助VPC中可以指定iP段，路由表以及閘道器的配置，在一定程度上做到了內外網的安全隔離。當internet使用者訪問部署在AWS中的服務時，首先會通過Route53實現的DNS域名解析服務，連線到

在網路層還有一個重要的服務用來降低使用者訪問延遲性，那就是使用CloudFront和邊緣站點實現網站內容快速分發網路，CloudFront能夠使的邊緣站點快取靜態和動態 web內容，當用戶請求CloudFront提供的內容時，使用者會被引導到距離最近，延遲最低的節點，以便傳送的內容具有最佳效能。如果內容已經在該節點中，CloudFront會立即反饋給使用者。如果內容目前不在該節點中，CloudFront 將從web 應用服務或S3

EC2安全組可作為虛擬子網和客戶端防火牆的一個組合。EC2安全組中的每一個例項都共享著一個通用安全策略；類似於防火牆的規則控制著各個組之間的流量。防火牆的預設行為是拒絕流量的，而特定規則可允許出入站的連線。

—-（還需要了解，如何做到快速響應，和快取內容，如何保持內容的最新性）以上就是網路層的架構設計

AZ

   AWS的每個區域一般由多個可用區（AZ）組成，而一個可用區一般是由多個數據中心組成。AWS引入可用區設計主要是為了提升使用者應用程式的高可用性。因為可用區與可用區之間在設計上是相互獨立的，也就是說它們會有獨立的供電、獨立的網路等，這樣假如一個可用區出現問題時也不會影響另外的可用區。在一個區

網路層後，接下來就是web應用服務層，通過使用 Auto Scaling與 ELB 整合來實現應用服務的可用性和擴充套件性，將ELB附加到現有 Auto Scaling組實現負載均衡，它能夠自動註冊組內的例項，並將傳入請求分配給這些例項。在可用性方面，如果有服務失敗宕機，那麼auto-scaling 能夠迅速發現問題機器並啟動一臺新的機器，持續服務。在擴充套件性方面使用 Auto Scaling，可以設定Min/MaX/引數實現自動擴縮 EC2 的服務例項數量。（還要看ELB和AUTOSCALING原理）。

那麼在WEB應用服務層後，

Elastic Load Balancing 支援兩種型別的負載均衡器：應用程式負載均衡器和傳統負載均衡器。通過傳統負載均衡器，在負載均衡器中註冊例項。通過應用程式負載均衡器，在目標組中將例項註冊為目標，並將流量路由到目標組。（還需要解釋選擇應用程式負載均衡器的理由）

接下來，就是 Redis 快取叢集服務層，這裡我使用的是Redis已禁用叢集模式（為什麼選擇），該層的主要職責提高生產部署的可靠性，緩解前端請求對資料庫訪問的壓力，降低延遲，還可以起到防災、減災的作用。由於使用了VPC，我們可以使用VPC的安全組和子網策略來控制對快取群集的訪問，Redis 複製組包含一個應用程式可讀寫入的主節點和 2個只讀副本節點。在向主節點寫入資料時，也會在只讀副本節點上非同步更新資料。這樣可以有效的防止節點故障，而在兩個可用區各分別部署一個叢集服務，主要是為了避免可用區故障。

為什麼選擇

 •您需要為讀取操作密集型應用程式將主群集中的資料複製到一個或多個只讀副本。

•您需要在主節點出現故障的情況下執行自動故障轉移。

•您需要釋出和訂閱 (pub/sub)功能 -向客戶端通知伺服器上發生的事件。

•您需要備份和還原功能。

•您需要支援多個數據庫。

最後，就是資料儲存層，資料庫通常是系統最重要的部分，應用程式如果不能連線到資料庫他們將無法工作，該層的主要職責是負責資料庫的高可用和高效能的資料儲存，一個高可用的資料庫通常包含兩個資料庫例項:一個主資料庫和備用資料庫。當所有請求傳送到主資料庫時，由 RDS例項來負責響應伺服器請求，完成對資料的讀寫操作。主和備用資料庫之間的資料同步複製。如果主資料庫由於硬體或網路故障而不可用時，RDS會自動偵測到故障，啟動故障轉移過程，備用資料庫將成為了主資料庫，同時DNS也會自動更新，來實現快速故障轉移。

一個高效能的資料庫對應用程式的反應效率是至關重要的，我們通過使用高效能的儲存型別（IOPS(SSD)）保證資料庫提供高效能的讀寫操作。與此同時，對資料進行有效的保護和儲存也是至關重要的，因此考慮到資料庫中的資料備份，我們可以通過RDS快照實現資料備份，除此之外，可以利用AWS Datapipeline 實現更加廉價的備份策略，定期執行資料庫備份指令碼進行備份，並存儲在S3資料桶中，來實現資料進行有效的保護和儲存。

那麼以上就是我設計應用程式架構，接著為大家介紹的是DevOPS架構：

Part 2：DevOp的實現，在我的架構中主要是通過EC2和 Auto Scaling結合，利用 CodePipeline，CodeCommit， Codebuild ，CodeDeploy  這些服務元件來實現的. 首先會使用AWS CodePipeline來構建一個工作流，定義開發人從本地開發環境提交到 CodeCommit中的程式碼。由Codebuild會完成編譯測試工作後，將其打包成可部署的包存放在SS的資料桶中，最後又codedeploy來從資料桶中獲取部署包，並按照appspec修訂檔案中定義好的部署規則來將包釋出到部署組，每個例項上的 CodeDeploy代理將定從指定的 S3 儲存中提取的內容。並按照 AppSpec檔案中的說明向例項中部署內容。

那麼這就是我設計得DEVOPS流程

最後，在架構中還要介紹，整個系統可以通過使用CloudWatch來監控整個系統的記憶體使用率、處理器利用率、快取命中率等一系列指標來監控伺服器執行狀況。

此外，藉助可用區實現物理隔離來確保服務的高可用，為每個例項關聯彈性 IP，使得auto scaling一旦檢測到的故障例項並重新載入新的例項後，EIP能夠重新分配到新的例項，從而保證例項重啟後IP地址不發生改變，為執行指令碼和自動化提供便利。

接下來介紹的是在架構圖中使用到的一些AWS服務元件以及選擇他們的原因。

第一點，需要保證的就是服務的可用性，AWS有能力處理大多數web應用伺服器的失敗，並能夠在短時間內恢復服務。因此構建高可用的服務元件我選擇了：

元件1 ，多可用區:使用多可用區，能夠確保如果有一個可用區發生故障，使用者請求可以重定向到其他可用區中正常工作的例項，而這所有這一切使用者是感覺不到的。

元件2， CloudWatch：通過檢測例項執行和效能指標，可以發現潛在的問題，並將潛在的問題傳送給運維團隊。

元件3， Auto Scaling：使用它能夠構建一組可用性很高的例項叢集。當大量請求到達時,它可以自動擴大EC2例項數量，當請求降低時，它還能夠自動縮小。

元件4， EL”:使用它，主要是為了實現多可用區的負載平衡。另外，還起到容錯功能，保證請求流量總是被分流到健康的EC2例項。

……………………………………………………………………………………………………………………………………………………………………………………………………………

第二點，高效能也是客戶非常關注的，AWS幾乎覆蓋全世界11個主要區域，42個可用區，52個邊緣站點，在提供高可用的服務同時，也能夠提供高效能服務。

Route 53 是一個多區域擴充套件的 DNS服務，當來自各地的請求到達後，它能夠重定向使用者請求到距離他們最近的web服務站點中去，配合使用 CloudFront和邊緣站點，S3，使用者能夠使靜態檔案的訪問更快捷，高效；

S3 可用來持久化靜態物件，例如，部署歸檔檔案，指令碼，資料庫備份檔案和日誌，媒體檔案等。

ElastiCache(redis叢集)會更有助於效能的提升，通過快取資料來減少資料庫連線次數。從而更快的響應客戶，

……………………………………………………………………………………………………………………………………………………………………………………………………………

第三點，就是安全方面: 我們認為使用者的任何資料都是非常重要的，需要有效的保護。AWS通過自動監控系統可以做到保護網路和增強網際網路接入的安全性，防止分布式拒絕服務(DDoS)攻擊。退役的儲存裝置也會從物理層面上進行徹底的銷燬。AWS還能夠確保資料中心的物理環境安全。

我主要選擇了這幾個元件：

VPC : 構建虛擬網路隔離來自外部網路的資源。

安全組：允許在每個層級配置訪問規則，在我的結構中，web層的安全組，我們可以定義只允許HTTPS訪問伺服器，我們也可以為web訪問暴露特定的埠。

在資料儲存層，也設有安全組，滿足定義在每個級別訪問底層資料的解決方案。

子網：

IAM：為所有使用者提供安全訪問許可權控制，通常IAM使用者組包括，系統管理員，開發測試組，經理組，他們分別擁有不同訪問和操作的AWS EC2和AWS S3資料桶的許可權。

最後是對使用者的需求做的梳理，對應我所設計得架構方案：

針對滿足需求的擴充套件能力 - 這個架構在web應用層使用了auto-scaling服務與AWS EC2例項相結合的方式是可以做到快速可伸縮的

針對缺乏災難恢復機制 - 在我的架構中使用了由主資料庫和備資料庫構成的高可用資料庫。

針對使用者體驗的低延遲 - CloudFront能夠使的邊緣站點快取靜態資料.  加速分配給終端使用者的 Web 服務。

針對基礎設施和服務例項故障失敗恢復 - 通過 Cloudwatch中定義的報警指標檢測auto-scaling。

針對資料在傳輸過程中的安全，由於VPC起到了隔離資源的作用。那麼在網路層可以僅由客戶使用IAM給定的特權來建立連線。資料在運輸過程中可以通過SSL / TLS傳輸協議。

針對隨著交付團隊擴大確保訪問環境的安全——使用IAM定義，使用者，角色，和組的不同許可權

針對活動物件大於6個月的歸檔策略 — —通過使用S3 物件生命週期規則定期向Glacier移動日誌和其他資料。

針對能夠輕鬆地管理和複製多個環境，方便以後管理可以通過使用BeanStalk快速部署PHP應用程式。

一個是 RTO，另一個是 RPO。所謂 RTO，Recovery Time Objective，它是指災難發生後，從 IT系統當機導致業務停頓之時開始，到 IT系統恢復至可以支援各部門運作、恢復運營之時，此兩點之間的時間段稱為 RTO。所謂 RPO，Recovery Point Objective，是指從系統和應用資料而言，要實現能夠恢復至可以支援各部門業務運作，系統及生產資料應恢復到怎樣的更新程度。這種更新程度可以是上一週的備份資料，也可以是上一次交易的實時資料。