標籤：
：完整mp4視頻
演講人：張俠 博士
1. 邱洋的理解
2. 初創公司提的業務和技術要求
- 快速驗證產品服務
- 為機會視窗而爭分奪秒（互連網1年等於傳統7年，狗年）
- 小的技術團隊沒有曆史包袱
- 關注於提供方案解決問題
- 避免工程大而全和返工
- 規避風險準備迎接高速成長
3. 初創公司的技術選型3.1. 常見技術堆棧
- 作業系統：linux：centos，redhat，suse，ubuntu
- 移動端：IOS、Android；HTML5
- 網站前端：PHP/ASP/JSP、HTML/CSS
- 前端架構：Flex，jQuery，Sencha
- 開發工具：Eclipse，SVN，SDK/IDE
- 技術架構：Struts，Springs，Hibernate；Velocity；Ruby on Rails
- 開發語言：Java，PHP，Python，Ruby，Net，Node.js，GO
- 負載平衡：軟體：Nginx，Squid；硬體：F5，Citrix Netscaler
- 資料庫：RDB：MySQL；NoSQL：MangoDB
- 緩衝：Memcached ，Redis
- 內容發布：CDN，DNS
- 其他：Lucene（全文檢索索引工具）
3.2. 架構的考慮
- 高效能
- 高可用
- 可擴充性
- 支援客戶、業務、訪問、和資料的高速成長
- 難於規劃，成長無上限
- 擴充時效能不能受影響
- 無縫：只需平滑的增加資源
- 高效：維護每個使用者的低成本
- 安全性
- 便於管理
- 成本可控
- 快速交付
3.3. AWS服務的解決方案
- 敏捷、快速、靈活
- 低啟動成本、隨用隨付費
- 不再需要猜測容量
- 集中精力創新
- 擺脫無差異化的體力活
- 數分鐘就可以全球化部署
- IT整體成本降低
3.4. 雲架構設計的7大建議原則
- 設計時考慮任何系統都會失效
- 松耦合和無狀態設計（只有無狀態的應用才能更好的快速伸縮）
- 設計可擴充性和自動縮放
- 安全貫穿設計始終，體現在每層中
- 不要過多擔心約束和失敗（比如每次處理的能力還不夠多，要做到的是清晰的瞭解當前的設計思路，因為雲是無限擴充的，所以幹好一件事情後雲中可以通過複製而擴充能力）
- 多考慮平行分散式處理
- 充分使用各種不同的服務
4. 六天完成初創公司的技術架構設計4.1. 第1天，開發和私測
首台伺服器（從雲中啟動一個vm開始）
- 通過雲中的EC2執行個體來進行測試（運行諸如apache、mysql等）
- 可以部署多台來分角色，因為剛開張，先從1台vm開始
- 為伺服器綁定IP地址，（限制：每個賬戶可以有5個Elastic IP地址）
- 設定DNS網域名稱來指向Elastic IP
4.2. 第2天，推出和公測
要測試了，當初的vm不夠用，需要更大的服務
- 加大Block Storage容量（EBS）
- 使用正確的虛擬機器類型（如cpu核多、記憶體多、GPU卡、硬碟讀寫速度快等）
- 按需改變虛擬機器大小
- 瞭解方案為長期永久，具有過渡性（目標是瞭解AWS中的各種操作、限制和效能方案）
- 還沒有容錯設計
分開網站應用程式和資料層
- 更多容量
- 每層分別擴充
- 細調每層的執行個體
- 注重安全
如何選擇資料庫？SQL or NoSQL？
為什麼通常使用關係型資料庫？
- SQL非常成熟，功能豐富
- 許多現成的代碼、工具和知識
- 擴充設計思路明確發發可行
- 現實：未來將逐漸使用多種資料庫
- 有些工作負載使用NoSQL更合適
- 為每項工作選擇合適的工具
經驗分享：關係型資料庫很複雜
- 關係型資料庫要實現高可擴充性，管理運營起來往往很困難
- 管理不善的關係型資料庫，會造成：資料不匹配和IT系統宕機下線的原因
- 針對初創企業團隊小，人員少在兼職，尤為如此
AWS提供託管的關係型資料庫
MySQL、Aurora、PostgreSQL、Oracle、SQL Server
如何進一步提升效率？
4.3. 第3天，客戶上線
高可用性被擺上檯面
- 第2天的情況是：動態內容在EC2執行個體中，靜態放入S3，用CloudFront加速，用RDS管理的資料庫，並且用ElasitcCache緩衝
- 今天，繼續在第2天的基礎上，在另一個AZ（可用性區域）中建立EC2儲存動態內容，並且用ELB負載平衡來進行跳轉
- ELB是託管的負載平衡服務
- 容錯
- 健全狀態檢查
- 分布在多個可用性區域
- 彈性-自動擴充容量
- 開啟RDS的muti-AZ，這樣RDS具備高可用了
- 在另一個AZ（可用性區域）再建立一個ElasticCache的執行個體
使用者訪問的User Session問題
- 問題：狀態通常存於本地磁碟（沒有共用）
- 簡單解決：ELB Session stickiness（session綁定）
- 更好方案：DynamoDB（將session狀態儲存在NoSQL資料庫中）
- DynamoDB是託管的檔案和KEY-VALUE儲存
- 易啟動，易擴充
- 到百萬IOPS
- 讀和寫
- 一致、快速的效能
- 持久性：特別適合儲存session data
4.4. 第4天，讓我們病毒式成長
目標：使用彈性IT代替猜測計算容量
使用自動縮放能力（三劍客：CW、AS、ELB）
微服務化/SOA化
將應用分解許多成小的、功能單一的、松耦合的、無狀態的構建單元
- 只在執行個體儲存上儲存暫時的資料
- 只要超過單一http調用的資料均需持久儲存，然後儲存
- 這樣的結構雖然簡單，但你仍需
- 配置具體參數
- 將代碼部署到多個執行個體
- 管理開發測試生產多個環境（Dev，Test，Prod）
- 維護應用的多個版本
解決方案：使用Elastic Beanstalk
- 容易部署、監控和擴充的三層web、應用、資料庫結構描述
- 基礎架構由Beanstalk管理和部署
- 客戶仍然掌控
- 預配置應用程式容器
- 容易更改配置
- 支援下述平台
如果系統更複雜一些，可以使用SQS實現松耦合
- 將任務部署到佇列服務
- SQS通過隊列為後端系統提供緩衝
- 非同步處理-自己把握節奏
- 移除關鍵路徑的延遲
4.5. 第5天，增加更多功能
AWS擁有更多的服務，你可以根據需要選擇
AWS服務的關於高擴充和高擴充性的服務
| 本身可以擴充和高可用 |
與合適的架構配合實現可擴充和高可用 |
| ElasticLoadBalancing |
EC2（本身不是高可用，而是在部署在多個AZ中後，可以實現一個高可用架構） |
| CloudFront |
VPC |
| Route53 |
|
| S3 |
|
| SQS |
|
| SES |
|
| CloudSearch |
|
| Lambda |
|
| … |
|
在擴大團隊時保持對創新的關注
4.6. 第6天，繼續快速成長
資料太大了，需要擴充關係型資料庫
增強RDS執行個體
- 大的執行個體類型
- 更多儲存/更多IOPS
- 唯讀副本read replca（主master—從slave）
- 擴充到超度單一DB執行個體的計算容量
- 對RDS for MySQL、PostgreSQL 和 Aurora適用
- 【寫】=>主 master
- 複製有延遲
- 能容忍到期資料的【讀】=>唯讀副本（從）read replca（slave）
- 高一致性的【讀】=>主master
如果需要經常寫？
- 挑戰：你遲早會達到主節點寫操作或儲存的極限
- 方案1：聯合Fedration（根據資料功能分到多個資料庫上）
- 將資料庫表分成多個小的自立的資料庫
- 跨功能函數查詢很困難
- 對於單一較大的函數、表的協助不大
- 方案2：分區Sharding（將一組資料分道多台主機上）
- 將行的子集存入資料庫分區（大資料領域很常用）
- 應用程式層面更複雜
- 擴充性實際上無上限
- 運營的複雜性
另一種解決方案，NoSQL資料存放區—DynamoDB
- 犧牲關聯式資料庫的查詢和效能，以擷取
- 可以大規模無縫擴充
- 自動分區
5. 總結
無使用者數上限的架構
- 應用程式層面做了自動調整
- 資料層面做了多AZ部署
- 使用了緩衝
- 使用了讀寫分離、跨區部署的關聯式資料庫
- 用S3存動態內容
- 用DynamoDB存非結構資料
- SNS、SQS、CloudSearch解決業務需要
- …
初創公司AWS架構原則
- 保持簡潔和無狀態
- 多使用託管的自動縮放的服務
- 將EC2執行個體置於多可用性區域的自動縮放組內
- 選擇合適的資料庫類型
- 在多個層次巧用緩衝
- 使用管理工具自動化部署
【總結】初創公司用AWS搭建高擴充性架構
