一、即時通信

- AJAX技術：通過AJAX實現網頁與服務器的無刷新交互，在網頁上每隔一段時間就通過AJAX從服務器中獲取數據。然后將數據更新并顯示在網頁上，這種方法簡單明了，實時性不高。

- Comet(Pushlet)技術：Comet是一種Web應用架構，服務器以異步方式向瀏覽器推送數據，無須瀏覽器發送請求。Comet架構非常適合事件驅動的Web應用，以及對交互性和實時性要求較高的應用，如股票交易行情分析、聊天室和Web版在線游戲等。

- XMPP協議：XMPP（可擴展消息處理現場協議）基于XML的協議，是專為即時通信系統設計的通信協議。用于即時消息以及在線現場探測，這個協議允許用戶向其他用戶發送即時消息。

- Flash的XmlSocket：Flash Media Server是一個強大的流媒體服務器，基于RTMP協議，提供了穩定的流媒體交互功能。內置遠程共享對象（shared  object）的機制。是瀏覽器創建并連接服務器的遠程共享對象。。

- WebSocket協議：WebSocket是通過單個TCP連接提供全雙工（雙向通信）通信信道的計算機通信協議，可在瀏覽器和服務器之間進行雙向通信，允許多個用戶連接到同一個服務器，并通過API進行通信并立即獲得響應。WebSocket不僅限于聊天/消息傳遞應用程序，還適用于實時更新和即時消息交換的應用程序。比如現場體育更新、股票行情、多人游戲、聊天應用、社交媒體等。

二、前后端分離與微服務架構

• vue：一套用于構建用戶界面的漸進式框架，它被設計為可以自底向上逐層應用。Vue的核心只關注視圖層，不僅易上手，還便于與第三方庫或已有的項目整合。另一方面，當Vue與現代化的工具鏈以及各種類庫結合使用時，Vue完全能夠為復雜的單頁應用提供驅動。
• axios.js：一個HTTP庫，用于實現前端的AJAX異步請求，從Vue2.0開始，官方推薦使用axios發送AJAX異步請求。

設置跨域訪問

# Vue和Django各自部署在不同服務器，兩者的協議+域名+端口號各不相同，因此Vue的AJAX請求訪問不到Django的API。為了實現兩者之間的數據傳輸，后端服務器系統必須設置跨域訪問。可通過第三方DjangoCors Headers實現。

pip install django-cors-headers

INSTALLED_APPS = [

    ...

    'corsheaders',

]

MIDDLEWARE = [

    ...

    # 跨域訪問

    'corsheaders.middleware.CorMiddleware',

]

# 設置HTTP請求是否允許攜帶Cookies信息，默認值為False

CORS_ALLOW_CREDENTIALS = True

# 只允許白明白設置的域名列表發送HTTP請求，默認False，若設置True允許所有域名發送HTTP請求。

CORS_ORIGIN_ALLOW_ALL = True

# 設置允許發送HTTP請求的域名列表

CORS_ORIGIN_WHITELIST = ()

# 設置HTTP請求方式

CORS_ALLOW_METHODS = (

    'GET',

    'DELETE',

    'OPTIONS',

    'PATCH',

    'POST',

    'PUT',

    'VIEW',

)

# 設置非標準HTTP請求頭

CORS_ALLOW_HEADERS = (

    'XMLHttpRequest',

    'X_FILENAME',

    'accept-encoding',

    ...

)

微服務架構

微服務（Microservice Architecture）是一種架構概念，它將功能分解成不同的服務，降低系統的耦合性，提供更加靈活的服務支持，各個服務之間通過API接口進行通信。

微服務實現原理：

• 傳統的微服務使用單體式開發，即所有網頁功能在一個web應用中實現，然后在某個服務器部署上線。
• 當網站的訪問量或數據量過大時，將導致單體式系統的某個功能出現異常，整個網站也隨之癱瘓。
• 對于大型網站來說，微服務架構可以將網站功能拆分為多個不同的服務，每個服務部署在不同的服務器，每個服務之間通過API通信，從而構建網站功能。
• 服務之間的通信需要考慮服務的部署方式。比如重試機制
• 限流、熔斷機制、負載均衡和緩存機制等。保證每個服務的穩健性。
• 微服務架構一共有6種設計模式。
• （1）聚合器微服務設計模式：聚合器調用多個微服務實現應用或網頁所需功能，每個微服務有自己的緩存和數據庫，這是一種常見的、簡單的設計模式
  
  • 　　

• （2）代理微服務設計模式：是聚合微服務設計模式的演變模式，應用程序或網頁根據業務需求的差異調用不同的微服務，代理可以委派HTTP請求，也可以進行數據轉換工作

  • 　　

• （3）鏈式微服務設計模式：每個微服務之間通過鏈式方式進行調用，如微服務A接收到請求后會與B進行通信，類似地，微服務B會與微服務C進行通信，所有微服務都使用同步消息傳遞。在整個鏈式調用完成之間，瀏覽器會一直處于等待狀態（4）分支微服務設計模式：聚合器微服務設計模型的擴展模式，允許微服務之間相互調用

  • 　　

• （4）數據共享微服務設計模式：部分微服務可能會共享緩存和數據庫，即兩個或兩個以上的微服務共用一個緩存和數據庫。這種情況只有在兩個微服務之間存在強耦合關系時才能使用，對于使用微服務實現的應用程序或網頁而言，這是一種反設計模式
  • 　　
• （5）異步消息傳遞微服務設計模式：由于API接口使用同步模式，如果API接口執行的程序耗時過長，就會增加用戶的等待時間，因此某些微服務可以選擇使用消息隊列（異步請求）代替API接口的請求和響應 
  • 　　

summary：微服務設計模式不是唯一的，具體還需要根據項目需求、功能和應用場景等多方面綜合考慮。對于微服務架構，架構的設計意識比技術開發更為重要，整個架構設計需要考慮多個微服務的運維難度、系統部署依賴、微服務之間通信成本、數據一致性、系統集成測試和性能監控等。

功能拆分

功能拆分一般遵從以下原則：

1. 單一職責、高內聚低耦合
2. 服務粒度適中
3. 以業務模型切入
4. 演進式拆分
5. 避免環形依賴與雙向依賴

微服務各階段實現功能

1. 開發階段：根據微服務架構設計模式進行功能拆分，將功能拆分成多個微服務，并且統一規范設計每個微服務的API接口，每個API接口符合RESTful設計規范。如果服務之間不同服務器，就需要考慮跨域訪問。
2. 測試階段：用于驗證各個服務之間的API接口否輸入輸出是否符合開發需求，還需要驗證各個API接口之間的調用邏輯是否合理。
3. 部署階段：根據部署方案執行，部署方案需要考慮服務的重試機制、緩存機制、負載均衡和集群等部署方式。
4. 運維監控階段：需要對網站系統實時監控，監控內容包括：日志收集、事故預警、故障定位和性能跟蹤等，并且還需要根據監測結構適當調整部署方式。

部署啟動

目前部署Django項目有兩種主流方案：Nginx+uWSGI+Django或者Apache+uWSGI+Django。

• Nginx或Apache作為服務器最前端，負責接收瀏覽器所有HTTP請求并統一管理。
• 靜態資源的HTTP請求由Nginx或Apache自己處理
• 非靜態資源的HTTP請求則由Nginx或Apache傳遞給uWSGI服務器，然后傳遞給Django應用，最后由Django進行處理并做出響應，從而完成一次Web請求。

# 啟動nginx

systemctl start nginx

# 重新讀取nginx配置文件

cd /etc/nginx/

sudo nginx -c nginx.conf

sudo nginx -s reload

# 通過配置文件啟動uWSGI服務器

uwsgi --ini nusic_uwsgi.ini

總結

以上是生活随笔為你收集整理的Django Web应用开发实战第十六章的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。