????

亞信云天的理解

? 初創公司需要快、多、好、省的技術架構

o 快：針對業務需要可以快速獲得資源與服務

o 多：擁有豐富的云服務可供選擇，能不自己做就不自己做

o 好：強調擴展性和高可用，既不要在一開始被"錢"束縛住，又需要良好的用戶體驗(能用是最基本的用戶需求)

o 省：可以彈性伸縮，并按需付費是最好的節省

??無論是初創公司還是傳統企業，很多架構思路是相通的：OS、前端、后端、數據庫、框架等，根據自身需要選擇。之后要做的就是在云中找到對應的服務功能。

? 云應用架構的7大設計原則

o 設計時考慮任何系統都會失效

o 松耦合和無狀態設計(只有無狀態的應用才能更好的快速伸縮)

o 設計可擴展性和自動縮放

o 安全貫穿設計始終，體現在每層中

o 不要過多擔心約束和失敗(比如每次處理的能力還不夠多，要做到的是清晰的了解當前的設計思路，因為云是無限擴展的，所以干好一件事情后云中可以通過復制而擴展能力)

o 多考慮平行分布式處理

o 充分使用各種不同的服務

? 初創公司可以按照如下方法漸進式使用云服務

o 按業務生命周期方法：從測試開始熟悉操作，再到后續生產部署，逐步習慣云服務

o 按應用規模變化方法：從一臺EC2實例開始，再根據業務發展引入靜態數據分離，關系數據庫擴展，緩存等需求，逐步了解更多云服務

o 按業務需要方法：從基礎的計算/存儲/網絡等IaaS服務開始，在逐步根據業務將消息隊列、全文搜索、郵件發送等直接使用PaaS服務，逐步將精力放入業務創新

初創公司的業務和技術要求

? 快速驗證產品服務

? 為機會窗口而爭分奪秒(互聯網1年等于傳統7年)

? 小的技術團隊沒有歷史包袱

? 關注于提供方案解決問題

? 避免工程大而全和返工

? 規避風險準備迎接高速成長

初創公司的技術選型

一、常見技術堆棧

1. 操作系統：linux：centos，redhat，suse，ubuntu

2. 移動端：IOS、Android；HTML5

3. 網站前端：PHP/ASP/JSP、HTML/CSS

4. 前端框架：Flex，jQuery，Sencha

5. 開發工具：Eclipse，SVN，SDK/IDE

6. 技術框架：Struts，Springs，Hibernate；Velocity；Ruby on Rails

7. 開發語言：Java，PHP，Python，Ruby，Net，Node.js，GO

8. 負載均衡：軟件：Nginx，Squid；硬件：F5，Citrix Netscaler

9. 數據庫：RDB：MySQL；NoSQL：MangoDB

10. 緩存：Memcached ，Redis

11. 內容發布：CDN，DNS

12. 其他：Lucene(全文檢索工具)

二、架構的考慮? 高性能? 高可用? 可擴展性o 支持客戶、業務、訪問、和數據的高速成長o 難于規劃，成長無上限o 擴展時性能不能受影響o 無縫：只需平滑的增加資源o 高效：維護每個用戶的低成本? 安全性? 便于管理? 成本可控? 快速交付三、AWS服務的解決方案? 敏捷、快速、靈活? 低啟動成本、隨用隨付費? 不再需要猜測容量? 集中精力創新? 擺脫無差異化的體力活? 數分鐘就可以全球化部署? IT整體成本降低六天完成初創公司的技術架構設計一、第1天，開發和私測首臺服務器(從云中啟動一個vm開始)? 通過云中的EC2實例來進行測試(運行諸如apache、mysql等)? 可以部署多臺來分角色，因為剛開張，先從1臺vm開始? 為服務器綁定IP地址，(限制：每個賬戶可以有5個Elastic IP地址)? 設置DNS域名來指向Elastic IP

二、第2天，推出和公測1、要測試了，當初的vm不夠用，需要更大的服務? 加大塊存儲容量(EBS)? 使用正確的虛擬機類型(如cpu核多、內存多、GPU卡、硬盤讀寫速度快等)? 按需改變虛擬機大小? 了解方案為長期永久，具有過渡性(目標是了解AWS中的各種操作、限制和性能方案)? 還沒有容錯設計2、分開網站應用和數據層? 更多容量? 每層分別擴展? 細調每層的實例o 實例類型o 存儲? 注重安全o 使用防火墻o 數據庫至于VPC私有子網3、如何選擇數據庫？SQL or NoSQL？為什么通常使用關系型數據庫？? SQL非常成熟，功能豐富? 許多現成的代碼、工具和知識? 擴展設計思路明確發發可行o 例如：對頻繁讀取的apps，采用讀寫分離? 現實：未來將逐漸使用多種數據庫o 有些工作負載使用NoSQL更合適o 為每項工作選擇合適的工具4、經驗分享：關系型數據庫很復雜? 關系型數據庫要實現高可擴展性，管理運營起來往往很困難? 管理不善的關系型數據庫，會造成：數據不匹配和IT系統宕機下線的原因? 針對初創企業團隊小，人員少在兼職，尤為如此AWS提供托管的關系型數據庫MySQL、Aurora、PostgreSQL、Oracle、SQL Server

5、如何進一步提升效率？? 部署靜態內容—Amazon S3o 高可用性、易擴展的對象存儲o 任何格式的靜態文件(javascript，CSS，images，videos)o 用戶可以直接上傳o S3 URLs 可以從S3直接提供o 讓網站服務器集中處理動態內容? 緩存這些靜態內容—Amazon CloudFronto?全世界分布的邊緣站點o?在邊緣站點提供緩存 – 減少延遲 Reduce latency – 減輕原始服務器的負載 – 靜態和動態內容o 更少的時間緩存大量熱點數據o 優化連接 – 優化連接路徑 – 重復使用連接 – 對不能緩存的內容也有幫助(減輕負擔)

? 數據庫緩存—Amazon Elastic Cacheo 從內存讀取速度更快o 減少數據庫的工作負載o 部署簡單o 完全托管(自動替換失效節點、負責升級補丁管理)o 好的彈性擴展o 兼容性(支持memcache，redis)

三、 第3天，客戶上線1、高可用性被擺上臺面? 第2天的情況是：動態內容在EC2實例中，靜態放入S3，用CloudFront加速，用RDS托管數據庫，并且用ElasitcCache緩存? 今天，繼續在第2天的基礎上，在另一個AZ(可用區)中創建EC2保存動態內容，并且用ELB負載均衡來進行跳轉o ELB是托管的負載均衡服務o 容錯o 健康檢查o 分布在多個可用區o 彈性-自動擴展容量? 開啟RDS的muti-AZ，這樣RDS具備高可用了? 在另一個AZ(可用區)再創建一個ElasticCache的實例

2、用戶訪問的User Session問題

? 問題：狀態通常存于本地磁盤(沒有共享)

? 簡單解決：ELB Session stickiness(session綁定)

? 更好方案：DynamoDB(將session狀態保存在NoSQL數據庫中)

? ? ? ?o DynamoDB是托管的文件和KEY-VALUE存儲

? ? ? ?o 易啟動，易擴展

? ? ? ?o 到百萬IOPS

? ? ? ?o 讀和寫

? ? ? ?o 一致、快速的性能

? ? ? ?o 持久性：特別適合存儲session data

四、第4天，讓我們病毒式成長

1、目標：使用彈性IT代替猜測計算容量

2、使用自動縮放能力(三劍客：CW、AS、ELB)

3、微服務化/SOA化?

將應用分解許多成小的、功能單一的、松耦合的、無狀態的構建單元

? 只在實例存儲上保存暫時的數據

? 只要超過單一http調用的數據均需持久保存，然后存儲

? 這樣就可以做到按需進行彈性伸縮了

? 這樣的結構雖然簡單，但你仍需

? ? ? ?o 配置具體參數

? ? ? ?o 將代碼部署到多個實例

? ? ? ?o 管理開發測試生產多個環境(Dev，Test，Prod)

? ? ? ?o 維護應用的多個版本

解決方案：使用Elastic Beanstalk

? 容易部署、監控和擴展的三層web、應用、數據庫架構

? 基礎架構由Beanstalk管理和部署

? 客戶仍然掌控

? 預配置應用容器

? 容易更改配置

? 支持下述平臺

5、如果系統更復雜一些，可以使用SQS實現松耦合

? 將任務部署到隊列服務

? SQS通過隊列為后端系統提供緩沖

? 異步處理-自己把握節奏

? 移除關鍵路徑的延遲

五、第5天，增加更多功能

1、AWS擁有更多的服務，你可以根據需要選擇

2、AWS服務的關于高擴展和高擴展性的服務

本身可以擴展和高可用	與合適的架構配合實現可擴展和高可用
ElasticLoadBalancing	EC2(本身不是高可用，而是在部署在多個AZ中后，可以實現一個高可用架構)
CloudFront	VPC
Route53
S3
SQS
SES
CloudSearch
Lambda
…

3、在擴大團隊時保持對創新的關注

六、第6天，繼續快速成長

數據太大了，需要擴展關系型數據庫增強RDS實例

? 大的實例類型

? 更多存儲/更多IOPS

? 只讀副本read replca(主master—從slave)

o 擴展到超度單一DB實例的計算容量

o 對RDS for MySQL、PostgreSQL 和 Aurora適用

o 【寫】=>主 master

o 復制有延遲

o 能容忍過期數據的【讀】=>只讀副本(從)read replca(slave)

o 高一致性的【讀】=>主master

如果需要經常寫？

? 挑戰：你遲早會達到主節點寫操作或存儲的極限

? 方案1：聯合Fedration(根據數據功能分到多個數據庫上)

o 將數據庫表分成多個小的自立的數據庫

o 跨功能函數查詢很困難

o 對于單一較大的函數、表的幫助不大

? 方案2：分片Sharding(將一組數據分道多臺主機上)

o 將行的子集存入數據庫分片(大數據領域很常用)

o 應用層面更復雜

o 擴展性實際上無上限

o 運營的復雜性

另一種解決方案，NoSQL數據存儲—DynamoDB

? 犧牲關系數據庫的查詢和性能，以獲取

? ? ? o 更靈活的數據模型

? ? ? o 水平伸縮可以預測的性能

? 可以大規模無縫擴展

? ? ? o 分布式系統可以對讀寫均實現擴展

? ? ? o 切片 + 復制

? 自動分區

? ? ? o 數據大小增加

? ? ? o 增加預設容量

總結

1、無用戶數上限的架構

? 應用層面做了自動伸縮

? 數據層面做了多AZ部署

? 使用了緩存

? 使用了讀寫分離、跨區部署的關系數據庫

? 用S3存動態內容

? 用DynamoDB存非結構數據

? SNS、SQS、CloudSearch解決業務需要

? …

2、初創公司AWS架構原則

? 保持簡潔和無狀態

? 多使用托管的自動縮放的服務

? 將EC2實例置于多可用區的自動縮放組內

? 選擇合適的數據庫類型

? 在多個層次巧用緩存

? 使用管理工具自動化部署

?

總結

以上是生活随笔為你收集整理的aws s3仅允许cloudfront访问_初创公司如何用AWS搭建高扩展性架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。