實時 Django 終於來了 —— Django Channels 入門指南

今天，我們很高興請到Jacob Kaplan-Moss。Jacob是來自Herokai，也是 Django的長期的核心代碼貢獻者，他將在這里分享一些他對某些特性的深入研究，他認為這些特性將重新定義框架未來。

當Django剛創建時，那是十多年前，網絡還是一個不太復雜的地方。大部分的網頁都是靜態的。由數據庫支撐的模型/視圖/ 控制器架構的網絡應用還是很新鮮的東西。Ajax剛剛開始被使用，只在較少的場景中。

到現在2016年，網絡明顯更加強大。過去的幾年里已經看到了所謂的“實時”網絡應用：在這類應用中客戶端和服務器之間、點對點通信交互非常頻繁。包含很多服務（又名微服務）的應用也變成是常態。新的web技術允許web應用程序走向十年前我們只敢在夢里想象的方向。這些核心技術之一就是WebSockets：一種新的提供全雙工通信的協議——一個持久的，允許任何時間發送數據的客戶端和服務器之間的連接。

雪落無痕xdj
翻譯於 4個月前

2人頂

頂翻譯的不錯哦!

在這個新的世界，Django顯示出了它的老成。在其核心，Django是建立在請求和響應的簡單概念之上的：瀏覽器發出請求，Django調用一個視圖，它返回一個響應並發送回瀏覽器。

這在WebSockets中是行不通的！視圖的生命周期只在一個請求當中，沒有一種機制能打開一個連接不斷的發送數據到客戶端，而不發送相關請求。

因此：Django Channels就應運而生了。Channels,簡而言之,取代了Django中的“guts” ——請求/響應周期發送跨通道的消息。Channels允許Django以非常類似於傳統HTTP的方式支持WebSockets。Channels也允許在運行Django的服務器上運行后台任務。HTTP請求表現以前一樣,但也通過Channels進行路由。因此,在Channels 支持下Django現在看起來像這樣:

雪落無痕xdj
翻譯於 4個月前

2人頂

頂翻譯的不錯哦!

如您所見，Django Channels引入了一些新的概念:

Channels基本上就是任務隊列：消息被生產商推到通道，然后傳遞給監聽通道的消費者之一。如果你使用Go語言中的渠道,這個概念應該相當熟悉。主要的區別在於，Django Channels通過網絡工作，使生產者和消費者透明地運行在多台機器上。這個網絡層稱為通道層。通道設計時使用Redis作為其首選通道層，雖然也支持其他類型(和API來創建自定義通道層)。有很多整潔和微妙的技術細節，查閱文檔可以看到完整的記錄。

現在，通道作為一個獨立的應用程序搭配使用Django 1.9使用。計划是將通道合並到Django1.10版本，今年夏天將會發布。

我認為Channels將是Django的一個非常重要的插件：它們將支撐Django順利進入這個新的web開發的時代。雖然這些api還沒有成為Django的一部分，他們將很快就會是！所以，現在是一個完美的時間開始學習Channels：你可以了解未來的Django。

雪落無痕xdj
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

開始實踐：如何在Django中實現一個實時聊天應用

作為一個例子，我構建了一個簡單的實時聊天應用程序——就像一個非常非常輕量級的Slack。有很多的房間,每個人都在同一個房間里可以聊天,彼此實時交互（使用WebSockets）。

你可以訪問我在網絡上部署的例子，看看在GitHub上的代碼，或點擊這個按鈕來部署自己的。（這需要一個免費的Heroku賬戶，所以得要先注冊）：

注意:你需要在點擊上面的按鈕后，啟動工作進程。使用儀表盤或運行heroku ps:scale web=1:free worker=1:free。

如果你想深入了解這個應用程序是如何工作的——包括你為什么需要worker！——那么請繼續讀下去。我將會一步一步來構建這個應用程序，並突出關鍵位置和概念。

雪落無痕xdj
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

第一步——從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。）

然后創建一個聊天室視圖以及相應的urls.py和模板：

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。

雪落無痕xdj
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

接下來我們做什么

為了搞明白接下來后台需要做些什么，我們得先看下客戶端的代碼。你可以在 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。

雪落無痕xdj
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

安裝和創建 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的情況。

雪落無痕xdj
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

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應用里使用。

雪落無痕xdj
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

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。）

雪落無痕xdj
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

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）。

雪落無痕xdj
翻譯於 4個月前

3人頂

頂翻譯的不錯哦!

這里代碼很多，讓我們一行行來看：

7. 客戶端將會連接到一個/chat/{label}/形式的WebSocket，label映射的是一個房間的屬性。因為所有的WebSocket消息（不考慮URL）客戶端都可以在相同的頻道里發送和獲取消息，我們要在哪個房間工作，通過路徑解析就可以。

客戶端解析WebSocket路徑是通過讀取message['path']獲得的，這不同於傳統的URL路由，Django的urls.py的路由是基於path的。如果你有多個WebSocket URL，你會需要路由到你自己定制的不同函數。（這是一個“早期”頻道方面的內容；很可能在未來的版本里Channel將會包含在WebSocket URL 路由中。）

8. 現在，我們可以從數據庫中查看Room對象了。

無若
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

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())}) 
                     

（再一次說明，為了清晰起見，我把錯誤處理和日志都去掉了。）

雪落無痕xdj
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

最初的幾行很簡單：從 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，就是這樣！

雪落無痕xdj
翻譯於 4個月前

2人頂

頂翻譯的不錯哦!

部署和擴展

現在我們已經把 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的免費或者愛好者層上，不過在實際使用環境中你可能需要升級到產品級來提高吞吐量。）

雪落無痕xdj
翻譯於 4個月前

2人頂

頂翻譯的不錯哦!

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進程個數是相當的。

雪落無痕xdj
翻譯於 4個月前

1人頂

頂翻譯的不錯哦!

接下來要做些什么呢?

對WebSocket的支持是Django的一項很大的新特性，但是這只粗淺介紹了Channels可以做些什么。你要記住：Channels是一個運行后台任務的通用工具。因此，很多過去需要 Celery 或者 Python-RQ 才能做得事情，都可以用Channels替換。 Channels無法完全替換復雜的任務隊列：他有些很重要的限制，比如只發一次，這並不適合所有的場景。查看文檔以了解全部細節。當然， Channels可以使通常的后台任務更加簡單。比如，你可以很容易的使用Channels完成圖像縮略圖生成，發送郵件、推文或者短信，運行耗時數據計算等等工作。

對於Channels來說：計划在 Django 1.10中包含Channels ，定於今年夏天發布。這意味着現在是一個很好的時機來嘗試一下並給出反饋：您的反饋將會推動這一重要特性的發展方向。如果你想參與進來，看看這份指導文檔向Djang貢獻代碼，然后到 django開發者郵件列表里分享你的反饋。

最后：非常感謝 Andrew Godwin 在 Channels上付出的努力工作。這真是Django的一個非常激動人心的新方向，我很激動地看到它開始發展起來。

雪落無痕xdj
翻譯於 4個月前

2人頂

頂翻譯的不錯哦!

進一步閱讀

關於Channels的更多信息，請查看Channels文檔，其中包含很多細節和引用，包括：

Channels的FAQs答案。
將Channels整合進Django的計划。
正式的異步網管接口說明（如果你真的想要了解所有技術細節！）

關於在 Heroku上使用Python 的信息，請訪問Python on Heroku in Dev Center。我推薦其中的幾篇特別好的文章：