1.架構，架構與業務緊密相關，是有業務驅動的。
2.APP后台演進原則。
App后台的架構是由業務規模驅動而演進的，App后台是為業務服務的，App后台的價值在於能為業務提供其所需要的功能，不應過度設計。
從項目的角度，當App訪問量不大時，應該快速搭建App后台，讓App盡快上線給用戶提供服務，驗證商業模式的正確性，同時快速迭代產品。
當App訪問量不斷上升，這時要在保證快速迭代的前提下，同時兼顧高性能和高可用。
當App訪問量達到一定階段后，增長曲線就會放緩，但業務變得更加復雜，對高性能和高可用的要求也更高，性能問題、模塊間的耦合、代碼的復雜性會更加突出和明顯，這時要使用業務拆分、分布式服務調用，甚至是技術轉型等問題。
1.項目啟動時，單機部署。
app后台一個極簡化的架構：
一開始就使用Redis的好處：
既能用作緩存，又能充當隊列服務，而且並發性能高，能在長時間內應對業務壓力，非常適合初期的項目。
這里使用Redis驗證用戶信息，充當消息隊列。
而文件服務初期可以選擇 文件雲存儲服務，或者自己搭建一個資源服務器。
2.項目一定規模時，分布式部署：
看一個百萬到千萬級的架構：
這里新增了專門用於連接內部服務器的SSH服務的外網通道，保證SSH操作隨時可用，同時加入了服務器集群，提供負載能力。
隨着業務的發展，某些數據表的規模會以幾何級增長，當數據達到一定規模時，查詢讀取性能就下降的厲害，數據庫主從的架構不能應對業務上的讀寫壓力，這時架構上要考慮分表（水平拆分／垂直拆分）。
當業務繼續不斷發展，數據庫分表后的讀寫性能也可能沒法滿足業務上的需求，這時只能采用進一步的拆分策略——分庫。用 Cobar 或者 MyCat 等關系型數據等分布式處理系統后，分庫后的架構如下：
3.可供選擇的成熟穩定的開源軟件
| 功能 | 可供選擇的開源軟件 |
|---|---|
| 項目管理軟件 | Mantis、BugFree |
| 代碼管理軟件 | SVN、Git |
| 編程語言 | Java、PHP、Python等 |
| 服務器系統 | CentOS、Ubuntu |
| HTTP／HTTPS服務器 | Nginx、Tomcat、Apache |
| 負載均衡 | Nginx、LVS、HAProxy |
| 郵件服務 | Postfix、Sendmail |
| 消息隊列 | RabbitMQ、ZeroMQ、Redis |
| 文件系統 | Fastdfs、mogileFS、TFS |
| Android推送 | Androidpn、gopush |
| IOS推送 | Javapns、Pyapns |
| 地理位置查詢LBS | MongoDB |
| 聊天 | Openfire、ejobberd |
| 監控 | ngiOS、zabbix |
| 緩存 | Memcache、Redis |
| 關系型數據庫 | MySQL、MariaDB、PostgreSQL |
| NoSQL數據庫 | Redis、MongoDB、Cassandra |
| 搜索 | Coreseek、Solr、ElasticSearch |
| 圖片處理 | GraphicsMagick、ImageMagick |
| 分布式訪問服務 | dubbo、dubbox |
4.可供選擇的可靠雲服務
對於初創公司還是建議盡可能的使用成熟可靠的雲服務和開源軟件，自身只專注於業務邏輯。
| 功能 | 可供選擇的雲服務 |
|---|---|
| 項目管理工具 | Teambition、Tower |
| 代碼托管平台 | GitHub、Gitlab、Bitbucket、CSDN CODE、Coding |
| 負載均衡 | 阿里雲SLB、騰訊雲CLB |
| 郵件服務 | SendCloud、MailGun |
| 消息隊列 | 阿里雲MNS、騰訊雲CMQ |
| 文件系統、圖片處理 | 七牛雲、阿里雲對象存儲OSS、騰訊雲對象存儲COS |
| Android推送 | 極光、個推、百度推送 |
| IOS推送 | 極光、個推、百度推送 |
| 聊天 | 融雲、環信 |
| 監控 | 監控寶、雲服務器自帶的監控服務 |
| 緩存 | 阿里雲緩存服務、騰訊雲彈性緩存 |
| 關系型數據庫 | 阿里雲RDS、騰訊雲CDB |
| NoSQL數據庫 | 阿里雲NoSQL產品、騰訊雲NoSQL產品 |
| 搜索 | 阿里雲開放搜索、騰訊雲搜TCS |
| 分布式訪問服務 | 阿里雲EDAS |
| 防火牆 | 阿里雲雲盾、騰訊雲安全 |
| 短信發送 | shareSDK、bmob、Luosimao |
| 社交登錄分享 | shareSDK |
5.選擇合適的數據庫產品和服務器系統
數據庫產品：
| 數據庫 | 數據存放位置 | 查找數據的區別 |
|---|---|---|
| Redis | 內存 | 基於鍵值對存儲，讀寫速度快 |
| MongoDB | 同時使用了硬盤和內存 | 每個數據有一個id（索引），知道id（索引）查詢速度快，不知道id（索引）效率低 |
| MySQL（MongoDB） | 硬盤 | 每個數據有一個id（索引），知道id（索引）查詢速度快，不知道id（索引）效率低 |
然后根據不同的產品需求選擇恰當的數據庫產品，如果沒有特殊的需求，Redis做緩存系統，MySQL 或 MariaDB 做數據庫（常見的設置是 數據庫默認字符集utf8，默認排序utf8_general_ci） 將會是很好的選擇。
軟件優化：
硬件優化：
架構優化：
-
分庫（把一張表的數據分別存儲在不同的數據庫，可用MyCat實現，MyCat，關系型數據庫分布式處理軟件）。
-
MyCat以代理服務器的形式位於App服務器和后台數據庫之間，
-
對外開放的接口是MySQL通信協議，將App服務器傳過來的sql語句按照路由的規則拆解轉發到不同的后台數據庫，並把結果匯總返回。
mycat部署模型如下：
服務器系統：
CentOS系統+Ngnix負載均衡&服務器
redis緩存+MySQL數據庫
HTTPS或websocket+簽名校驗+Json
6.選擇合適的消息隊列軟件：
當后台系統發現完成某些小任務需要花費很多時間，而且遲點晚成也不影響整個任務的完成進度時，就會把這些小任務交給消息隊列。例如發送郵件、短信、推送消息等任務都非常適合在消息隊列中處理。
把這些任務放在消息隊列中，可加快App后台請求都響應時間。同時消息隊列也能把大量的並發請求變成串行的請求，來減輕服務器的負擔。
常見的消息隊列軟件有：
| 消息隊列軟件 | 說明 |
|---|---|
| RabbitMQ | 重量級，適合企業級的開發，自帶Web監控界面，方便監控隊列的情況 |
| Redis | 輕量級，是一個key-value系統，但是也支持消息隊列這種數據結構，App后台中Redis被廣泛使用 |
| ZeroMQ | 號稱最快，尤其針對大吞吐量的需求場景 |
| ActiveMQ | Apache的一個子項目，能夠以代理人和點對點的技術實現隊列 |
7.使用分布式服務實現服務的復用：
隨着業務不斷增加，后台系統由一個單一應用膨脹為一個巨無霸系統，系統中聚合了大量的應用和服務，各個模塊之間有很多功能重復實現（例如登錄模塊），造成了開發、運維、部署的麻煩。
解決這些問題的方法就是把重復實現的模塊獨立部署為遠程服務，新增的業務調用遠程服務所提供的功能實現相關的業務，不依賴於里面具體的代碼實現。
8.實現遠程服務可以 參考 REST設計原則 和 RPC遠程調用協議。
開源的RPC庫有：
| 開源的RPC庫 | 說明 |
|---|---|
| Hprose | 輕量級、跨語言、跨平台、無侵入式、高性能動態遠程對象調用引擎庫 |
| Dubbo | 分布式服務框架，致力於提供高性能和透明化的RPC遠程調用服務和SOA服務治理方案 |
9.用戶驗證方案最佳實踐：
App操作中經常涉及用戶登錄操作，登錄就需要使用到用戶名和密碼，為了安全起見，在登錄過程中暴漏密碼的次數越少越好。
1.HTTPS協議是 HTTP協議 和 SSL／TLS協議 的組合。其是一個安全通信通道，基於HTTP開發，用於在客戶計算機和App后台之間交換信息。其使用安全套接字層（SSL）進行信息交換，簡單來說就是HTTP的安全版。
HTTPS實際上應用了安全套接字層（SSL）作為HTTP應用層的子層。
HTTPS的模型：
| HTTP |
|---|
| SSL／TLS（安全套接字層／傳輸層安全協議） |
| TCP |
| IP |
| 網絡傳輸 |
避免信息的泄漏，最基本的方案是所有涉及安全性的API請求都必須使用HTTPS協議。
2.選擇JSON作為數據交換格式
JSON是一種輕量級的數據交換格式，采用完全獨立於語言的文本格式，易於編寫，也易於機器解析和生成，而且對比XML更省流量，這些特性使得JSON成為理想的數據交換語言。
3.基本的用戶驗證方案
傳統Web網站使用Cookie+Session保持用戶的登錄狀態，App后台則使用token進行驗證，流程如下：
此時App已經獲取到了token值，為了安全，我們不在網絡上傳輸token，而使用簽名校驗（這里使用URL簽名）的方式，API請求加上URL簽名sign和用戶id后如下：
test.com/user/update?uid=2&sign=3f1e736bc4ae958ae7e8500b45aefdbb&age=22
這樣，token就不需要附在URL上了。App后台簽名校驗流程如下：
還有的童鞋喜歡設置時間戳，這樣時間一長，URL就失效了，也是一種不錯的進一步的優化方案。
建議：為了保障數據安全，這里建議 同時使用 HTTPS 和 簽名校驗。
結束語：在移動互聯網項目中，產品的研發講求 小步快走，快速迭代。 架構的設計也可以遵循同樣的思路。