上周五同事分享了design patterns in networks，里面很多patterns都是做路由器防火墻這樣的轉發(fā)設備之所以高效的精髓所在?！赋绦蛉松沟淖x者多為互聯(lián)網(wǎng)應用（系統(tǒng)）開發(fā)者，對這些design patterns未必了解，所以這篇文章我干脆抽取同事分享內容和互聯(lián)網(wǎng)系統(tǒng)開發(fā)關聯(lián)較大的patterns，講講在互聯(lián)網(wǎng)項目上的應用場景，借花獻佛。

Control plane和data plane分離

這兩個概念幾乎是networks 101的入門概念。Juniper上世紀末興起的重要原因之一就是嚴格區(qū)分界定control plane和data plane，然后用ASIC實現(xiàn)data plane。Data plane是指一個網(wǎng)絡設備用于報文轉發(fā)的component，它的效率決定整個設備的效率，一般會由硬件完成。Control plane是指一個設備協(xié)議相關的部分，可以沒有數(shù)據(jù)轉發(fā)那么高效。

當你打開瀏覽器訪問google時，internet上面的網(wǎng)絡設備就開始緊鑼密鼓地工作，目的只有一個，把你的請求轉發(fā)到google的服務器。學過網(wǎng)絡課程的人都知道，這其中運行的網(wǎng)絡設備就是路由器。路由器需要有足夠快的轉發(fā)速度，延時越小越好 —— 這考量的是data plane的效率；而data plane轉發(fā)決策的依據(jù) —— 路由，則由control plane的協(xié)議處理來完成。

在一個互聯(lián)網(wǎng)系統(tǒng)上，似乎沒有control plane和data plane較為清晰的界定。我們不妨粗暴地認為用戶訪問的路徑為data plane，而admin相關的路徑為control plane。對于data plane上的工作，我們可以單獨劃分一個集群來處理，力求每個request都得到高效地處理，而control plane上的工作，則可以盡可能用比較小的資源完成。這里最重要的原則是：data plane和control plane做到路徑分離，讓data plane上的大量requests不致于影響control plane的正常工作；同時control plane上的慢速任務不致于拖累data plane的訪問速度。

First path vs Fast path

做防火墻，少不了會遇到first path和fast path的概念。防火墻處理的是雙向的數(shù)據(jù)流，需要記錄狀態(tài)，所以有session的概念。在first path里面，走一個慢速的全路徑，創(chuàng)建session，在fast path里面，則可以利用session里面的各種信息快速處理數(shù)據(jù)報文。

在互聯(lián)網(wǎng)系統(tǒng)上，類似的mapping很好建立。在一個需要用戶登錄的系統(tǒng)里，用戶登錄的整個過程可以被視作first path，隨后的訪問可以被視作fast path。

用戶登錄是一個復雜的過程，不僅僅是驗證用戶合法性這么簡單。在前臺盡快給出用戶登錄后頁面的同時（responsiveness很重要），后臺需要加載一系列用戶相關的數(shù)據(jù)到緩存（比如redis）中，以便用戶在隨后的訪問中能夠快速獲取。加載的數(shù)據(jù)可以是用戶的朋友信息，用戶可能會訪問的熱點數(shù)據(jù)，各種各樣的counters等等。

當然，first path/fast path的概念不僅僅適用于登錄和登錄后的訪問，還有很多其它的應用場景。比如說一個規(guī)則系統(tǒng)，首次訪問時從規(guī)則引擎中抽取用戶相關的規(guī)則進行編譯和緩存，之后的訪問則直接從編譯好的規(guī)則緩存中高效讀取。

注意first path/fast path的概念是相對的，就像分形幾何一樣，first path里面可以再區(qū)分中first path/fast path，fast path里也可以再區(qū)分出first path/fast path，不斷迭代下去。這樣做的目的是，不斷地優(yōu)化系統(tǒng)中最常用的80%的路徑，讓它們的效率大化。

Slow path vs Fast path

Slow path/fast path和first path/fast path很類似，但又不盡相同。就用戶登錄而言，我們假定（或者有實際數(shù)據(jù)）80%的用戶通過用戶名/密碼登錄，那么用戶名/密碼登錄就要置于fast path下，而其它的諸如LDAP，OpenID，XAuth登錄方式置于slow path下。

這樣區(qū)分fast path/slow path的好處是，一旦有需要，我們可以把對應的代碼用更高效的方式實現(xiàn)，比如說整個系統(tǒng)是python實現(xiàn)的，系統(tǒng)中的一些fast path處在用戶訪問的熱點區(qū)域，那么可以考慮用go來實現(xiàn)。

Queue based design

在網(wǎng)絡設備中，queue無處不在，幾乎成了最基本的操作。一個數(shù)據(jù)報文從硬件上來之后被放到了driver的queue上，然后在系統(tǒng)處理的各個層級，不斷地被enqueue/dequeue。Queue有很多好處，比如說延遲處理，優(yōu)先級，流量整形（traffic shaping）。

一個復雜的互聯(lián)網(wǎng)系統(tǒng)很多時候也需要queue來控制任務處理的節(jié)奏。比如說email驗證這樣的事情，可以不必在當前的request里完成，而放到message queue中，由后臺的worker來處理。另外，queue可以有不同的優(yōu)先級，發(fā)送email和將圖片轉換成不同的size顯然可以放入不同的優(yōu)先級隊列中調度。

對于互聯(lián)網(wǎng)項目而言，有很多成熟的message queue system，比如RabbitMQ，ZeroMQ。

Pipeline

在網(wǎng)絡系統(tǒng)里面，如果一個任務很復雜，需要很多CPU時間，那么該任務可以分解成多個小任務來執(zhí)行，否則的話，這個任務占用CPU時間過長，導致其他任務無法執(zhí)行。當一個任務分解成多個小任務后，每個小任務之間由queue連接，上一次處理完成之后，放入下一個queue。這樣可以任務調度更均衡。

在互聯(lián)網(wǎng)項目中，pipeline有很多應用場合。比如說一個workflow里面狀態(tài)機的改變，可能會執(zhí)行一系列的操作，然后最終遷移到新的狀態(tài)。如果這一系列的操作在一個大的function里執(zhí)行，而非分解成若干個通過queue相連的小操作，那么整個處理過程中的慢速操作會影響整個系統(tǒng)的吞吐量。而且，這樣做非常不利于concurrency。

在一個大型系統(tǒng)中，pipeline的程度決定了concurrency的程度。而pipeline的應用程度會影響整個系統(tǒng)架構的吞吐量。有些編程語言，如golang，天然就讓你的思維模式往pipeline的方式去轉（通過go/chan）。

Finite State Machine

既然提到了狀態(tài)機，就講講狀態(tài)機。狀態(tài)機由兩個元素組成：狀態(tài)；以及狀態(tài)遷移。狀態(tài)遷移是由動作引起的，因此一個狀態(tài)機可以表示為 state machine = {state, event} -> (action, new state)。只要畫出一個二維表，就能分析系統(tǒng)所有可能的路徑，而且很難有遺漏。在網(wǎng)絡設備中，大部分協(xié)議都由狀態(tài)機來表述，比如說ospf，igmp，tcp等等。

在互聯(lián)網(wǎng)項目中，狀態(tài)機無處不在。比如說訂單處理。一個訂單的處理流程用狀態(tài)機表述再好不過。下面是我曾經(jīng)寫過的一段示例代碼（python）：

ORDER_EVENTS = {
  (const.ORDER_EVENT_PAYED, const.ORDER_STATE_CREATED): {
    'new_state': const.ORDER_STATE_PAYED,
    'callback': on_order_event_payed,
  },
  (const.ORDER_EVENT_PAY_EXPIRED, const.ORDER_STATE_CREATED): {
    'new_state': const.ORDER_STATE_CANCELLED,
    'callback': on_order_event_cancelled,
  },
  (const.ORDER_EVENT_CONFIRMED, const.ORDER_STATE_PAYED): {
    'new_state': const.ORDER_STATE_CLOSED,
    'callback': on_order_event_confirmed,
  },
  (const.ORDER_EVENT_CONFIRM_EXPIRED, const.ORDER_STATE_PAYED): {
    'new_state': const.ORDER_STATE_CLOSED,
    'callback': on_order_event_confirm_expired,
  },
  ...
}

本文名稱：系統(tǒng)開發(fā)之設計模式
標題路徑：http://jinyejixie.com/news20/43320.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信小程序、網(wǎng)站排名、營銷型網(wǎng)站建設、小程序開發(fā)、網(wǎng)站營銷、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)