1.設計app架構：

1.梳理app業務流程
2.整理業務流程可能遇到的問題
3.根據問題，探討可執行的解決方案
4.把3中所有技術進行有機融合，就是app后臺的初步架構

api編寫：
1.api的作用（功能）
2.api需要輸入的參數
3.api返回的數據

2.服務器選擇

1.傳統的IDC
在傳統的IDC，要加cpu或內存，流程如下:
　　1.和客戶經理商商談所需硬件的價格
　　2.匯款過去，等IDC的財務確認
　　3.確認后，等待IDC安排工作人員升級硬件
　　這個流程走一次，最少也要1至2天。延遲了1至2天升級硬件，怎么保證可以快速應付爆發的業務

2.云服務器
升級硬件:
1.在用戶后臺選擇需要的硬件配置
　　2.通過網絡支付
　　3.重啟服務器，升級就完成了。如果只是升級帶寬，甚至不用重啟。
　　整個過程合起來不用5分鐘，簡單，快捷，方便。
　　而且，現在的云服務器提供商，出了服務器外，還提供下面的服務：
　　負載均衡
　　云數據庫
　　云內存存儲
　　這些服務在app上線初期，在一臺服務器上自己搭建就行了，但隨著app的發展，這些服務都需要部署在不同的服務器。
　　規模的增大，也要面對高可用，高并發，監控報警等問題。這些問題如果都要后端人員處理，那要瘋了，后端就那么一兩個人，既要保證平時的開發任務，又要做復雜的運維管理。后端人員也不是全能，一般后端人員是專注于開發，運維稍遜一籌。
　　這時，就能體會到云服務的優點，由云服務器的提供商來負責運維。高可用，高并發，監控報警這些都靠云服務器的提供商來保障，就能大大減輕運維方面的壓力和人員的開支。

3.選擇
在網絡上經常被問到，需要選擇什么樣的服務器配置，這個問題，沒法回答。這需要在綜合考慮用戶量，業務邏輯綜合考慮的。
給個建議，最初硬件配置可以差點，隨時監控主機，發現負載高了，才升級硬件配置也不遲

3.app后臺

1.app后臺要慎重考慮網絡傳輸流量，主要做api設計，圖片處理上
2.移動手機弱網絡環境
3.手機電量有限

4.app流程

1.項目業務邏輯
2.產品原型
3.UI效果圖
4.研發階段

* api設計
* api提供測試數據供前端開發
* 開發頁面及初級架構設計
* 后端實現api接口功能

5.測試反饋

* bug修改人員
* bug描述說明與重現步驟
* bug提交版本與bug提交人

6.市場推廣與市場運營

* 潛在用戶如何發現應用市場中的app？
* 怎么讓用戶了解app?
* 怎么讓用戶下載app?
* 怎么讓用戶使用app?怎樣增加用戶粘性?

5.項目開發管理

1.日常開發

* 開發計劃
* 開發規范
* 保證開發的進度和效率

2.每日例會

* 昨天做了哪些事情，還有哪些沒做，需要多長時間去完成
* 今天要做什么
* 有什么工作需要哪些人配合

3.測試和修復bug

* 可以交叉測試
* 問題描述和重現步驟
* 解決問題人員和提出問題人員

4.評審
使用評審整個app的功能及體驗

6.app后臺

1.api接口
從業務邏輯中提煉api接口

* 業務邏輯思維導圖
* 功能-業務邏輯思維導圖
* 基本功能模塊關系

* 功能模塊接口UML(設計出api)
* 在設計稿標記api
* 編寫api文檔

2.業務邏輯思維導圖

* 用思維導圖把結構關系列出來，包含里面的功能
* 把相同的元素整理出來，如相同的推送、評論、圖片上傳，然后用相同的顏色標起來

業務思維導圖.png

功能-業務邏輯導圖.png

功能模塊關系圖.png

功能模塊UML.png

3.api設計要點

* 根據對象設計api，而不是根據頁面設計api（頁面修改會影響到api更改，維護較難）
* api命名(望名而知api)
* api安全
* api返回數據(注意空值的處理，不然易造成app閃退)

app后臺角度，api返回的數據中正確值和空值的類型必須一樣，禁止返回null值;
app客戶端，當api返回數據缺少某個數據時，app客戶端自動補上這個數據并賦值；
數據庫設計，所有字段都有默認值，不允許Null值；
產品中常用的null值需求是用Null表示數據未填寫，如用“1”表示男性，“0”表示女性，Null表示用戶未填寫性別；

4.圖片處理

* app客戶端緩存圖片，圖片不存在，才通過api獲取圖片;
* 當app客戶端需要某種尺寸的圖片，由app客戶端通知服務器所需要的尺寸，由服務器動態生成并緩存；

app后臺數據庫只保存原圖，需要什么尺寸，動態生成；

5.返回提示信息

* 提示用戶信息
* 提示程序員信息，參數問題，格式問題

7.數據庫選擇

1.MySQL、Redis、MongoDB讀寫數據區別
Redis是存放在服務器端內存中，內存用滿之后需要擴容，就只能使用Redis的分布式方案，為防止丟失，可調整Redis配置文件，按一定策略把數據持久化傳到硬盤中。

MongoDB同時使用了硬盤和內存，其使用了操作系統提供的MMAP（內存文件映射）機制進行數據文件的讀寫，MMAP可以把文件直接映射到進程的內存空間中，這樣文件就會在內存中有對應的地址，這時對文件的讀寫是可以操作內存進行的，而不需要傳統的如fread、fwrite文件操作方式。

MySQL的數據放在硬盤中，MySQL的緩存是查詢的結果，而不是緩存數據。

2.MySQL、Redis、MongoDB查找數據的區別
Redis的數據基于“鍵值對”存儲，查找數據，直奔主題，讀寫速度快。

MongoDB和MySQL，每組數據都有一個id（或者可以為每組數據建立索引），查找數據分兩種，知道id或索引，不知道id或索引，前者效率高，后者效率低。

3.MySQL、Redis、MongoDB查找數據的區別
Redis數據只存放在服務器端內存中，由于內存價格高，所以內存存儲數據成本高，app后臺開發中，讀寫頻率高的數據一般放在Redis中（當然這部分數據也可放在MySQL或MongoDSB中，Redis中國的數據是以緩存的形式存在的，數據更新時，兩部分數據都要更新以保持數據統一性）。

MongoDB使用場景：
網站數據：MongoDB非常適合實時的插入、更新與查詢，并具備網站實時數據存儲所需要的復制及高度伸縮性；
大尺寸、低價值的數據；
高伸縮性的場景；
存儲地理坐標的數據；

MongoDB不適用場景：
高度事物性的系統：如銀行或會計系統，涉及金錢的操作不支持；
傳統的商業智能應用；
需要SQL的問題：雖然MongoDB支持類似于SQL的查詢，但它的查詢比起MySQL來有一定的差距；

MySQL適用場景：
事物性的系統：如轉賬；
需要復雜的SQL問題；

8.消息隊列

消息隊列把大量的并發請求變成串行的請求，來減輕服務器的壓力。
app后臺中，發送郵件、發送短信、推送消息等任務都適合在消息隊列中完成；

1.消息隊列的流程

* 隊列服務器
* 隊列生產者
* 隊列消費者

9.使用分布式服務實現業務復用

遠層服務：
把重復實現的模塊獨立部署為遠程服務，新增的業務調用遠程服務所提供的功能實現相關的業務，不依賴于里面的具體實現代碼。當遠程業務發生變化時，只要接口傳人的參數和返回值不變，就不會影響到調用遠程服務的業務。

1.遠層服務的實現

* REST
* RPC
* 開源的RPC庫

2.常見的搜索軟件

* Lucene
* Sold
* ElasticSearch
* Sphinx
* CoreSeek

3.定時任務

10.后臺核心技術

1.用戶驗證方案

* api請求必須使用HTTPS協議

傳統Web網站使用Cookie+Session保持用戶登錄狀態；

2.app通信安全

* URL簽名（改進：在傳遞參數中增加時間戳）
* AES對稱加密

AES加密（data，secretKey）

app后臺
* app后臺用時間戳生成HTTP請求頭Token-Param
* 取請求頭Token-Param的22位長度作為secretKey
* 用AES算法把個人信息用密鑰secretKey加密，在進行base64編碼，用HTTPS返回給app

客戶端
* 取HTTPS協議中HTTP請求頭Token-Param的值的22位作為secretKey
* 把HTTPbody的數據先進行base64算法解碼，用AES算法把解碼后的數據用密鑰secretKey解密，獲取個人用戶信息

3.更進一步的通信安全

* 使用自定義的通信協議傳輸敏感數據
* 使用RSA加強通信的安全性
* 涉及敏感信息（如支付密碼），每次都需用戶輸入支付密碼確認，支付密碼永遠不在app端保存
* 使用自主開發的輸入控件輸入敏感信息

4.短信服務

* 發送短信只能依靠第三方短信平臺
* 短信的到達率和延時app后臺無法控制

短信平臺選擇（價格，短信的到達率和延時），先試用，在選用！
為建立可靠的短信服務，app后臺必須要接入最少兩個短信平臺，當前短信平臺不可靠時，切換到另一個平臺；

5.表情
Openfire中發送表情引起連接斷開的問題
xmpp斷開連接，是由Openfire中代碼引起的，app后臺加個codePoint判斷即可；

6.高效更新數據
推拉結合和數據增量更新是實現高效獲取數據的關鍵；

輪詢：
典型的拉模式，每隔一段時間，app向app后臺發送請求數據，耗網絡流量，服務器壓力大；

推模式：
當app后臺有數據更新，通過推送系統通知app，當app收到這個數據更新的通知后在調用api獲取相應的數據。

推模式.png

7.數據增量更新策略
使用app本地存儲，需考慮數據增量大更新方案；
當app從服務器獲取一次數據時，記錄獲取最新數據的update_time，當再次獲取數據就只需要獲取update_time到訪問服務器這刻為止所更新的數據。

8.獲取APK和IPA文件中的資源

11.文件系統

盡量使用成熟可靠的云服務和開源軟件，自身只專注于業務邏輯；

架設文件系統涉及文件的分布式存儲、圖片水印、圖片縮放、及CDN等方面，小團隊可用第三方云存儲平臺；

1.分布式文件存儲系統

* 擴容的時候，只需添加機器就能達到擴容效果，不需重啟整個文件系統，甚至遷移文件
* 保證文件系統高可用、文件冗余備份，避免以某臺機器宕機而造成文件服務停止

2.推薦使用FastDFS（開源的輕量級的分布式文件系統）
FastDFS對文件管理功能包過：文件存儲、文件同步、文件訪問等，解決了大容量存儲和負載均衡的問題。
FastDFS的基本原理可類比生活中的倉庫，有兩大角色，跟蹤器和存儲節點，跟蹤器就是倉庫管理員，負責調度工作，在訪問上起負載均衡的作用，存儲節點就是貨柜，工人就是向FastDFS存儲文件的客戶端；

3.圖片水印、縮減和裁剪
推薦使用GraphicsMagick作為圖片處理軟件；支持多語言、多平臺；

4.CDN
解決網絡擁擠情況；
傳統CDN服務商、阿里云、UCloud等提供CDN服務；
另外很多CDN服務商提供了圖片水印、縮減、裁剪的功能，開發者可以直接使用；

5.ELK日志分析平臺（分布式的日志收集和分析系統）

6.Docker構建一致的開發環境
Docker是一個用于統一開發和部署的輕量級容器，讓開發者打包其應用及依賴包到另一個可移植的容器，發布該容器到其它機器，就能很容易的實現應用的部署。

12.app后臺應用最廣泛的系統

1.基本系統優化
app后臺的Linux系統如果是采用默認安裝或機房工作人員幫忙安裝，運維人員需要對其進行優化，以獲得更高的性能和安全性。

開啟自動服務優化；

Linux的交換區：交換區是硬盤上的一塊空間，在內存不足的情況下，操作系統先把內存中暫時不用的數據存儲到硬盤的交換區，騰出內存來讓別的程序運行。

阿里云服務器上的Linux系統是默認沒有設置交換區（Swap），由于開啟Swap分區會導致硬盤IO性能下降，因此阿里云服務器初始沒有設置Swap，如需要開啟Swap，可使用相應的命令開啟。

2.故障案例分析

* 進程管理軟件引起的最大連接數設置（修改限制）
* 占滿磁盤空間引起網絡無法登陸問題（可能是由bug日志過多占空間，修復bug后要注意清楚）

13.Nginx-app后臺HTTP服務的利器

Nginx與Apache類似，其是一個高性能的HTTP和反向代理服務器，也是一個imop／pop3/smtp代理服務器。

Nginx高性能主要是使用了epoll和kqueue網絡I／O模型，而Apache使用的是傳統的select模型。

處理大量請求時，epoll模型遠遠大于select模型；
理解：select 模型處理（如客人進店點菜，服務員全程跟著）
epoll模型處理（如客人進店點菜，在需要的時候服務員才跟著）

http配置；

https配置：

生成證書：
* 繳費，到證書服務商申請
* 用戶自己給自己頒發證書，即手動生成

location配置:主要針對靜態網頁；

sever虛擬機配置；

負載均衡配置：保證服務的高可用；

負載均衡.png

下載app配置：在瀏覽器下載；

性能統計：可開啟Nginx的統計模塊；

14.MySQL-app后臺最常用的數據庫

1.MySQL基本架構

• 服務層：大多數基于網絡的客戶端／服務端工具都有這一層，這一層主要處理連接和安全驗證；
• 核心層：這層處理MySQL的核心業務；
  查詢、分析、緩存和內置的函數
  內建的視圖，存儲過程，觸發器
• 存儲引擎層：存儲引擎負責數據的存儲和提取。

核心層通過存儲引擎的API與存儲引擎通信，這樣就遮蔽了不同存儲引擎的差異，使得這些差異對上層查詢是透明的。
存儲引擎之間不會相互通信，只是簡單的響應上層查詢。

建議選擇MySQL社區版，足夠業務需求；

2.軟件優化

1.正確使用MyISAM和InnoDB存儲引擎
MyISAM和InnoDB存儲引擎是MySQL最常用的存儲引擎；

• MyISAM基于ISAM（索引順序訪問方法），支持全文索引，但并非是事物安全，不支持外建，使用表級鎖。每個MyISAM存3個文件：FRM文件存放表結構，MYD文件存放數據，MYI存放索引。

• InnoDB是事務型存儲引擎，其支持行鎖，InnoDB的行鎖也不是絕對的，如果他在執行一個更新的語句是沒法確定更新的范圍，也會鎖表。InnoDB支持回滾、崩潰恢復、ACID事物控制，InnoDB存儲他的表和索引在一張表空間，表空間可包含多個文件。
  支持外建，是事務安全型的；

2.正確使用索引

* 給合適的列建索引
* 索引列的值盡不相同
* 使用短索引
* 利用最左前綴
* 使用like查詢時索引會失效，盡量少使用like查詢
* 不能濫用索引

3.避免使用select*

• “select*”從數據庫中返回的數據更多，降低了查詢速度；
• 過多的返回結果會增大服務器反給app端的數據的傳輸，網絡不好的情況下，過大的傳輸會造成請求失敗；

4.建議數據庫上所有字段都設置為NOTNULL，必須有默認值；

3.硬件優化

1.增加物理內存
2.增加應用緩存
3.用固態硬盤代替機械硬盤
4.SSD硬盤+SATA硬盤混合存儲方案

4.架構優化

1.分表
項目用戶增長，數據龐大，就要分表：將大表拆分為多個子表，在更新或查詢數據的時候，壓力會分散到不同的表上。由于分表之后，每張表的數據變小，查詢或更新會有很好的提升；

• 水平拆分：把一張表的數據分別保存在不同的表中；
• 垂直拆分：把一張表的字段保存在不同的表中；

2.數據庫優化
使用數據庫讀寫分離策略；
讀寫分離是把對數據庫的讀和寫操作分開對應于主／從數據庫服務器；

讀寫分離架構.png

3.分庫
數據規模變大，當讀寫分離也不能滿足系統性能要求的時候要考慮分庫，分庫即把不同的數據表部署在數據庫集群上；

MyCat部署.png

4.SQL慢查詢分析
SQL慢查詢是指超過一定時間的SQL查詢語句，把這些語句記錄到查詢日志，以便分析其原因，以進行優化。

5.云數據庫

* 配置高性能的SSD硬盤
* 備份機制
* 完善的監控體系
* 彈性擴展

15.Redis-app后臺高性能的緩存系統

1.Redis

業務場景需求：

* 少量數據被經常讀寫，同時對讀寫速度要求非常高；
* 能提供豐富的數據結構
* 提供數據落地的功能

Redis就是滿足上面需求的開源Key-Value內存存儲系統；
特點：

* 全部的數據操作在內存，保證了高速的讀寫速度
* 提供豐富的數據類型，string、hash、list、set、sorted set、bitmap、hyperloglog
* 提供了AOF和RDB兩種數據的持久化方式，保證了Redis重啟后數據不丟失
* Redis所有操作都是原子性，同時Redis還支持對幾個操作合并后的原子性操作，也即支持事務

2.Redis常用數據結構及應用場景

2.1string-存儲簡單的數據

特點：
* 可接受任何格式的二進制數據
* 是基本的Key-Value結構

場景：
* 可存儲大量數據，app后臺該類型經常被用來緩存數據
* 頁面：訪問頻率高，數據不經常變動（可能幾天）

緩存不常變數據.png

2.2hash-存儲對象的數據

特點：
* hash的key是唯一值，value部分是個hashmap結構

場景：
* 根據用戶id獲取用戶信息

2.3list-模擬隊列操作

特點：
* list是按照插入順序排序的字符串鏈表，可在頭部和尾部插入新元素
* 鏈表中間插入效率低，首位插入效率高

場景：
* Redis被用來作為消息隊列

如短信發送：

短信發送.png

2.4set-無序且不重復的元素集合

特點：
* set類型可以看作是沒有排序、不重復的元素集合，可以在類型上添加、刪除或判斷某一元素存在等操作

場景：
* 如社交中的共同好友

2.5sorted set - 有序且不重復的元素集合

特點：
* 和set 類似，不容許成員重復

場景：
* 各種類型的排行榜（如人氣排行）

3.內存優化

3.1監控內存使用情況（命令redis-cli info）

3.2優化存儲結構

* hash存儲，當hashmap成員達到不同數時，采用不同的形式存儲數據（<512用ziplist存儲，>512用hashmap存儲;）,hashmap成員長度（<64用ziplist存儲，>64用hashmap存儲）
* set使用了intest的結構來節省內存

3.3限制使用的最大內存

• 設置maxmemory的參數來限制Redis使用的物理內存
• 當Redis使用的內存達到了限制值，任何write操作會觸發“數據清除策略”，配置文件“maxmemory-policy”來采用特定的“數據清除策略”

3.4設置過期時間
可設置Key超時時間（命令EXPIRE key seconds）
超過超時時間后，刪除不用的Key及數據，達到內存優化；

刪除：
* 惰性刪除(發現key過期就刪除)
* 定期刪除（定期檢查，有過期的刪除）

4.集群

4.1客戶端分片
4.2Twemproxy

Twemproxy.png

優劣.png

4.3Codis

Codis.png

4.4Redios3.0集群采用了p2p模式，完全去中心化

4.5云服務器上的集群服務

* 動態擴容
* 數據多備（數據保存在一主一備兩臺機器中）
* 自動容災

4.6持久化
Redis是一個支持持久化操作的內存數據庫，通過持久化機制把內存中的數據保存在硬盤文件。當Redis重啟后通過把硬盤文件重新加載到內存，就能達到恢復數據目的。

* RDB(按照一定的時間周期策略把內存的數據以快照的形式寫入到硬盤的二進制文件)
* AOF（通過write函數追加到持久文件中）

4.7故障排除
查看Redis錯誤日志；

16.MongoDB-app后臺新興的數據庫

1.MongoDB

* 一種非關系型數據庫
* 支持的數據結構非常松散，數據采用bson格式，可存儲比較復雜的數據類型
* 讀寫性能高
* 水平擴展機制

高性能（MMAP和Journal日志）
* MMAP（內存文件映射）
* Journal日志（所有數據更新操作都會記錄并保存在該日志中）

* MongoDB把關系模型轉變為文檔模型
* 可進行數組操作、文檔操作

2.高可集用群

2.1主從
MongoDB采用雙機主從備份，主節點的數據會自動同步到從節點，當主節點宕機后，切換到從節點繼續提供服務。

主從.png

2.2副本集
副本集使用多臺機器做同一份數據的同步和異步，從而使多臺服務器擁有同一份數據的多個副本。一臺服務器作為主節點提供寫入服務，多臺服務器作為副本節點提供讀取服務，實現讀寫分離和負載均衡。當主節點宕機后，可把副本節點提為主節點或將其他節點改為主節點，繼續服務。

副本集.png

2.3分片
集群中大量的數據讀寫請求分散到多個集群處理，在MySQL中稱為數據庫分片；

2.4.LBS- 地理位置查詢

2.5MongoDB3.0

* 靈活的存儲架構（引入插件式存儲引擎api）
* 性能提升7-10倍
* 存儲空間最多減少80%（新增WiredTiger存儲引擎，支持集合數據壓縮）
* 運維成本降低95%

17.app后臺架構剖析

1.聊天app后臺架構

1.1移動互聯網的網絡特性

* 弱網絡性
心跳機制防止TCP half-open（客戶端斷開連接，服務器以為仍和app保持連接）
* 對流量敏感

1.2協議

* XMPP
* MQTT
* ActivitySync

基于隊列的消息協議

* 傳統的IM協議一般是基于隊列的消息發送和反饋機制

基于隊列消息協議.png

基于版本號的消息協議

基于版本號的協議.png

1.3文件發送

文件發送.png

1.4聊天架構

聊天架構.png

連接層:
* 與app保持連接
* 把消息通過隊列轉發到邏輯層處理

業務層(處理業務邏輯):
* 驗證模塊（驗證用戶身份信息）
* 路由模塊（路由獲取用戶所在服務器，如實現群聊功能） 
* 統計模塊（統計各種信息，如連接數、每秒發送消息數、每個端端連接數）
* 數據存儲模塊（存儲消息、統計信息、用戶身份信息等）

持久層：
* 提供數據存儲服務

流程：

聊天后臺流程.png

2.社交app后臺架構

社交的核心功能是Feed；

2.1基本表結構
常見的Feed架構就是把數據存儲在MySQL中，熱點數據（一般說最近3天數據）存儲在緩存（常見的緩存有Redis和Memcached，微博用的Memcached），務必讓絕大數請求通過緩存直接返回，只有少量的請求穿透緩存落到數據庫。

2.2推拉模式

推模式：
* 推送給粉絲（同時推送很多人，延遲嚴重，浪費存儲空間）
* 一個SQL可完成（顯示Feed）
* 變更成本高 （如刪除某一條內容）

拉模式：
* 采用了時間換空間的策略
* 不推送
* 需要大量的聚合運算（顯示Feed）
* 沒有變更成本

微博中公開的微博采用了拉模式，私密性微博采用了推模式；

2.3數據庫的架構演進
單機部署 ——> 讀寫分離，從一主一從到一主多從——>分表分庫

2.4社交app后臺數據庫在業務層實現分表分庫的方案

數據庫自增id
* 生成id算法

分表分庫策略
* 按hash拆分（適用于數據分表分庫前中期）
* 按時間拆分
* 綜合使用拆分

hash拆分.png

時間拆分.png

2.5緩存架構的演進
分布式緩存

分布式緩存.png

主從緩存結構

主從緩存.png

2.6防止緩存實效的措施

* 定期把主緩存的數據同步到從緩存
* 應用層控制請求有一定的概率落在從緩存，讓從緩存承擔部分請求，使從緩存的數據不過冷

3.LBS-app后臺架構

3.1地理坐標
獲取

* GPS：精度高，初始化搜索衛星的速度慢，耗電
* 基站：速度快、精度低，不同運營商的基站定位差別大
* AGPS：GPS+基站的結合
* WiFi定位：通過服務商收集的Wi-Fi數據定位，但WiFi的地理信息更新慢

app端建議使用地圖SDK，后臺注意坐標偏移問題；

處理

* MySQL的空間數據庫(把地理坐標的數據當成一種獨立的數據類型)
* geohash（geohash編碼就是把地理坐標變換成一個值（字符串））
* MongoDB封裝了大量地理位置操作 

3.2基于MongoDB的LBS后臺架構演進
副本集架構——>分片架構

副本集架構

* 保證高可用

MongoDB副本集架構.png

分片架構

* 每個分片都是副本集架構

4.推送服務器的后臺架構

4.1Android推送
由于android系統沒有限制，當app進入后臺也能運行服務，所以android可以基于長連接作推送；

app連接推送服務器流程：

后臺推送消息到app流程：

后臺推送消息到app.png

app獲取離線消息流程：

app獲取離線消息.png

4.2iOS推送
APNS原理：

APNS原理.png

18.app后臺架構的演進

app后臺架構核心：

* 高可用
* 高性能
* 安全性
* 可擴展
* 可伸縮

app發送請求后臺運行：

app請求后臺運行.png

1.高性能

app層：

app層.png

網絡傳輸層：

網絡傳輸層.png

應用服務層：

文件服務層.png

文件服務層：

應用服務層.png

緩存層：

緩存層.png

數據庫層：

數據庫層.png

2.高可用

應用服務器高可用原理.png

宕機后的負載均衡：

宕機.png

高可用備份：

備份.png

數據服務器宕機：

數據服務器宕機.png

3.開發服務器、工具

開發.png

開發2.png

4.架構演進

4.1單機部署
app后臺極簡化架構：

app后臺極簡化架構.png

* 加入ULB(UCloud的負載均衡ULB是免費的)
* 一開始使用Redis（既能當緩存，又能當隊列服務，并發性能高，適用于初期項目）
* 架構中不包含文件服務（運維成本高）

4.2分布式部署

分布式部署.png

4.3架構拆分

架構拆分.png

業務平穩期：

業務平穩期.png