本書講了什么

通過闡述移動互聯(lián)網(wǎng)中App后臺開發(fā)的特點洞坑，梳理了App后臺開發(fā)中會遇到的各個技術(shù)點缠局，給出了生產(chǎn)環(huán)境常用軟件的實戰(zhàn)運維經(jīng)驗總結(jié)吼鳞。

作者什么來頭

當當沒寫看蚜，我也懶得查。 曾健生

第1章 App后臺入門

App后臺的功能

遠程存儲數(shù)據(jù)赔桌。

消息中轉(zhuǎn)供炎。

App后臺架構(gòu)

梳理APP業(yè)務(wù)流程。

整理每個流程會遇到的問題疾党。

根據(jù)問題音诫，探討可行的技術(shù)方案。

有機融合這些方案雪位，就是初步的架構(gòu)竭钝。

架構(gòu)設(shè)計的特點

架構(gòu)是和業(yè)務(wù)緊密相關(guān)。業(yè)務(wù)不同雹洗，解決方案也不同香罐，架構(gòu)就不同。

架構(gòu)的演變是業(yè)務(wù)上的驅(qū)動时肿，APP處于不同發(fā)展階段庇茫，架構(gòu)上也需變化。

架構(gòu)不是為了炫耀技術(shù)螃成，是為了滿足業(yè)務(wù)需要旦签，不應(yīng)過度設(shè)計。

App和App后臺的通信

1.用HTTP協(xié)議還是私有協(xié)議寸宏？

APP與后臺通信分為使用通用語言和使用暗語兩種方式宁炫。協(xié)議就相當于一套語言，雙方都知道每個字節(jié)的具體含義氮凝。HTTP協(xié)議是使用的最廣泛的協(xié)議羔巢。大多數(shù)開發(fā)語言都支持通用協(xié)議，有大量成熟模塊供程序員調(diào)用，方便程序員解析這些通用協(xié)議的內(nèi)容竿秆。

使用私有協(xié)議相當于使用暗語炭臭，類似于開發(fā)一種新的語言。私有協(xié)議對協(xié)議的封裝和拆解工作量大袍辞，APP程序員和后臺程序員都要增加額外的工作量鞋仍，且私有協(xié)議對程序員的設(shè)計能力要求高。除非開發(fā)者對APP的安全性和性能要求高搅吁，不然選擇HTTP協(xié)議就足夠威创。

2.APP和后臺通信使用長連接還是短連接？

可以用打電話的模型理解：是一致保持通話谎懦，還是有需要才撥號通話肚豺。長連接就相當于一直保持通話，服務(wù)器能保持的通信數(shù)量有限界拦，如果達到數(shù)量極限吸申，需要增加服務(wù)器。這種通信方式多數(shù)是使用Socket和WebSocket連接長時間連接享甸，對程序員素質(zhì)要求高截碴，開發(fā)困難，除了手游和聊天推送外蛉威，不建議使用日丹。當APP和服務(wù)器使用短連接，主要使用HTTP協(xié)議蚯嫌，開發(fā)效率高哲虾，推薦使用。

3.APP和后端是怎么通信的择示？

APP后臺只提供了一系列功能給APP使用束凑，這些功能以API的形式提供。API（應(yīng)用程序編程接口）是一些預(yù)先定義的函數(shù)栅盲，目的是提供應(yīng)用程序與開發(fā)人員基于某軟件或硬件得以訪問一組例程的能力汪诉，而又無需訪問源碼，或理解內(nèi)部工作機制的細節(jié)剪菱。

當APP調(diào)用API時摩瞎，需要明確：

API的用途拴签。比如用取款器取款孝常、查余額。

輸入什么蚓哩。比如取款需要輸入金額构灸。

結(jié)果是什么。比如取款成功還是失敗岸梨。

4.后端是返回給API的數(shù)據(jù)格式

API一般是以HTTP的形式調(diào)用的喜颁，通過HTTP傳入?yún)?shù)返回數(shù)據(jù)稠氮。JSON是一種輕量級數(shù)據(jù)交換格式，比XML更省流半开。{“age”：11隔披，“name”：“jeff”}

APP和后臺通訊過程

選擇服務(wù)器

如果出現(xiàn)了APP訪問量爆發(fā)的情況，解決訪問壓力最快的方式就是升級服務(wù)器的硬件寂拆。使用云服務(wù)升級硬件很簡單：選擇硬件配置奢米；付款；重啟服務(wù)器纠永。上線初期一般都在一臺服務(wù)器上搭建所有服務(wù)鬓长，隨著APP的發(fā)展，這些服務(wù)需要部署在不同的服務(wù)器上尝江。

選擇編程語言

選擇符合業(yè)務(wù)場景的最熱門的變成語言涉波。

1.每種編程語言都有自己擅長的業(yè)務(wù)場景和性能特性。

2.選擇開發(fā)效率最高的編程語言炭序。

3.忌諱用兩套不同的語言維護同一個業(yè)務(wù)邏輯啤覆。

4.一個系統(tǒng)中，不同的業(yè)務(wù)邏輯可以用不同的編程語言實現(xiàn)惭聂。

研發(fā)階段

Android和iOS工程師先設(shè)計前端架構(gòu)城侧，或先做界面。后端架構(gòu)設(shè)計完成后彼妻，通過三點初步設(shè)定API接口：API是有什么用嫌佑？API的輸入函數(shù)是什么？API返回什么數(shù)據(jù)侨歉？后臺工程師向前端說明API接口屋摇，初期API不用實現(xiàn)功能，返回假數(shù)據(jù)幽邓，后期慢慢實現(xiàn)炮温。

最適合App的開發(fā)模式——敏捷開發(fā)

略，近期=找本敏捷的書學(xué)習(xí)下牵舵。

每日例會

昨天完成了哪些任務(wù)柒啤？

每個任務(wù)用了多少時間傻谁？

沒完成的任務(wù)還要多少時間钳榨？

今天準備做哪些工作？

有什么工作需要其他同事配合换棚？

回顧會議

這輪迭代做的好的和不好的地方没炒。

第2章 App后臺基礎(chǔ)技術(shù)

從App業(yè)務(wù)邏輯中提煉API接口步驟：

業(yè)務(wù)邏輯思維導(dǎo)圖涛癌。

功能—業(yè)務(wù)邏輯思維導(dǎo)圖。

基本功能關(guān)系模塊。

功能模塊接口UML（設(shè)計出API）拳话。

在設(shè)計稿標注API先匪。

編寫API文檔。

業(yè)務(wù)邏輯思維導(dǎo)圖

用思維導(dǎo)圖把結(jié)構(gòu)關(guān)系列出來弃衍，包括里面的功能呀非。把相同的元素整理出來，比如都是相同的推送镜盯、評論姜钳、圖片上傳，然后用相同顏色表示出來形耗。

功能—業(yè)務(wù)邏輯思維導(dǎo)圖

MVC哥桥，寫一個model的名字出來，開發(fā)人員能夠把業(yè)務(wù)邏輯里面的東西和其關(guān)聯(lián)激涤。簡單說就是一對多拟糕，一就是model，多就是業(yè)務(wù)邏輯倦踢，一個model對應(yīng)多個業(yè)務(wù)邏輯送滞。先做最上限的一層，盡可能多的進行一對多的分析辱挥，然后按照最小獨立原則犁嗅，看這個是不是一個最小的系統(tǒng)，按設(shè)計原理：每個model都是一個可獨立運行的模塊晤碘，也就是說model和model之間是沒關(guān)系的褂微。在思維導(dǎo)圖中，其實就是業(yè)務(wù)邏輯和功能模塊的結(jié)合园爷。

劃分功能模塊依據(jù)三個原則：

功能模塊和業(yè)務(wù)邏輯之間的關(guān)系宠蚂。

功能模塊和功能模塊之間不能有關(guān)系。

功能模塊要盡可能的實現(xiàn)一堆多（一個功能模塊對應(yīng)多個業(yè)務(wù)邏輯）童社。

基本功能模塊關(guān)系

現(xiàn)在要做第三個圖求厕，步驟是從業(yè)務(wù)邏輯進入功能模塊，功能模塊按人和事來分扰楼。

人有哪些功能模塊呀癣？

事有哪些功能模塊？

人和事之間的關(guān)系又有哪些功能模塊弦赖？

功能模塊接口UML（設(shè)計出API）

現(xiàn)在只考慮功能模塊项栏，做功能模塊的UML圖，要設(shè)計哪些接口去解決哪些問題腾节。接口是基于現(xiàn)在的模塊忘嫉、粗略的模塊“赶伲基于現(xiàn)在的模塊設(shè)計接口庆冕，就是要提高耦合度，確保耦合正確劈榨。

編寫在線API測試文檔

API在線測試文檔使用Swagger-UI搭建访递。

設(shè)計稿標注API

后臺開發(fā)在設(shè)計搞上標注出哪個界面調(diào)用哪個API。

設(shè)計API的要點

根據(jù)對象而不是頁面設(shè)計API同辣。

API命名簡單易懂拷姿。

API安全性。

API所返回的數(shù)據(jù)旱函。API返回的數(shù)據(jù)中正確值和空值的類型必須一樣响巢。數(shù)據(jù)庫設(shè)計得時候，合理的設(shè)計原則是所有字段都有默認值棒妨，不允許Null值踪古。

圖片的處理。APP本地緩存圖片券腔，緩存圖片不存在時才請求服務(wù)器API伏穆。當APP需要某種尺寸的圖片，由APP通知服務(wù)器所需圖片的尺寸纷纫，服務(wù)端動態(tài)生成并緩存枕扫。

返回的提示信息。APP后臺只返回信息代碼辱魁，具體文字APP決定烟瞧。

在線API測試文檔。

APP啟動時調(diào)用一個API獲取必要的初始化信息染簇。

API版本升級需要注意：V2版本的Controller必須繼承V1版的Controller燕刻，這樣V2版本的API只重寫需要改動的API。

如何選擇合適的數(shù)據(jù)庫產(chǎn)品

Redis剖笙，MongoDB卵洗，MySQL讀寫數(shù)據(jù)的區(qū)別

Redis的數(shù)據(jù)存放在服務(wù)器的內(nèi)存，內(nèi)存滿了需要擴容弥咪，只能使用Redits的分布式方案过蹂。

MongoDB同時使用硬盤和內(nèi)容，使用MMAP機制進行數(shù)據(jù)文件讀寫聚至，可以直接把文件映射到進程的內(nèi)存空間中酷勺，這樣文件在內(nèi)存中有對應(yīng)的地址，對文件的讀寫是能通過操作內(nèi)存進行的扳躬。

MySQL數(shù)據(jù)存放在硬盤中脆诉，緩存的是查詢結(jié)果而不是緩存數(shù)據(jù)甚亭。

Redis，MongoDB击胜，MySQL查找數(shù)據(jù)的區(qū)別

Redis的數(shù)據(jù)是基于“鍵值對”存儲亏狰，鍵相當于門牌號，值相當于房間偶摔，Redis查找數(shù)據(jù)每次都是直奔目標暇唾，讀寫速度快。

MongoDB和MySQL中辰斋，沒組數(shù)都有一個id（或為每組數(shù)據(jù)建立索引）策州，這個id和索引就相當于門牌號。

MongoDB和MySQL中查找數(shù)據(jù)有兩種模式：知道id或索引宫仗，不知道id或索引够挂。不知道的時候就要遍歷。

Redis藕夫，MongoDB下硕，MySQL適用場景（略）

消息隊列的工作流程

巨無霸系統(tǒng)的危害

隨著業(yè)務(wù)不斷增加，后臺系統(tǒng)由一個單一的應(yīng)用膨脹為巨無霸系統(tǒng)汁胆，具體表現(xiàn)為系統(tǒng)中聚合了大量的應(yīng)用和服務(wù)梭姓，各模塊之間有很多功能重復(fù)實現(xiàn)，造成了開發(fā)嫩码、運維誉尖、部署上的麻煩。

遠程服務(wù)的優(yōu)點

解決上述問題的方法是把重復(fù)實現(xiàn)的模塊獨立部署為遠程服務(wù)铸题，新增的業(yè)務(wù)調(diào)用遠程服務(wù)所提供的功能實現(xiàn)相關(guān)業(yè)務(wù)铡恕，不依賴于里面具體的代碼實現(xiàn)。下圖為把登錄模塊部署為一個遠程服務(wù)丢间。遠程服務(wù)的實現(xiàn)：REST/PRC/開源PRC庫探熔。

搜索技術(shù)的基本原理

如果知道每行數(shù)據(jù)中包含多少關(guān)鍵字，然后建立一個映射表烘挫，把每個關(guān)鍵字出現(xiàn)在哪行數(shù)據(jù)中記錄下來诀艰，搜索就不用遍歷。當知道關(guān)鍵字饮六，只需要查找映射表其垄，找到關(guān)鍵詞，根據(jù)關(guān)鍵詞建立的映射關(guān)系就能查到包含這個關(guān)鍵詞的數(shù)據(jù)卤橄。知道每行數(shù)據(jù)中包含多少個關(guān)鍵字的過程绿满，就是分詞。常見開源搜索軟件：Lucene/Solr/ElasticSearch/Sphnix/CoreSeek

定時任務(wù)

APP后臺開發(fā)經(jīng)常需要執(zhí)行一些定時任務(wù)窟扑，如定期清理垃圾文件等喇颁。

第3章 App后臺核心技術(shù)

用戶驗證方案

使用HTTPS協(xié)議

HTTPS基于HTTP開發(fā)漏健，用于在客戶計算機和APP后臺之間交換信息。其使用安全套接字層（SSL）進行信息交換橘霎，簡單來說其是HTTP的安全版蔫浆。HTTPS實際上使用了安全套接字層（SSL）作為HTTP應(yīng)用層的子層。

基本的用戶登錄方案

URL簽名

AES對稱加密（略）

App后臺發(fā)送短信簡介

發(fā)送手機短信要通過運營商的短信通道茎毁，但通道費用過高克懊，進而催生了短信平臺忱辅。短信平臺購買了運營商的短信通道后七蜘，把一個通道給一批企業(yè)共同使用，讓企業(yè)按發(fā)送短信數(shù)量付費墙懂，從而降低了企業(yè)發(fā)送短信的成本橡卤，同時短信平臺也初步審核短信內(nèi)容，避免出發(fā)短信通道的使用限制损搬。APP后臺購買了短信平臺的短信服務(wù)后碧库，就能通過短信平臺的API接口發(fā)送短信。

內(nèi)容的推拉

如果APP要知道首頁是否有內(nèi)容更新巧勤，通過輪詢機制訪問獲取API嵌灰，從API是否返回更新的數(shù)據(jù)得知是否有內(nèi)容更新。輪詢即每隔一段時間颅悉，APP向后臺發(fā)送請求獲取是數(shù)據(jù)沽瞭。缺點：耗電、耗流量剩瓶。

推模式的流程

不能只用推模式驹溃，手機網(wǎng)絡(luò)環(huán)境的復(fù)雜性，不能保證數(shù)據(jù)更新的通知一定能到達APP延曙，所以也要采用輪訓(xùn)的方式定期拉數(shù)據(jù)豌鹤，使用推拉結(jié)合時輪詢的時間間隔可以設(shè)置的比較長。

文件系統(tǒng)

盡量使用成熟可靠的云服務(wù)和開源軟件枝缔，自身只專注于業(yè)務(wù)邏輯布疙。

第4章 Linux-App后臺應(yīng)用最廣泛的系統(tǒng)

后臺開發(fā)需要兼顧開發(fā)與運維兩方面，現(xiàn)在的APP服務(wù)器大多是運行在Linux系統(tǒng)愿卸，因此開發(fā)工作中設(shè)計大量Linux的運維操作拐辽。具體操作不看了。

第5章 Nginx-App后臺HTTP服務(wù)的利器

Nginx是一個高性能的HTTP和反向代理服務(wù)器擦酌，在BAT和眾多互聯(lián)網(wǎng)公司有廣泛應(yīng)用俱诸，其主要特點是占用內(nèi)存少，并發(fā)能力強赊舶。略略略睁搭。

第6章 MySQL-App后臺最常用的數(shù)據(jù)庫

第7章 Redis-App后臺高性能的緩存系統(tǒng)

MySQL速寫速度慢赶诊，隨著互聯(lián)網(wǎng)發(fā)展，越來越多業(yè)務(wù)場景需要滿足：少量數(shù)據(jù)需要經(jīng)常被讀寫园骆，對速度要求高舔痪；能提供豐富的數(shù)據(jù)結(jié)構(gòu)；提供數(shù)據(jù)落地的功能锌唾。Redis就死滿足上述需求的開源Key-Value內(nèi)存存儲系統(tǒng)锄码。

第8章 MongoDB——App后臺新興的數(shù)據(jù)庫

MongoDB是介于關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫之間的產(chǎn)品，是非關(guān)系型數(shù)據(jù)庫當中功能最豐富晌涕、最像關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)庫滋捶。是由10gen公司基于C++編寫，知名IT公司使用其構(gòu)建自己的核心應(yīng)用的有eBay余黎、Cisco重窟、Adobe等。它的主要特點：讀寫性能高惧财、靈活的文檔模型給開發(fā)帶來的方便巡扇、水平擴展機制能輕松應(yīng)對從百萬到十億級別的數(shù)據(jù)處理。這也是MongoDB名字來源于單詞humongous的原因垮衷。

第9章 App后臺架構(gòu)剖析（略）

第10章 App后臺架構(gòu)的演進

架構(gòu)的核心要素

高性能厅翔。

高可用。

可伸縮搀突。

可擴展刀闷。

安全性。

架構(gòu)的演進

單機部署描姚。

分布式部署涩赢。

服務(wù)化。

架構(gòu)的特點

每個App的后臺架構(gòu)不會完全一樣轩勘。

架構(gòu)的演進是由業(yè)務(wù)驅(qū)動的筒扒。

架構(gòu)不是為了炫耀技術(shù)。