《App後臺開發運維與架構實踐》第10章 App後臺架構的演進
10.1 架構的核心要素
10.1.1 高效能
效能問題是驅動架構發展的最直接力量，因為效能問題是最容易被使用者感知的，沒有一個使用者會忍受一個響應速度極慢的App。從App發出請求到App後臺返回結果，這一過程如下所示。
每層都有相應的措施以提高系統的效能。
- App層
圖片、音訊、視訊等靜態資源，第一次下載後可以快取到手機的SD卡；對於通知等內容，使用增量更新的技術，減少伺服器的負擔和使用的流量；根據App當前的網路環境下載不同的圖片資料。
- 網路傳輸層
使用CDN技術，讓使用者在最近的機房下載靜態資源，減少網路傳輸的時間；在應用伺服器部署反向代理伺服器、快取熱檔案，使請求在到達應用伺服器前返回靜態資源，減輕伺服器的負擔，減少請求的時間。
- 應用服務層
在程式碼層面，改進演算法，使用多執行緒和優化程式記憶體等優化方法；在語言層面，考慮使用Golang、Erlang等更適用於高併發場景的語言；通過非同步操作把使用者的請求傳送到訊息佇列等待任務程式處理，減少請求的等待時間；將多臺應用伺服器組成一個叢集，使用負載均衡軟體把請求按一定的規則分發到每個應用伺服器上，提高系統整體的處理能力；使用分散式快取軟體快取使用者的熱點請求資料，加快伺服器的響應時間，減輕資料庫的負擔。
- 檔案服務層
使用MogileFS、TFS、FastDFS等軟體架設一個分散式檔案系統，提供整體的檔案處理能力；使用七牛、又拍、UCloud的物件儲存等第三方檔案雲端儲存服務，把檔案存放在雲伺服器上，從而在架構上去掉檔案伺服器。
- 快取層
使用Redis、Memcached或者雲伺服器的雲快取服務。
- 資料庫層
資料庫前加一層或多層快取，擋住大部分的熱點請求，使大部分的請求不穿透到資料庫，減輕資料庫的壓力；對於MySQL資料庫，可以使用讀寫分離、分表、分庫等成熟的技術；對於NoSQL型別的產品，例如MongoDB，可以使用其原生的副本集、分片等機制，提升其效能；使用Facebook開源的FlashCache技術，把傳統硬碟上的熱資料快取在SSD硬碟上，冷門資料儲存在傳統硬碟上。
10.1.2 高可用
高可用就是要保證為App提供7X24小時服務的App後臺，伺服器不能隨便宕機，或者在一個伺服器叢集中，部分伺服器宕機了也可以保證整個服務不受影響。保證App後臺高可用的主要方法是冗餘
對於應用伺服器而言，多臺應用伺服器組成一個叢集，由負載均衡器把請求按照一定的策略分發到叢集中的每個應用伺服器，當負載均衡器檢測到某臺應用伺服器宕機，就把該臺應用伺服器從叢集中移除。保證負載均衡策略有效的核心是應用層必須是無狀態的。所謂無狀態，就是指任意一臺應用伺服器上不會儲存使用者的狀態資訊（例如，在某臺應用伺服器上儲存使用者已經登入的憑據）。使用者的狀態資訊可以儲存在快取或資料庫，供所有的應用伺服器共同呼叫。
對於資料伺服器（包括資料庫、快取、檔案）而言，保證高可用需要對儲存的資料進行實時備份，當資料伺服器宕機後，立刻把資料的讀寫請求切換到備份伺服器上，同時儘快修復宕機的伺服器，以保障冗餘。
10.1.3 可伸縮
可伸縮是指通過往叢集中新增機器，應付不斷增大的訪問壓力和資料儲存需求。
應用伺服器的可伸縮性是指當訪問量增大後，往叢集中新增伺服器。資料儲存的可伸縮性分為檔案資料的可伸縮性（比如分散式檔案儲存軟體FastDFS）、快取資料的可伸縮性（通過改進的路由演算法減少新增伺服器造成的路由失效情況）、資料庫的可伸縮性（關係型資料庫的分散式處理系統MyCat實現分庫，NoSQL資料庫MongoDB使用分片策略就能實現可伸縮性）。
10.1.4 可擴充套件
可擴充套件性的核心是減少模組間的耦合度，每個模組都儘量少依賴其他模組，這樣其中一個模組的變化對其他模組的影響減少。實現可擴充套件的方式如下：
- 訊息佇列：降低模組間的耦合程度。
- 分散式服務：把業務中可複用的模組抽離成一個獨立的服務，對其他模組提供可複用的服務，通過分散式服務框架供其他模組呼叫。
- 開放式API：把自身的業務封裝成開放式API供其他開發者呼叫。
10.1.5 安全性
安全性就是保證使用者的核心資料不被非法人員盜竊。
10.2 架構選型的要點
10.2.1 用成熟穩定的開源軟體
10.2.2 儘可能使用雲服務
| 功能 | 可使用的雲服務 |
| 專案管理工具 | Teambition、Tower |
| 程式碼管理工具 | GitHub、碼雲 |
| 負載均衡 | 阿里雲負載均衡服務SLB、UCloud負載均衡服務ULB |
| 郵件服務 | SendCloud、MailGun |
| 訊息佇列 | 阿里雲訊息通知服務MNS |
| 檔案系統、圖片處理 | 七牛、又拍雲、阿里雲物件儲存OSS、UCloud物件儲存UFile |
| Android推送、iOS推送 | 極光、個推、百度推送 |
| 聊天 | 融雲、環信 |
| 監控 | 監控寶、雲伺服器自帶的監控服務 |
| 快取 | 阿里雲開放快取服務OCS、UCloud雲記憶體儲存UMem |
| 關係型資料庫 | 阿里云云資料庫RDS、UCloud雲資料庫UDB |
| NoSQL資料庫 | 阿里雲開放結構化資料服務OTS、UCloud雲記憶體儲存UMem |
| 搜尋 | 阿里雲開放搜尋服務OpenSearch |
| 分散式訪問服務 | 阿里雲企業級分散式應用服務EDAS |
| 防火牆 | 阿里云云盾、UCloud防火牆 |
| 簡訊傳送 | 阿里雲簡訊服務、bmob、shareSDK、Luosimao |
| 社交登入分享 | shareSDK |
10.3 架構的演進
App後臺的架構是由業務規模驅動而演進的，App後臺是為業務服務的，App後臺的價值在於能為業務提供其所需要的功能，不應過度設計。
從一個專案的角度，當App訪問量不大的時候去追逐高效能App後臺的架構是捨本逐末，這時候的主要工作是快速搭建App後臺，讓App儘快上線給使用者提供服務，驗證商業模式的正確性，同時快速迭代產品。
當App訪問量不斷飛漲，這時要在保證快速迭代的前提下，同時也兼顧高效能和高可用。
當App訪問量增長到一定階段後，增長曲線會有所放緩，但業務變得更加複雜，對高效能和高可用的要求也更高，效能問題、模組間的耦合、程式碼的複雜性會更加突出和明顯，這時要使用業務拆分、分散式服務呼叫，甚至是技