http://www.oschina.NET/translate/in_deep_with_django_channels_the_future_of_real_time_apps_in_django
今天，我們很高興請到Jacob Kaplan-Moss。Jacob是來自Herokai，也是 Django的長期的核心代碼貢獻者，他將在這里分享一些他對某些特性的深入研究，他認為這些特性將重新定義框架未來。
當Django剛創建時，那是十多年前，網絡還是一個不太復雜的地方。大部分的網頁都是靜態的。由數據庫支撐的模型/視圖/ 控制器架構的網絡應用還是很新鮮的東西。Ajax剛剛開始被使用，只在較少的場景中。
到現在2016年，網絡明顯更加強大。過去的幾年里已經看到了所謂的“實時”網絡應用：在這類應用中客戶端和服務器之間、點對點通信交互非常頻繁。包含很多服務（又名微服務）的應用也變成是常態。新的web技術允許web應用程序走向十年前我們只敢在夢里想象的方向。這些核心技術之一就是WebSockets：一種新的提供全雙工通信的協議——一個持久的，允許任何時間發送數據的客戶端和服務器之間的連接。
在這個新的世界，Django顯示出了它的老成。在其核心，Django是建立在請求和響應的簡單概念之上的：瀏覽器發出請求，Django調用一個視圖，它返回一個響應並發送回瀏覽器。
這在WebSockets中是行不通的 ！視圖的生命周期只在一個請求當中，沒有一種機制能打開一個連接不斷的發送數據到客戶端，而不發送相關請求。
因此：Django Channels就應運而生了。Channels,簡而言之,取代了Django中的“guts” ——請求/響應周期發送跨通道的消息。Channels允許Django以非常類似於傳統HTTP的方式支持WebSockets。Channels也允許在運行Django的服務器上運行后台任務。HTTP請求表現以前一樣,但也通過Channels進行路由。因此,在Channels 支持下Django現在看起來像這樣:
如您所見，Django Channels引入了一些新的概念:
Channels基本上就是任務隊列：消息被生產商推到通道，然后傳遞給監聽通道的消費者之一。如果你使用Go語言中的渠道,這個概念應該相當熟悉。主要的區別在於，Django Channels通過網絡工作，使生產者和消費者透明地運行在多台機器上。這個網絡層稱為通道層。通道設計時使用Redis作為其首選通道層，雖然也支持其他類型(和API來創建自定義通道層)。有很多整潔和微妙的技術細節，查閱文檔可以看到完整的記錄。
現在，通道作為一個獨立的應用程序搭配使用Django 1.9使用。計划是將通道合並到Django1.10版本，今年夏天將會發布。
我認為Channels將是Django的一個非常重要的插件：它們將支撐Django順利進入這個新的web開發的時代。雖然這些api還沒有成為Django的一部分，他們將很快就會是！所以，現在是一個完美的時間開始學習Channels：你可以了解未來的Django。
開始實踐：如何在Django中實現一個實時聊天應用
作為一個例子，我構建了一個簡單的實時聊天應用程序——就像一個非常非常輕量級的Slack。有很多的房間,每個人都在同一個房間里可以聊天,彼此實時交互（使用WebSockets）。
你可以訪問我在網絡上部署的例子，看看在GitHub上的代碼，或點擊這個按鈕來部署自己的。（這需要一個免費的Heroku賬戶，所以得要先注冊）：
注意:你需要在點擊上面的按鈕后，啟動工作進程。使用儀表盤或運行heroku ps:scale web=1:free worker=1:free。
如果你想深入了解這個應用程序是如何工作的——包括你為什么需要worker！——那么請繼續讀下去。我將會一步一步來構建這個應用程序，並突出關鍵位置和概念。
第一步——從Django開始
雖然在實現上有了很大差異，但是這仍舊是我們使用了十年的Django。所以第一步和其他任何Django應用是一樣的（如果你是Django新手，你得看看如何在Heroku上開始使用Python和Django新手教程）。創建一個工程后，你可以定義模型來表示一個聊天室和其中的消息（chat/models.py）：
|
1
2
3
4
5
6
7
8
9
|
class
Room(models.Model):
name
=
models.TextField()
label
=
models.SlugField(unique
=
True
)
class
Message(models.Model):
room
=
models.ForeignKey(Room, related_name
=
'messages'
)
handle
=
models.TextField()
message
=
models.TextField()
timestamp
=
models.DateTimeField(default
=
timezone.now, db_index
=
True
)
|
（在這一步中，包括后面的例子，我已經將代碼最簡化，希望能將焦點放到重點上，全部代碼請看Gitbub。）
|
1
2
3
4
5
6
7
8
9
10
11
12
|
def
chat_room(request, label):
# If the room with the given label doesn't exist, automatically create it
# upon first visit (a la etherpad).
room, created
=
Room.objects.get_or_create(label
=
label)
# We want to show the last 50 messages, ordered most-recent-last
messages
=
reversed
(room.messages.order_by(
'-timestamp'
)[:
50
])
return
render(request,
"chat/room.html"
, {
'room'
: room,
'messages'
: messages,
})
|
現在，我們已經已經有了一個可以運行的Django應用。如果你在標准的Django環境中運行它，你可以看到已經存在的聊天室和聊天記錄，但是聊天室內無法進行交互操作。實時沒有起作用，我們得做工作來處理 WebSockets。
接下來我們做什么
為了搞明白接下來后台需要做些什么，我們得先看下客戶端的代碼。你可以在 chat.js 中找到，其實也沒做多少工作！首先，創建一個 websocket：
|
1
2
|
var ws_scheme
=
window.location.protocol
=
=
"https:"
?
"wss"
:
"ws"
;
var chat_socket
=
new ReconnectingWebSocket(ws_scheme
+
'://'
+
window.location.host
+
"/chat"
+
window.location.pathname);
|
注意：
-
像HTTP和 HTTPS一樣，WebSocket協議區分為安全和非安全兩種，我們可以按照需要選擇合適的.
-
因為Heroku的路由有60秒鍾過期的問題。 我使用了 一個瀏覽器WebSocket小技巧 可以在socket斷開時自動重連。 （感謝Kenneth Reitz，在他的 Flask WebSocket例子中指出了這一點）。
接下來，我們將加入一個回調函數，當表單提交時，我們就通過WebSocket發送數據（而不是 POST數據）：
|
1
2
3
4
5
6
7
8
|
$(
'#chatform'
).on(
'submit'
, function(event) {
var message
=
{
handle: $(
'#handle'
).val(),
message: $(
'#message'
).val(),
}
chat_socket.send(JSON.stringify(message));
return
false;
});
|
我們可以通過WebSocket發送任何想要發送的數據。像眾多的API一樣， JSON 是最容易的，所以我們將要發送的數據打包成JSON格式。
最后，我們需要將回調函數與WebSocket上的新數據接收事件對接起來：
|
1
2
3
4
5
6
7
8
|
chatsock.onmessage
=
function(message) {
var data
=
JSON.parse(message.data);
$(
'#chat'
).append(
'<tr>'
+
'<td>'
+
data.timestamp
+
'</td>'
+
'<td>'
+
data.handle
+
'</td>'
+
'<td>'
+
data.message
+
' </td>'
+
'</tr>'
);
};
|
簡單提示：從獲取的信息中拉取數據，在會話的表上加上一行。如果現在就運行這個代碼，他是無法運行的，現在還沒有誰監聽WebSocket連接呢，只是簡單的HTTP。現在，讓我們來連接WebSocket。
安裝和創建 Channels
要將這個應用“通道化”，我們需要做三件事情：安裝Channels，建立通道層，定義通道路由，修改我們的工程使其運行在Channels上（而不是WSGI）。
1. 安裝Channels
要安裝Channels，只需要執行pip install channels，然后將 "channels”添加到 INSTALLED_APPS配置項中。安裝Channels后，允許Django以“通道模式”運行，使用上面描述的通道架構來完成請求/響應的循環。（為了向后兼容，你仍可以以 WSGI模式運行Django ，但是在這種模式下WebSockets和Channel的其他特性就不能工作了。）
2. 選擇一個通道層
接下來，我們將定義一個通道層。這是Channels用來在消費者和生產者（消息發送者）之間傳遞消息的交換機制。 這是一種有特定屬性的消息隊列（詳細信息請查看Channels文檔）。
我們將使用redis作為我們的通道層：它是首選的生產型（可用於工程部署）通道層，是部署在Heroku上顯而易見的選擇。 當然也有一些駐留內存和基於數據的通道層，但是它們更適合於本地開發或者低流量情況下使用。 （更多細節，再次請查看 文檔。）
但是首先：因為Redis通道層是在另外的包中實現的，我們需要運行pip安裝 asgi_redis。（我將會在下面稍微介紹點“ASGI”。）然后我們在CHANNEL_LAYERS配置中定義通道層：
|
1
2
3
4
5
6
7
8
9
|
CHANNEL_LAYERS
=
{
"default"
: {
"BACKEND"
:
"asgi_redis.RedisChannelLayer"
,
"CONFIG"
: {
"hosts"
: [os.environ.get(
'REDIS_URL'
,
'redis://localhost:6379'
)],
},
"ROUTING"
:
"chat.routing.channel_routing"
,
},
}
|
要注意的是我們把Redis的連接URL放到環境外面，以適應部署到Heroku的情況。
3. 通道路由
在通道層（CHANNEL_LAYERS），我們已經告訴 Channel去哪里找通道路由——chat.routing.channel_routing。通道路由很類似與URL路由的概念：URL路由將URL映射到視圖函數；通道路由將通道映射到消費者函數。跟 urls.py類似，按照慣例通道路由應該在routing.py里。現在，我們創建一條空路由：
|
1
|
channel_routing = {}
|
(我們將在后面看到好幾條通道路由信息，當連接WebSocket的時候回用到。)
你會注意到我們的app里有urls.py和routing.py兩個文件：我們使用同一個app處理HTTP請求和WebSockets。這是很典型的做法：Channels應用也是Django應用，所以你想用的所有Django的特性——視圖，表單，模型等等——都可以在Channels應用里使用。
4. 運行
最后，我們需要替換掉Django的基於HTTP/WSGI的請求處理器，而是使用通道。它是一個基於新興標准ASGI（異步服務器網關接口）的, 所以我們將在asgi.py文件里定義處理器：
|
1
2
3
4
5
|
import
os
import
channels.asgi
os.environ.setdefault(
"DJANGO_SETTINGS_MODULE"
,
"chat.settings"
)
channel_layer
=
channels.asgi.get_channel_layer()
|
(將來，Django會自動生成這個文件，就像現在自動生成wsgi.py文件一樣。)
現在，如果一切順利的話，我們應該能在通道上把這個app運行起來。Channels接口服務叫做Daphne，我們可以運行如下命令運行這個app：
|
1
|
$ daphne chat.asgi:channel_layer
-
-
port
8888
|
** 如果現在訪問http://localhost:8888/ 我們會看到……什么事情也沒發生。這很讓人困惑，直到你想起Channels將 Django分成了兩部分：前台接口服務 Daphne，后台消息消費者。所以想要處理HTTP 請求，我們得運行一個worker：
|
1
|
$ python manage.py runworker
|
現在請求應該能傳遞過去了。這說明了其中的機制很簡潔：Channels 繼續處理 HTTP(S)請求，但是是以一個完全不同的方式去處理，這與通過Django運行 Celery 沒有太大的不同，那種情況下運行WSGI服務的同時也要運行Celery服務。不過現在，所有的任務——HTTP請求， WebSockets，后台服務都在worker中運行起來了.
（順便說一句，我們仍然可以通過運行Python manage.py runserver命令來做本地測試。當這么做時， Channels只是在同一進程里運行起Daphne和一個worker。）
WebSocket消費者
好了，我們已經完成了安裝；讓我們開始進入最奇妙的部分吧。
Channels 將WebSocket連接映射到三個通道中:
-
一個新的客戶端 （如瀏覽器）第一次通過WebSocket連接上時，一條消息被發送到 websocket.connect 通道。當這發生時，我們記錄這個客戶端當前進入一個已知的聊天室。
-
每條客戶端通過已建立的socket發送的消息都被發送到 websocket.receive通道。（這些都是從瀏覽器接收到的消息；記住通道都是單向的。我們等一會兒會介紹如何將消息發送給客戶端。）當一條消息被接受時，我們將對聊天室里所有其他客戶端進行廣播。
-
最后，當客戶端斷開連接時，一條消息被發送到websocket.disconnect通道。當這發生時，我們將此客戶端從聊天室里移除。
首先，我們得在routing.py文件里對這個三個通道進行hook:
|
1
2
3
4
5
6
7
|
from
.
import
consumers
channel_routing
=
{
'websocket.connect'
: consumers.ws_connect,
'websocket.receive'
: consumers.ws_receive,
'websocket.disconnect'
: consumers.ws_disconnect,
}
|
其實很簡單：就是將每個通道連接到對應的處理函數。現在我們來看看這些函數。按照慣例我們會將這些函數放到一個 consumers.py 文件里（但是像視圖一樣，其實也可以放在任何地方）。
首先來看看 ws_connect：
|
1
2
3
4
5
6
7
8
9
10
|
from
channels
import
Group
from
channels.sessions
import
channel_session
from
.models
import
Room
@channel_session
def
ws_connect(message):
prefix, label
=
message[
'path'
].strip(
'/'
).split(
'/'
)
room
=
Room.objects.get(label
=
label)
Group(
'chat-'
+
label).add(message.reply_channel)
message.channel_session[
'room'
]
=
room.label
|
（為了清晰起見，我將代碼中的異常處理和日志去掉了。要看完整版本，請看GitHub上的consumers.py）。
|
這里代碼很多，讓我們一行行來看： 7. 客戶端將會連接到一個/chat/{label}/形式的WebSocket，label映射的是一個房間的屬性。因為所有的WebSocket消息（不考慮URL）客戶端都可以在相同的頻道里發送和獲取消息，我們要在哪個房間工作，通過路徑解析就可以。 客戶端解析WebSocket路徑是通過讀取message['path']獲得的，這不同於傳統的URL路由，Django的urls.py的路由是基於path的。如果你有多個WebSocket URL，你會需要路由到你自己定制的不同函數。（這是一個“早期”頻道方面的內容；很可能在未來的版本里Channel將會包含在WebSocket URL 路由中。） 8. 現在，我們可以從數據庫中查看Room對象了。 |
9. 這條線是使聊天功能能工作的關鍵。我們需要知道如何把消息發送回這個客戶端。要做到這點，我們將使用消息的應答通道——每條消息都會有一個應答通道屬性（reply_channelattribute），可以用來把消息發送回這個客戶端。（我們不需要去自己創建這個通道；Channels已經創建好了。）
然而，只把消息發送到這一個通道還是遠遠不夠的的；當一個用戶聊天時，我們想把消息送給每一個連接到此聊天室的用戶。要做到這點，我們使用一個通道組（channel group）。一個組是由多個通道連接而成，你可以用他來廣播消息。所以，我們將這個消息的應答通道加入到這個聊天室的特殊通道組中。
10. 最后，后續的消息（接收/斷開）不再包含這個URL（因為連接已經激活）。所以，我們需要一種方式來把一個WebSocket連接映射到哪個聊天室記錄下來。要做到這點，我們可以使用一個通道會話。通道會話很像 Django的會話框架： 它們通過通道消息的屬性message.channel_session把這些信息持久化下來。我們給一個消費者添加修飾屬性 @channel_session，就可以讓會話框架起效。 （文檔見 通道會話如何工作的更多細節）。
現在一個客戶端已經連接上來了，讓我們看看ws_receive。WebSocket上每接收一條消息，這個消費者都會被調用：
|
1
2
3
4
5
6
7
|
@channel_session
def
ws_receive(message):
label
=
message.channel_session[
'room'
]
room
=
Room.objects.get(label
=
label)
data
=
json.loads(message[
'text'
])
m
=
room.messages.create(handle
=
data[
'handle'
], message
=
data[
'message'
])
Group(
'chat-'
+
label).send({
'text'
: json.dumps(m.as_dict())})
|
（再一次說明，為了清晰起見，我把錯誤處理和日志都去掉了。）
最初的幾行很簡單：從 channel_session中解析出聊天室，在數據庫中查找出來該聊天室，解析JSON消息，將消息作為Message對象存放在數據庫中。然后，我們所要作的就是將這條消息廣播給聊天室里所有的成員，為了做到這點我們可以使用和前面一樣的通道組。Group.send()將會把這條信息發送到加入到本組的所有reply_channel。
然后， ws_disconnect就很簡單了：
|
1
2
3
4
|
@channel_session
def
ws_disconnect(message):
label
=
message.channel_session[
'room'
]
Group(
'chat-'
+
label).discard(message.reply_channel)
|
這里，在從channel session里查找到聊天室后，我們從聊天組里斷開了reply_channel，就是這樣！
部署和擴展
現在我們已經把 WebSockets連接起來並開始工作，我們可以像上面一樣運行daphne和worker進行測試，或者運行manage.py runserver)。但是和自己聊天是很寂寞的哦，所以讓我們在Heroku上把它跑起來！
大部分情況下， 一個 Channels 應用和一個python應用在Heroku上都是一樣的——在requirements.txt中有詳細需求, 在runtime.txt定義Python運行事，通過標准的Git推送到heroku上進行部署，等等。 （對於一個新手，請看 在Heroku上開始Python開發教程。） 我將重點突出那些Channel應用和標准Django應用不一樣的地方：
1. Procfile 和處理類型
因為Channels應用同時需要 HTTP/WebSocket 服務和一個后台通道消費者， 所以Procfile需要定義這兩種類型。下面是我們的Procfile:
|
1
2
|
web: daphne chat.asgi:channel_layer --port $PORT --bind 0.0.0.0 -v2
worker: python manage.py runworker -v2
|
當我們首次部署，我們需要確認兩種處理類型都在運行中（Heroku默認值啟動web進程）：
|
1
|
$ heroku
ps
:scale web=1:
free
worker=1:
free
|
（一個簡單的應用將運行在 Heroku的免費或者愛好者層上，不過在實際使用環境中你可能需要升級到產品級來提高吞吐量。）
2. 插件： Postgres和Redis
就像Django的大多數應用，你需要一個數據庫， Heroku的Postgres可以完美的滿足要求。然而，Channels也需要一個 Redis實例作為通道層。所以，我們在首次部署我們的應用時需要創建一個 Heroku Postgres和一個 Heroku Redis：
$ heroku addons:create heroku-postgresql $ heroku addons:create heroku-redis
3. 擴展
因為Channels實在是太新了，擴展性問題還不是很了解。然而，基於現在的架構和我早前做的一些性能測試，我可以做出一些預測。關鍵點在於Channels 把負責連接的處理進程（daphne）和負責通道消息處理的處理進程（runworker）分開了。這意味着：
-
通道的吞吐量——HTTP請求， WebSocket消息，或者自定義的通道消息——取決於工作者進程的數量。所以，如果你需要處理大量的請求，你可以擴展工作者進程 （比如，heroku上 ps:scale worker=3）。
-
並發水平——當前打開的連接數——將受限於前端web進程的規模。所以，如果你需要處理大量並發的WebSocket連接，你得擴展web進程（比如， heroku 上ps:scale worker=2）。
基於我前期做的測試工作， 在一個Standard-1X進程內Daphne是非常適合處理成百的並發連接的。所以我估計很少有場景需要擴展這個web進程。一個Channels應用中的工作者進程的個數與一個老風格Django應用所需的web進程個數是相當的。
接下來要做些什么呢?對WebSocket的支持是Django的一項很大的新特性，但是這只粗淺介紹了Channels可以做些什么。你要記住：Channels是一個運行后台任務的通用工具。因此，很多過去需要 Celery 或者 Python-RQ 才能做得事情，都可以用Channels替換。 Channels無法完全替換復雜的任務隊列：他有些很重要的限制，比如只發一次，這並不適合所有的場景。 查看文檔以了解全部細節。 當然， Channels可以使通常的后台任務更加簡單。比如，你可以很容易的使用Channels完成圖像縮略圖生成，發送郵件、推文或者短信，運行耗時數據計算等等工作。 對於Channels來說：計划在 Django 1.10中包含Channels ，定於今年夏天發布。這意味着現在是一個很好的時機來嘗試一下並給出反饋：您的反饋將會推動這一重要特性的發展方向。如果你想參與進來，看看這份指導文檔向Djang貢獻代碼， 然后到 django開發者郵件列表 里分享你的反饋。 最后： 非常感謝 Andrew Godwin 在 Channels上付出的努力工作。這真是Django的一個非常激動人心的新方向，我很激動地看到它開始發展起來。 |
進一步閱讀
關於Channels的更多信息，請查看Channels文檔，其中包含很多細節和引用，包括：
-
Channels的FAQs答案。
-
將Channels整合進Django的計划。
-
正式的 異步網管接口說明 （如果你真的想要了解所有技術細節！）
關於在 Heroku上使用Python 的信息，請訪問Python on Heroku in Dev Center。我推薦其中的幾篇特別好的文章：