Django項目細(xì)節(jié)
跨域CORS
我們?yōu)榍岸撕秃蠖朔謩e設(shè)置了兩個不同的域名
JWT認(rèn)證機(jī)制
JWT協(xié)議似乎已經(jīng)應(yīng)用十分廣泛，JSON Web Token——一種基于token的json格式web認(rèn)證方法。基本的原理是，第一次認(rèn)證通過用戶名密碼，服務(wù)端簽發(fā)一個json格式的token。后續(xù)客戶端的請求都攜帶這個token，服務(wù)端僅需要解析這個token，來判別客戶端的身份和合法性。
Celery異步任務(wù)
Celery是基于Python開發(fā)的一個分布式任務(wù)隊列框架，支持使用任務(wù)隊列的方式在分布的機(jī)器/進(jìn)程/線程上執(zhí)行任務(wù)調(diào)度。
選擇中間人
RabbitMQ
RabbitMQ 功能完備、穩(wěn)定、耐用，并且安裝簡便，是生產(chǎn)環(huán)境的絕佳選擇。 配合 Celery 使用 RabbitMQ 的詳情見
FastDFS分布式文件系統(tǒng)
通過獨立文件服務(wù)器可以解決一些問題，如果某天存儲文件的那臺服務(wù)突然down了怎么辦？可能你會說，定時將文件系統(tǒng)備份，這臺down機(jī)的時候，迅速切換到另一臺就OK了，但是這樣處理需要人工來干預(yù)。另外，當(dāng)存儲的文件超過100T的時候怎么辦？單臺服務(wù)器的性能問題？這個時候我們就應(yīng)該考慮分布式文件系統(tǒng)了。
業(yè)務(wù)繼續(xù)發(fā)展，單臺服務(wù)器存儲和響應(yīng)也很快到達(dá)了瓶頸，新的業(yè)務(wù)需要文件訪問具有高響應(yīng)性、高可用性來支持系統(tǒng)。分布式文件系統(tǒng)，一般分為三塊內(nèi)容來配合，服務(wù)的存儲、訪問的仲裁系統(tǒng)，文件存儲系統(tǒng)，文件的容災(zāi)系統(tǒng)來構(gòu)成，仲裁系統(tǒng)相當(dāng)于文件服務(wù)器的大腦，根據(jù)一定的算法來決定文件存儲的位置，文件存儲系統(tǒng)負(fù)責(zé)保存文件，容災(zāi)系統(tǒng)負(fù)責(zé)文件系統(tǒng)和自己的相互備份。
優(yōu)點：擴(kuò)展能力: 毫無疑問，擴(kuò)展能力是一個分布式文件系統(tǒng)最重要的特點；高可用性: 在分布式文件系統(tǒng)中，高可用性包含兩層，一是整個文件系統(tǒng)的可用性，二是數(shù)據(jù)的完整和一致性；彈性存儲: 可以根據(jù)業(yè)務(wù)需要靈活地增加或縮減數(shù)據(jù)存儲以及增刪存儲池中的資源，而不需要中斷系統(tǒng)運(yùn)行
缺點：系統(tǒng)復(fù)雜度稍高，需要更多服務(wù)器
Docker
Docker是一個開發(fā)，運(yùn)輸和運(yùn)行應(yīng)用程序的開放平臺。Docker使您可以將應(yīng)用程序與基礎(chǔ)架構(gòu)分離，以便快速交付軟件。使用Docker，您可以像管理應(yīng)用程序一樣管理基礎(chǔ)架構(gòu)。通過利用Docker的方法快速發(fā)送，測試和部署代碼，您可以顯著減少編寫代碼和在生產(chǎn)中運(yùn)行代碼之間的延遲。
頁面靜態(tài)化等技術(shù)
傳統(tǒng)的django頁面渲染:
數(shù)據(jù)庫查詢-->數(shù)據(jù)+Templates--> 前端
使用頁面靜態(tài)化技術(shù):
腳本實現(xiàn)數(shù)據(jù)庫查詢--> 數(shù)據(jù)+Templates--> 靜態(tài)頁面-->前端
頁面靜態(tài)化即將動態(tài)渲染生成的頁面結(jié)果保存成html文件，放到靜態(tài)文件服務(wù)器中。用戶訪問的時候訪問的直接是處理好之后的html靜態(tài)文件。
captcha
captcha 是用 python 寫的生成驗證碼的庫，它支持圖片驗證碼和語音驗證碼，我們使用的是它生成圖片驗證碼的功能。
Django REST framework
Web應(yīng)用編程接口（API）自動請求網(wǎng)站的特定信息而不是整個網(wǎng)頁。因此即便數(shù)據(jù)瞬息萬變，它呈現(xiàn)的信息也都是最新的
QQ登錄
QQ登錄，亦即我們所說的第三方登錄，是指用戶可以不在本項目中輸入密碼，而直接通過第三方的驗證，成功登錄本項目。
若想實現(xiàn)QQ登錄，需要成為QQ互聯(lián)的開發(fā)者，審核通過才可實現(xiàn)。注冊方法可參考鏈接http://wiki.connect.qq.com/%E6%88%90%E4%B8%BA%E5%BC%80%E5%8F%91%E8%80%85
成為QQ互聯(lián)開發(fā)者后，還需創(chuàng)建應(yīng)用，即獲取本項目對應(yīng)與QQ互聯(lián)的應(yīng)用ID，創(chuàng)建應(yīng)用的方法參考鏈接http://wiki.connect.qq.com/__trashed-2
QQ登錄開發(fā)文檔連接http://wiki.connect.qq.com/%E5%87%86%E5%A4%87%E5%B7%A5%E4%BD%9C_oauth2-0
樂觀鎖和悲觀鎖
悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數(shù)據(jù)的時候都認(rèn)為別人會修改，所以每次在拿數(shù)據(jù)的時候都會上鎖，這樣別人想拿這個數(shù)據(jù)就會block直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機(jī)制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數(shù)據(jù)的時候都認(rèn)為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù)，可以使用版本號等機(jī)制。樂觀鎖適用于多讀的應(yīng)用類型，這樣可以提高吞吐量，像數(shù)據(jù)庫如果提供類似于write_condition機(jī)制的其實都是提供的樂觀鎖。
Django與Flask的區(qū)別
（1）Flask
Flask確實很“輕”，不愧是Micro Framework，從Django轉(zhuǎn)向Flask的開發(fā)者一定會如此感慨，除非二者均為深入使用過
Flask自由、靈活，可擴(kuò)展性強(qiáng)，第三方庫的選擇面廣，開發(fā)時可以結(jié)合自己最喜歡用的輪子，也能結(jié)合最流行最強(qiáng)大的Python庫
入門簡單，即便沒有多少web開發(fā)經(jīng)驗，也能很快做出網(wǎng)站
非常適用于小型網(wǎng)站
非常適用于開發(fā)web服務(wù)的API
開發(fā)大型網(wǎng)站無壓力，但代碼架構(gòu)需要自己設(shè)計，開發(fā)成本取決于開發(fā)者的能力和經(jīng)驗
各方面性能均等于或優(yōu)于Django
Django自帶的或第三方的好評如潮的功能，F(xiàn)lask上總會找到與之類似第三方庫
Flask靈活開發(fā)，Python高手基本都會喜歡Flask，但對Django卻可能褒貶不一
Flask與關(guān)系型數(shù)據(jù)庫的配合使用不弱于Django，而其與NoSQL數(shù)據(jù)庫的配合遠(yuǎn)遠(yuǎn)優(yōu)于Django
Flask比Django更加Pythonic，與Python的philosophy更加吻合
（2）Django
Django太重了，除了web框架，自帶ORM和模板引擎，靈活和自由度不夠高
Django能開發(fā)小應(yīng)用，但總會有“殺雞焉用牛刀”的感覺
Django的自帶ORM非常優(yōu)秀，綜合評價略高于SQLAlchemy
Django自帶的模板引擎簡單好用，但其強(qiáng)大程度和綜合評價略低于Jinja
Django自帶ORM也使Django與關(guān)系型數(shù)據(jù)庫耦合度過高，如果想使用MongoDB等NoSQL數(shù)據(jù)，需要選取合適的第三方庫，且總感覺Django+SQL才是天生一對的搭配，Django+NoSQL砍掉了Django的半壁江山
Django目前支持Jinja等非官方模板引擎
Django自帶的數(shù)據(jù)庫管理app好評如潮
Django非常適合企業(yè)級網(wǎng)站的開發(fā)：快速、靠譜、穩(wěn)定
Django成熟、穩(wěn)定、完善，但相比于Flask，Django的整體生態(tài)相對封閉
Django是Python web框架的先驅(qū)，用戶多，第三方庫最豐富，最好的Python庫，如果不能直接用到Django中，也一定能找到與之對應(yīng)的移植
Django上手也比較容易，開發(fā)文檔詳細(xì)、完善，相關(guān)資料豐富
