以單Elastic Beanstalk來進行建置

通常就這個架構是偏向單純

但是如果是在系統運作上面附載高低差很大的時候

為了資源利用率最大化通常會使用

Load Balancing 與 auto scaling 的架構運行就會是必要的

在這種狀況之下除了 Load Balancing 類型的選擇之外

您還需要考慮到

1. login機制
2. Cache的共用是否有存在的必要
3. 共用資料夾的必要性
4. data存放的位置選擇

但對於開發者來說這些都是可以用程式修改來進行排除的問題

對於營運者來說還可以再更一步地考慮到既然系統的擴展之外的問題

通常對於系統工程師來說維護附載平衡與知間的一致性就是一個很大的工程

但在於Elastic Beanstalk當中

你發現到的是著重不止於擴展這件事情上

而是服務的整合與增進服務品質之上

 

[架構師悄悄話…]

或許有點誇大

但是在雲端與傳統IDC的建置方式中

“建置1000個同時1000人上線的服務”對比”建置1個可容納100,000的網站”

在雲端的建置方式後者的難度遠高於前者

這點對於傳統的IDC維運人員來說是比較不可思議的

因為在這些年的硬體發展中

硬體效能的成長幅度其實一直沒減慢過

而且硬體相關的解決方案一直沒有少過

但是如果再考慮成本效益的情況之下

雲端服務的效益絕對會比較好

 

上一篇:Day02 – Elastic Beanstalk 架構說明(1)

下一篇:Day04 – Elastic Beanstalk 操作說明(1)