目錄
asgi是非同步通訊服務規範。客戶端發起服務呼叫，但不等待結果。呼叫方立即繼續其工作，並不關心結果。如果呼叫方對結果感興趣，有一些機制可以讓其隨時被**方法返回結果。
asgi嘗試保持在乙個簡單的應用介面的前提下，提供允許資料能夠在任意的時候、被任意應用程序傳送和接受的抽象。並且同樣描述了乙個新的，相容http請求響應以及websocket資料幀的序列格式。允許這些協議能通過網路或本地socket進行傳輸，以及讓不同的協議被分配到不同的程序中。
#asgi example
程式設計客棧async def application(scope, receive, send):
event = await receive()
...
await send()
您可以使用 uvicorn，daphne 或 hypercorn 執行任何 asgi 框架
對於小型服務，您也可以直接編寫 asgi 應用程式。例如之前編寫的非同步框架。
python 中有以下幾個支援 asgi 的非同步框架
starlette
starlette 是乙個輕量級的 asgi 框架/工具包。它是構建高效能非同步服務的理想選擇，並且支援 http 和 websockets。
django channels
asgi 規範最初是設計就是用於 django channels 的。
channels 與其他asgi框架略有不同，它**程框架後端上提供了非同步前端。
同時 django channels 支援 websocket，後台任務和長期執行的連線，而應用程式**仍在標準執行緒上下文中執行
quart
quart 是乙個類似於 flask 的 asgi web 框架。quart 不僅與 flask 相似，而且與 flask api 相容！
該框架的作者希望保留了flask 的風格，只是向其中新增非同步、websocket 和 http 2支援。
因此，你可以從 flask 文件中學習 quart 的用法，只需要記住 quart 中的函式是非同步的就行。
乙個簡單的 quart 服務：
from quart import quart
app = quart(name)
@app.route('/')
async def hello():
return 'hello'app.run()
和 flask 是不是很像，只是多了乙個非同步 async
由於 quart 是從 flask 中演進過來的，因此 flask 的所有功能均可用：路由，中介軟體，會話，模板，藍圖等
uvicorn 是乙個快速的 asgi 伺服器，uvicorn 是基於 uvloop 和 httptools 構建的，是 python 非同步生態中重要的一員。
uvicorn 當前支援 http / 1.1wcqagwsp 和 websockets，將來計畫支援http / 2。
版本要求 python 3.5 以上，uvicorn 的安裝，
pip install uvicorn
示例如下：
執行命令如下，
uvicorn demo:app
服務啟動之後，我們通過瀏覽器就能方位該服務，預設埠 8000
daphne
daphne 伺服器是最早為 django channels 提供支援的 asgi 伺服器
daphne 它在生產中廣泛執行，並支援http / 1.1，http / 2和 websockets。
安裝和執行的命令如下：
pip install daphne daphne app:app和 uvicorn 命令類似，app 是檔名稱，app 是應用程式
hypercorn
hypercorn 最初是框架 quart 的一部分，然後被分離為獨立的 asgi 伺服器
同樣的，hypercorn 支援 http/1.1, http/2, 以及 websockets.
安裝和執行的命令如下：
pip install hypercorn hypercorn app:app
www.cppcns.comfastapi 是乙個基於 starlette 和 pydantic 的 api 框架，其靈感來自以前的 apista 伺服器版本
使用 python 3.6+ 型別宣告編寫 api 函式引數，並獲得自動資料轉換，資料驗證。
fastapi 最主要的特點是快，非常高的效能，向 nodejs 和 go 看齊，現有最快的python框架之一
同時它可以自動生成互動式 api 文件 ui，編寫 api 介面後，你就可以使用符合標準的 ui 如 swaggerui，redoc 等來使用 api。
其特點如下：
示例如下：
先安裝依賴的庫
pip install fastapi
pip install uvicorn
import uvicorn
from fastapi import fastapi
# 類似於 app = flask(__name__)
app = fastapi()
# 繫結路由和檢視函式
@app.get("/")
async def root():
return
# 在 windows 中必須加上 if __name__ == "__main__"，否則會丟擲 runtimeerror: this event loop is already running
if __name__ == '__main__':
# 啟動服務，因為我們這個檔案叫做 main.py，所以需要啟動 main.py 裡面的 app
# 第乙個引數 "main:app" 就表示這個含義，然後是 host 和 port 表示監聽的 ip 和埠
uvicorn.run(app='main:app', host="127.0.0.1", port=8000, reload=true, debug=true)
fastapi 的幾大功能：型別檢查、自動 swagger ui、支援 asyncio、強大的依賴注入系統
效能提公升注: 以下針對生產環境的大型專案而言fastapi利用非同步和輕量級的特點，大大提公升了效能。但非同步應用到實際中，並不是一件容易的事。fastapi的非同步不算難寫，邏輯不複雜的話，閉著眼睛加幾個await很簡單。但如果涉及到複雜系統。一處非同步，處處非同步。到底要不要用可能就見仁見智了。輕量級同時也代表著和flask一樣，很多東西需要自己diy。而不是像django一樣一站式解決。所以fastapi可能逐漸接過flask的位置，但還是難以對django發起挑戰。最重要的一點還是，選了python作為後端。可能打一開始就不是對效能有多敏感。而是看中python的開發效率和生態。如果從兼顧開發效率+效能的角度出發，那麼fastapi極大程度上會遇到來自go的強力競爭。只有再兼顧上python現有生態，fastapi才會有很大的優勢。我們可以假想乙個現有python專案，遇到了效能瓶頸，但不想脫離python的環境，或者不想承受更換語言的成本。那麼fastapi是個很好的未來。
api文件、型別檢測以及依賴注入fastapi完全擁抱了typing型別系統，高度整合了openapi(swagger ui)，正如他的名字一樣fastapi，從api開發的角度來說，無論是效能還是開發效率，它都足夠「fast」。為api文件提供了非常多的支援。無需任何配置，後端只要把endpoint寫出來，乙份詳盡的api文件就會自動生成。對於小型專案來說絕對是巨大優勢。型別檢測和依賴注入是api文件的基石 ，它們重點在於圍繞框架的「感知力」。inspect抓endpoint的引數，明確的知道每個api介面需要什麼，返回什麼。這會讓你感覺這個框架真的很有靈性。對於這方面我個人絕對是讚不絕口的。
簡單與簡潔會用flask就會fastapi，fastapi的學習曲線十分平滑。從下至上有很多值得學習參透的。非常建議有空的同學過一遍starlette，uvicorn，fastapi的原始碼。加起來也沒有django多。
相關生態和社群還未成熟python的非同步發展略為緩慢，僅僅fastapi還不能撐起一片天。例如現在還沒有完全可靠的非同步orm。不少東西還需要自己造輪子。在小專案上，這可能影響不是很大。直接寫**可能比配置外掛程式來的快。但將很大程度上影響它被採用到線上生產環境。總結你可以將fastapi看成新出爐的flask plus。如果你有採用flask的理由，那麼你同樣有將來採用fastapi的理由。
WSGI與ASGI的區別與聯絡
區別cgi common gateway inte ce，通用閘道器介面 定義客戶端與web伺服器的交流方式的乙個程式，例如正常情況下客戶端傳送過來乙個請求，根據http協議web伺服器將請求的內容解析出來，經過處理會後，再將返回的內容封裝好。例如伺服器返回乙個html頁面，並且根據http協議構建...
python中非同步與同步
首先理解非同步與同步的概念 非同步 多工，多個任務之間執行沒有先後順序，可以同時執行，執行的先後順序不會有什麼影響，存在的多條執行主線。同一時間只能做一件事，做完了才能做下一件事情 同步 多工，多個任務之間執行的時候要求有先後順序，必須乙個先執行完成之後，另乙個才能繼續執行，只有乙個主線 可以近似的...
python的多執行緒與非同步程式設計
作業系統中，程序是資源分配的基本單位，執行緒是pu排程 程式執行 的最小單位。計算機執行程式必須分配資源 記憶體，有堆 棧 自右儲存區 全域性 靜態變數區 資料區 關於多執行緒的介紹，這不再闡述，請見python內建函式thread encoding utf 8 多執行緒測試 import time...