大家好，我是極客重生，假期這么快就結束了，不管做什么，都要認真做好，該玩的時候就好好玩，放松休息，該學習的時候就好好學習，刻苦訓練，該工作的時候就認真工作，努力掙錢，今天我們看一看業(yè)界一些著名的編程模型。

背景

模型是對事物共性的抽象，編程模型就是對編程的共性的抽象。

什么是編程的共性呢？

最重要的共性就是：程序設計時，代碼的抽象方式、組織方式或復用方式。編程模型主要是方法與思想。編程模型處于方法或思想性的層面，在很多情況下，也可稱為編程方法、編程方式、編程模式或編程技術、編程范式。在這里就當做同一種說法。

當面對一個新問題時，通常的想法是通過分析，不斷的轉化和轉換，得到本質相同的熟悉的、或抽象的、簡單的一個問題，這就是化歸思想。把初始的問題或對象稱為原型，把化歸后的相對定型的模擬化或理想化的對象稱為模型。

編程模型，簡單地可以理解它就是模板，遇到相似問題就可以方便依模板解決,這樣就簡化了編程問題。不同的編程環(huán)境和不同的應用對象有不同的編程模型。

事件驅動

來源于《Software Architecture Patterns》

事件驅動架構（Event-Driven Architecture）是一種用于設計應用的軟件架構和模型，程序的執(zhí)行流由外部事件來決定，它的特點是包含一個事件循環(huán)，當外部事件發(fā)生時使用回調機制來觸發(fā)相應的處理。主要包括 4 個基本組件：

• 事件隊列（event queue）：接收事件的入口，存儲待處理事件

• 分發(fā)器（event mediator）：將不同的事件分發(fā)到不同的業(yè)務邏輯單元

• 事件通道（event channel）：分發(fā)器與處理器之間的聯(lián)系渠道

• 事件處理器（event processor）：實現(xiàn)業(yè)務邏輯，處理完成后會發(fā)出事件，觸發(fā)下一步操作

為什么采用事件驅動模型?

事件驅動模型也就是我們常說的觀察者，或者發(fā)布-訂閱模型；

理解它的幾個關鍵點：

• 首先是一種對象間的一對多的關系；最簡單的如交通信號燈，信號燈是目標（一方），行人注視著信號燈（多方）；

• 當目標發(fā)送改變（發(fā)布），觀察者（訂閱者）就可以接收到改變；

• 觀察者如何處理（如行人如何走，是快走/慢走/不走，目標不會管的），目標無需干涉；所以就松散耦合了它們之間的關系。

許多現(xiàn)代應用設計都是由事件驅動的，事件驅動應用可以用任何一種編程語言來創(chuàng)建，因為事件驅動本身是一種編程方法，而不是一種編程語言。

• 松耦合——服務不需要(也不應該)知道或依賴于其他服務。在使用事件時，服務獨立運行，不了解其他服務，包括其實現(xiàn)細節(jié)和傳輸協(xié)議。事件模型下的服務可以獨立地、更容易地更新、測試和部署。

• 易擴展——通過高度獨立和解耦的事件處理器自然地實現(xiàn)了可擴展性。每個事件處理器都可以單獨擴展，從而實現(xiàn)細粒度的可擴展性。

• 恢復支持——帶有隊列的事件驅動架構可以通過“重播”過去的事件來恢復丟失的工作。當用戶需要恢復時，這對于防止數據丟失非常有用。

事件驅動架構可以最大程度減少耦合度，因此是現(xiàn)代化分布式應用架構的理想之選。

深入理解事件驅動

1.異步處理和主動輪訓，要理解事件驅動和程序，就需要與非事件驅動的程序進行比較。實際上，現(xiàn)代的程序大多是事件驅動的，比如多線程的程序，肯定是事件驅動的。早期則存在許多非事件驅動的程序，這樣的程序，在需要等待某個條件觸發(fā)時，會不斷地檢查這個條件，直到條件滿足，這是很浪費cpu時間的。而事件驅動的程序，則有機會釋放cpu從而進入睡眠態(tài)（注意是有機會，當然程序也可自行決定不釋放cpu），當事件觸發(fā)時被操作系統(tǒng)喚醒，這樣就能更加有效地使用cpu。

2.IO模型，事件驅動框架一般是采用Reactor模式或者Proactor模式的IO模型。

Reactor模式其中非常重要的一環(huán)就是調用函數來完成數據拷貝，這部分是應用程序自己完成的，內核只負責通知監(jiān)控的事件到來了，所以本質上Reactor模式屬于非阻塞同步IO。

來自：深入理解Linux高性能網絡架構的那些事

Proactor模式，借助于系統(tǒng)本身的異步IO特性，由操作系統(tǒng)進行數據拷貝，在完成之后來通知應用程序來取就可以，效率更高一些，但是底層需要借助于內核的異步IO機制來實現(xiàn)，可能借助于DMA和Zero-Copy技術來實現(xiàn)，理論上性能更高。

當前Windows系統(tǒng)通過IOCP實現(xiàn)了真正的異步I/O，而在Linux 系統(tǒng)的異步I/O還不完善，比如Linux中的boost.asio模塊就是異步IO的支持，但是目前Linux系統(tǒng)還是以基于Reactor模式的非阻塞同步IO為主。

3.事件隊列，事件驅動的程序必定會直接或者間接擁有一個事件隊列，用于存儲未能及時處理的事件，這個事件隊列，可以采用消息隊列。

4.事件串聯(lián)，事件驅動的程序的行為，完全受外部輸入的事件控制，所以事件驅動框架中，存在大量處理程序邏輯，可以通過事件把各個處理流程關聯(lián)起來。

5.順序性和原子化，事件驅動的程序可以按照一定的順序處理隊列中的事件，而這個順序則是由事件的觸發(fā)順序決定的，這一特性往往被用于保證某些過程的順序性和原子化。

事件驅動的缺點

• 事件驅動架構，就是通過引入中間層 來實現(xiàn)事件發(fā)布-訂閱機制進行組件解耦，看似能帶來不少誘人的優(yōu)點，也必然會增加系統(tǒng)的復雜度，間接增加開發(fā)難度和維護難度。

• 事件驅動架構改變了編程思維，將完整的功能過程，拆解為了不同的異步事件處理，也喪失了連貫的流程處理能力。如果事件數量眾多，就容易在“事件叢林”中迷了路，比如中斷風暴，驚群效應等。

常用的事件驅動框架

• select

• poll

• epoll

• libev

• 中斷系統(tǒng)

消息驅動

消息驅動和事件驅動很類似，都是先有一個事件，然后產生一個相應的消息，再把消息放入消息隊列，由需要的項目獲取。他們只是一些細微區(qū)別，一般都采用相同框架，細微的區(qū)別：

消息驅動：生產者A發(fā)送一個消息到消息隊列，消費者B收到該消息。生產者A很明確這個消息是發(fā)給消費者B的。通常是P2P模式。

事件驅動：生產者A發(fā)出一個事件，消費者B或者消費者C收到這個事件，或者沒人收到這個事件，生產者A只會產生一個事件，不關心誰會處理這個事件?，通常是發(fā)布-訂閱模型。

現(xiàn)代軟件系統(tǒng)是跨多個端點運行并通過大型網絡連接的分布式系統(tǒng)。例如，考慮一位航空公司客戶通過 Web 瀏覽器購買機票。該訂單可能會通過API，然后通過一系列返回結果的過程。這些來回通信的一個術語是消息傳遞。在消息驅動架構中，這些 API 調用看起來非常像一個函數調用：API 知道它在調用什么，期待某個結果并等待該結果。

消息驅動的優(yōu)點

• 開發(fā)難度低：消息驅動類似經典的編程模型，調用一個函數，等待一個結果，對結果做一些事情，編程簡單快速，開發(fā)難度低。

• 方便調試維護：因為編程邏輯清晰簡單，流程清晰，調試起來更加直接方便，后期維護也容易。

常用的消息驅動框架

• API網關

• gRPC

• 微服務架構

事件驅動vs消息驅動

消息驅動的方法與事件驅動的方法一樣有很多優(yōu)點和缺點，但每種方法都有自己最適合的情況。

消息感覺很像經典的編程模型：調用一個函數，等待一個結果，對結果做一些事情。除了為大多數程序員所熟悉之外，這種結構還可以使調試更加直接。另一個優(yōu)點是消息“阻塞”，這意味著呼叫和響應的各個單元坐下來等待輪到接收者進行處理。

事件驅動系統(tǒng)使單個事件易于隔離測試。然而，這種與整個應用系統(tǒng)的分離也抑制了這些單元報告錯誤、重試調用程序甚至只是向用戶確認進程已完成的能力。換句話說：當事件驅動系統(tǒng)中發(fā)生錯誤時，很難追蹤到底是哪里出了問題。可觀察性工具正在應對調試復雜事件鏈的挑戰(zhàn)。但是，添加到業(yè)務交易交叉點的每個工具都會為負責管理這些工作流的程序員帶來另一層復雜性。

如果通信通常以一對一的方式進行，并且優(yōu)先接收定期狀態(tài)更新或確認，那么您將傾向于使用基于消息的方法。但是，如果系統(tǒng)之間的交互特別復雜，并且確認和狀態(tài)更新導致的延遲使得等待它們變得不切實際，那么事件驅動的設計可能更合適。但是請記住，大多數大型組織最終會采用混合策略，一些面向客戶/API 調用使用消息驅動，而企業(yè)本身使用事件驅動。因此，盡可能多地熟悉兩者并沒有什么壞處。

數據驅動

數據驅動核心出發(fā)點是相對于程序邏輯，人類更擅長于處理數據。數據比程序邏輯更容易駕馭，所以我們應該盡可能的將設計的復雜度從程序代碼轉移至數據。

例子

假設有一個程序，需要處理其他程序發(fā)送的消息，消息類型是字符串，每個消息都需要一個函數進行處理。第一印象，我們可能會這樣處理：

上面的消息類型取自sip協(xié)議（不完全相同，sip協(xié)議借鑒了http協(xié)議），消息類型可能還會增加。看著常常的流程可能有點累，檢測一下中間某個消息有沒有處理也比較費勁，而且，每增加一個消息，就要增加一個流程分支。

按照數據驅動編程的思路，可能會這樣設計：

下面這種思路的優(yōu)勢：

1、可讀性更強，消息處理流程一目了然。

2、更容易修改，要增加新的消息，只要修改數據即可，不需要修改流程。

3、重用，第一種方案的很多的else if其實只是消息類型和處理函數不同，但是邏輯是一樣的。下面的這種方案就是將這種相同的邏輯提取出來，而把容易發(fā)生變化的部分提到外面。

隱含在背后的思想

很多設計思路背后的原理其實都是相通的，隱含在數據驅動編程背后的實現(xiàn)思想包括：

1、控制復雜度。通過把程序邏輯的復雜度轉移到人類更容易處理的數據中來，從而達到控制復雜度的目標。

2、隔離變化。像上面的例子，每個消息處理的邏輯是不變的，但是消息可能是變化的，那就把容易變化的消息和不容易變化的邏輯分離。

3、機制和策略的分離。和第二點很像，本書中很多地方提到了機制和策略。上例中，我的理解，機制就是消息的處理邏輯，策略就是不同的消息處理：

深入理解編程藝術之策略與機制相分離

數據驅動編程可以用來做什么

表驅動法(Table-Driven)

消除重復代碼，考慮一個消息（事件）驅動的系統(tǒng)，系統(tǒng)的某一模塊需要和其他的幾個模塊進行通信。它收到消息后，需要根據消息的發(fā)送方，消息的類型，自身的狀態(tài)，進行不同的處理。比較常見的一個做法是用三個級聯(lián)的switch分支實現(xiàn)通過硬編碼來實現(xiàn)：

switch(sendMode) { case: } switch(msgEvent) { case: } switch(myStatus) { case: }

這種方法的缺點：

• 可讀性不高：找一個消息的處理部分代碼需要跳轉多層代碼。

• 過多的switch分支，這其實也是一種重復代碼。他們都有共同的特性，還? ?可以再進一步進行提煉。

• 可擴展性差：如果為程序增加一種新的模塊的狀態(tài)，這可能要改變所有的? 消息處理的函數，非常的不方便，而且過程容易出錯。

• 程序缺少核心主干：缺少一個能夠提綱挈領的主干，程序的主干被淹沒在? ? 大量的代碼邏輯之中。

用表驅動法來實現(xiàn)

根據定義的三個枚舉：模塊類型，消息類型，自身模塊狀態(tài)，定義一個函數跳轉表：

typedef struct __EVENT_DRIVE {MODE_TYPE mod;//消息的發(fā)送模塊EVENT_TYPE event;//消息類型STATUS_TYPE status;//自身狀態(tài)EVENT_FUN eventfun;//此狀態(tài)下的處理函數指針 }EVENT_DRIVE;EVENT_DRIVE eventdriver[] = //這就是一張表的定義，不一定是數據庫中的表。也可以使自己定義的一個結構體數組。 {{MODE_A, EVENT_a, STATUS_1, fun1}{MODE_A, EVENT_a, STATUS_2, fun2}{MODE_A, EVENT_a, STATUS_3, fun3}{MODE_A, EVENT_b, STATUS_1, fun4}{MODE_A, EVENT_b, STATUS_2, fun5}{MODE_B, EVENT_a, STATUS_1, fun6}{MODE_B, EVENT_a, STATUS_2, fun7}{MODE_B, EVENT_a, STATUS_3, fun8}{MODE_B, EVENT_b, STATUS_1, fun9}{MODE_B, EVENT_b, STATUS_2, fun10} };int driversize = sizeof(eventdriver) / sizeof(EVENT_DRIVE)//驅動表的大小EVENT_FUN GetFunFromDriver(MODE_TYPE mod, EVENT_TYPE event, STATUS_TYPE status)//驅動表查找函數 { int i = 0; for (i = 0; i < driversize; i ++){ if ((eventdriver[i].mod == mod) && (eventdriver[i].event == event) && (eventdriver[i].status == status)){ return eventdriver[i].eventfun;}} return NULL; }

這種方法的好處：

• 提高了程序的可讀性。一個消息如何處理，只要看一下驅動表就知道，非常明顯。

• 減少了重復代碼。這種方法的代碼量肯定比第一種少。為什么？因為它把一些重復的東西：switch分支處理進行了抽象，把其中公共的東西——根據三個元素查找處理方法抽象成了一個函數GetFunFromDriver外加一個驅動表。

• 可擴展性。注意這個函數指針，他的定義其實就是一種契約，類似于java中的接口，c++中的純虛函數，只有滿足這個條件（入參，返回值），才可以作為一個事件的處理函數。這個有一點插件結構的味道，你可以對這些插件進行方便替換，新增，刪除，從而改變程序的行為。而這種改變，對事件處理函數的查找又是隔離的（也可以叫做隔離了變化）。、

• 程序有一個明顯的清晰主干。

• 降低了復雜度。通過把程序邏輯的復雜度轉移到人類更容易處理的數據中來，從而達到控制復雜度的目標。

?2. 基于數據模型編程

• 基于Yang模型編程(DSL），YANG是一種語言，是用來建立數據模型的語言，可以通過定義業(yè)務數據模型，自動生成對應數據處理邏輯（比如參數校驗，范圍，存儲方式，權限控制等），典型的數據驅動編程；

• Linux內核DTS設備樹模型，刪除大量hardcode，精簡內核驅動代碼。

• 基于xml，protobuf數據模型編程，界面顯示，web配置邏輯，RPC微服務等；

數據驅動思考

• 它不是一個全新的編程模型：它只是一種設計思路，而且歷史悠久，在unix/linux社區(qū)應用很多；

• 它不同于面向對象設計中的數據：“數據驅動編程中，數據不但表示了某個對象的狀態(tài)，實際上還定義了程序的流程；OO看重的是封裝，而數據驅動編程看重的是編寫盡可能少的代碼。”

• 數據壓倒一切。如果選擇了正確的數據結構并把一切組織的井井有條，正確的算法就不言自明。編程的核心是數據結構，而不是算法。——Rob Pike
  

• 程序員束手無策，只有跳脫代碼，直起腰，仔細思考數據才是最好的行動。表達式編程的精髓。——Fred Brooks

• 數據比程序邏輯更易駕馭。盡可能把設計的復雜度從代碼轉移至數據是個好實踐。——《unix編程藝術》作者。

總結

設計模式（古典）主要針對OOP領域編程設計方法的抽象。這里的編程模型，主要是針對業(yè)務編程框架的抽象。

消息驅動和事件驅動，本身有很多相似地方，消息驅動主要代表是經典跨進程通信架構，讓消息處理和函數調用一樣，邏輯依然可以保持清晰簡單。而事件驅動采取異步處理方式，最大化解耦，讓程序耦合更低，框架更易擴展，兩種編程模型都有各自優(yōu)缺點，只有根據具體的場景找到一種合適使用方法。

數據驅動是一種新的編程思考，堅持"data as program"準則，把處理邏輯數據化，這樣可以通過不同數據配置來實現(xiàn)不同的邏輯，讓核心代碼更精煉簡單，框架更易擴展。

參考和擴展閱讀

• 《unix編程藝術》

• 《Software Architecture Patterns》

• ?https://blog.csdn.net/chgaowei/article/details/6966857

• 深入理解Linux高性能網絡架構的那些事

- END -

---

看完一鍵三連在看，轉發(fā)，點贊

是對文章最大的贊賞，極客重生感謝你

編程究竟難在哪？

深入理解無鎖編程

深入理解編程藝術之策略與機制相分離

總結

以上是生活随笔為你收集整理的深入理解重要的编程模型的全部內容，希望文章能夠幫你解決所遇到的問題。

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