想學習 AWS 卻又不知道從何下手？初探 AWS 雲端架構
最近自己的技能樹正在往雲端技術的方向生長，主要學習的服務為 AWS (Amazon Web Service)。不過 AWS 少說也提供了上百項雲端服務，為了學習要一項一項去翻官方文件肯定是會力不從心的，顯然不是一個好方法。我自己找到了一項比較適合自己的學習方式（也許並不適合正在閱讀這篇文章的你），也就是從架構面下手，要知道，不同的應用對應出來的軟體架構也會截然不同，例如一個 Web Application 跟一個數據分析應用，在架構上肯定會不同的，可想而知使用的雲端服務也會有所不同。因此以我自己為例子，主要涉獵的領域在 Web 開發，可以先去了解 Web 應用的雲端軟體架構為何？會使用哪些服務？確定後再去學習對應的服務，如此一來可以避免學了一些自己根本不知道會不會用到的服務。而我認為先掌握架構，對整個應用流程有基本的理解後，再去學習個別的服務要怎麼使用會容易許多。
也許這樣的學習方式並不適合你，但如果你是沒有學習方向的初學者，我覺得不妨一試。透過這篇文章，我會介紹 Web 應用在 AWS 上常見的雲端架構及其演進過程，文中僅會簡述各個服務的功能，不會詳細介紹，不過相信在看完本篇文章後，你也能大致理解現今的雲端軟體架構，並有明確的方向知道要學習哪些服務，還有應該串接哪些服務來建構自己的架構，Let’s Go！
行前說明
沒有所謂一定正確或完美的架構，實際上都應該依照實際的需求去變動架構，例如新增或刪減一些服務。因此我下面所介紹的架構不一定是對的，也不一定適合每一個專案，只能說它們是我認為最普遍被開發者所認同的架構，各位可以把它們當作骨架，讓你迅速建構出軟體架構的雛形，再依據自己的需求去做調整。
另外也建議閱讀這篇文章的讀者至少對資訊應用架構有基本概念，會比較好理解文章的內容。
從來沒碰過雲端，該怎麼踏出第一步？讓我們從「經典架構」開始談起
也許你接觸軟體開發已經一陣時間了，也知道基本的軟體架構長什麼樣子，但談到雲端架構，你卻腦筋一片空白，因為你從來沒碰過雲端服務及其架構，深怕它跟以往的軟體架構有著天壤之別。不過別擔心
你在本地端怎麼做，在雲端上就怎麼做。大部分的架構思路，在雲端上是可以套用的。
如果我們用本地開發的思維，那麼最簡易的應用架構可能是這個樣子：
使用者發送網路請求並透過 DNS 服務解析域名，再轉發到網頁伺服器，網頁伺服器可能直接回傳靜態內容，也可能再轉傳請求到應用伺服器（例如 Node.js 架設的 Application Server），應用伺服器跟資料庫要資料或做對應操作，再把結果回傳給使用者。除此之外，可能還需要做好使用者的權限控管、建立服務與使用者的監測系統，方便觀測軟硬體的 Log。
前面說過了，「本地怎麼做，雲端就怎麼做。」因此上面的架構如果透過 AWS 雲端服務來建置，可能會變成這樣：
對應以上兩張圖可以猜到，Route53 應該是 AWS 的 DNS 服務，EC2 是虛擬主機，RDS 是雲端的資料庫服務，S3 則是可以拿來存放檔案資料的雲端儲存服務。上面提及的權限驗證與監控系統，AWS 也提供了相對應的解決方案：AWS IAM 用來管理使用者的權限，CloudTrail 可以對使用者的行為進行監控，CloudWatch 則是幫助監控 EC2、Route53 等資源的使用狀況。
了解了以上的架構，我們就知道如果要使用 AWS 雲端服務建立基本的應用架構，大概需要熟悉 AWS 提供的哪些服務了，是不是馬上就有了方向了呢？
以上這種非常基礎簡單的雲端架構又被稱作「經典架構」。
大型系統 ＆ 高併發架構
然而現今的軟體隨著應用的複雜化與使用者流量的增長，更追求架構的「可靠性 Reliability」、「高可用性 High Availability」與「穩定性 stability」，簡單來說就是系統的故障率要盡量降低且可以被訪問與操作的程度要是高的。很顯然的經典架構暴露著「單點失效 Single Point Of Failure」的風險，當遇到流量高峰 server 沒辦法負荷炸掉了，沒有對應的 Failover 機制，整個應用也許就跟著崩壞。
因此一般我們會在經典應用的基礎上再去擴展我們的架構，使其能夠處理高併發的流量。
擴展的主要方式是透過「水平擴展 Horizontal Scaling」，啟動多台 Server，透過負載均衡器將流量導到不同 Server 上來達到分流。不過需要注意的是，如果請求是 stateless 的，那麼這樣並沒有什麼問題，但萬一請求需要儲存使用者的狀態，我們可能會需要同一個使用者透過 Load Balancer 導到的都是同一個 server，在分流時則需要透過 Sticky Session 或是 Consistent Hashing 來解決。而對於一些耗時的非同步操作，我們可以透過 Message Queue 訊息佇列來消化掉，才不會讓使用者的 request 卡住造成系統塞車，在 Message Queue 身後的是被稱作 Worker 的 Server Instance，負責擔任 Queue 的 Consumer，從 Message Queue 取出訊息並作對應處理。最後為了提升效能，減少對資料庫重複的操作，我們可以增加一層快取層。如果對應到 AWS 的服務，以上的架構可能長得是這個樣子
這邊加入了 AWS CloudFront 的 CDN Server 來提升效能，如果不了解 CDN 的可以參考我之前的文章：Coding your CDN ! 充滿驚奇的 AWS Lambda@Edge，再來是使用 AWS ELB 當作附載均衡器，負載均衡器後面接的是 AWS Auto Scaling，可以按照流量變化幫我們自動增減伺服器，例如在特定流量高峰時間增加機器，或是在 CPU 用量到達特定百分比時增開機器…等，AWS Auto Scaling 提供了許多 Scaling Policy，相信一定可以找到適合你需求的方案。Message Queue 的部分則是使用了 AWS SQS (Simple Queue Service)，資料庫則是可以依照需求替換，上面我選擇放置 DynamoDB。Cache Service 則可以使用 AWS 的 ElasticCache，它提供了 Memcached 與 Redis 兩種底層引擎，而緩存又有許多不同的操作手法，最常見的就是 write-through 與 lazy loading，這邊推薦一篇鐵人賽的文章，寫得清楚易懂。而前面提過的負責權限控管與監控的 IAM、CloudWatch、CloudTrail 等服務當然得繼續存在。
這就是最基本的面對高併發流量的雲端架構，為什麼說是最基本的呢？ 因為其實還有非常非常多的擴展方向，尤其是資料庫層，我們在先前的架構中是完全沒有提到資料庫相關的架構調整的，常見的讀寫分離、Hot Standby、Sharding 與 Partition 都是可以考慮的方向。另外更進一步的架構調整甚至可以考慮 Multi-Region，增加應用的可用性
高併發架構差不多就介紹到這裡，當然有很多遺失的拼圖與很多可以改善的地方，不過我想透過了解最簡單的架構，我們已經可以掌握學習方向。
無伺服器應用 — Serverless Architecture
Serverless 的流行也對軟體架構產生改變（不知道 Serverless 的讀者可以參考這篇文章），許多雲端供應商都推出了自己的 FaaS 方案，以 AWS 為例就是大名鼎鼎的 AWS Lambda。這些 FaaS 解決方案大多都有會 Auto Scaling、依照使用量收費、像容器化技術一樣運行才開啟，運行完則迅速關閉等特性。要知道 Serverless 並不適用於所有的軟體應用，尤其是需要長時間不間斷運行的應用，用 Serverless 並不會帶來什麼好處，成本甚至可能超過直接長期租用虛擬機，因此還需參考自身的需求判斷是不適合採用 Serverless。其實如果要透過 AWS 學習 Serverless，方向還挺明確的
主要就是學習 AWS Lambda 與當作整合性接口的 API Gateway。
傳統架構跟雲端架構，只能擇一嗎？
答案是否定的。就算想要把傳統架構轉換成雲端架構，過程肯定也是漸進式的，而當你的架構成功遷移到雲端上，原本的本地端機房也未必就沒了價值。
本地機房與雲端混合使用，可以保留架構的彈性，這種架構也稱作「混合雲」架構。
混合雲是一種雲端運算模型，它通過網絡連接組合一個或多個公用雲和私有雲環境，允許在不同的雲環境之間共享數據和應用程序。它也同時擁有公有雲與私有雲的特性，例如公有雲可以根據需要擴展和縮小計算能力以降低成本，私有雲可以讓你更好的控制物理資源，但相對的成本也更高。
這部分我就了解的不太深了，有興趣的讀者再自行研究囉！
結論
透過短短的一篇文章，我們了解了雲端的「經典」、「大型＆高併發」、「無伺服器應用」三種基礎架構，先了解架構是我認為學習雲端服務比較有效率的一種方式，透過架構，我們知道面對百來種的雲端服務中，該去選哪些來研究，避免成為無頭蒼蠅的窘境。不過除了學習那些服務，我建議讀者也要先熟悉網路相關的概念，之後在學習上可以少走點路，畢竟那麼多的服務要進行溝通，還要注意通訊安全，背後的網路原理必定是複雜的，例如可以透過 AWS VPC (Virtual Private Cloud ) 去了解 AWS 的網路環境組成。本篇文章就到這裡，希望可以幫到螢幕前的你囉！
