免费观看又色又爽又黄的小说免费_美女福利视频国产片_亚洲欧美精品_美国一级大黄大色毛片

系統開發之設計模式

2016-08-27    分類： 網站建設

上周五同事分享了design patterns in networks，里面很多patterns都是做路由器防火墻這樣的轉發設備之所以高效的精髓所在。「程序人生」的讀者多為互聯網應用（系統）開發者，對這些design patterns未必了解，所以這篇文章我干脆抽取同事分享內容和互聯網系統開發關聯較大的patterns，講講在互聯網項目上的應用場景，借花獻佛。

Control plane和data plane分離

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

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

在一個互聯網系統上，似乎沒有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的概念。防火墻處理的是雙向的數據流，需要記錄狀態，所以有session的概念。在first path里面，走一個慢速的全路徑，創建session，在fast path里面，則可以利用session里面的各種信息快速處理數據報文。

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

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

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

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

Slow path vs Fast path

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

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

Queue based design

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

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

對于互聯網項目而言，有很多成熟的message queue system，比如RabbitMQ，ZeroMQ。

Pipeline

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

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

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

Finite State Machine

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

在互聯網項目中，狀態機無處不在。比如說訂單處理。一個訂單的處理流程用狀態機表述再好不過。下面是我曾經寫過的一段示例代碼（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,
  },
  ...
}

當前文章：系統開發之設計模式
瀏覽地址：http://m.newbst.com/news/43320.html

成都網站建設公司_創新互聯，為您提供網站收錄、企業建站、標簽優化、軟件開發、網站制作、網站內鏈

廣告

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

外貿網站建設