Cloud Foundry架構和訊息處理機制
Cloud Foundry的核心元件主要有Router、Cloud Controller、Services、Health Manager和DEA,以及模組之間使用的NATS訊息通訊機制。這些模組之間的關聯關係如下圖所示,模組之間使用NATS或者HTTP等其他的訊息機制進行通訊。
NATS是一個基於事件驅動的輕量級支援釋出、訂閱機制的訊息系統,基於Event Machine開發,以事件驅動。新版本的NATS可以支援多伺服器節點,避免了單節點的NATS導致的系統在HA方面的不穩定性。各個元件是基於訊息釋出訂閱機制構建的,NATS元件的主要作用和功能如下:
定址和發現;
命令和控制;
中央通訊系統;
支援訊息的釋出和訂閱。
在處理Web業務時,會存在大量併發的Http連結,在處理TCP Socket的高效能的I/O設計中,NATS有兩個比較著名的模式Reactor和Proactor模式,其中Reactor模式用於同步I/O,而Proactor運用於非同步I/O操作。
在比較這兩個模式之前,首先說明幾個概念,什麼是阻塞和非阻塞,什麼是同步和非同步,同步和非同步是針對應用程式和核心的互動而言的,同步指的是使用者程式觸發IO操作並等待或者輪詢的去檢視IO操作是否就緒,而非同步是指使用者程式觸發IO操作以後便開始做自己的事情,而當IO操作已經完成的時候會得到IO完成的通知。
而阻塞和非阻塞是針對於程式在訪問資料的時候,根據IO操作的就緒狀態來採取的不同方式,說白了是一種讀取或者寫入操作函式的實現方式,阻塞方式下讀取或者寫入函式將一直等待,而非阻塞方式下,讀取或者寫入函式會立即返回一個狀態值。
一般來說I/O模型可以分為:同步阻塞,同步非阻塞,非同步阻塞,非同步非阻塞IO
同步阻塞IO:
在此種方式下,使用者程式在發起一個IO操作以後,必須等待IO操作的完成,只有當真正完成了IO操作以後,使用者程式才能執行。JAVA傳統的IO模型屬於此種方式。
同步非阻塞IO:
在此種方式下,使用者程式發起一個IO操作以後邊可返回做其它事情,但是使用者程式需要時不時的詢問IO操作是否就緒,這就要求使用者程式不停的去詢問,從而引入不必要的CPU資源浪費。其中目前JAVA的NIO就屬於同步非阻塞IO。
非同步阻塞IO:
此種方式下是指應用發起一個IO操作以後,不等待核心IO操作的完成,等核心完成IO操作以後會通知應用程式,這其實就是同步和非同步最關鍵的區別,同步必須等待或者主動的去詢問IO是否完成,那麼為什麼說是阻塞的呢?因為此時是通過select系統呼叫來完成的,而select函式本身的實現方式是阻塞的,而採用select函式有個好處就是它可以同時監聽多個檔案控制程式碼,從而提高系統的併發性。
非同步非阻塞IO:
在此種模式下,使用者程式只需要發起一個IO操作然後立即返回,等IO操作真正的完成以後,應用程式會得到IO操作完成的通知,此時使用者程式只需要對資料進行處理就好了,不需要進行實際的IO讀寫操作,因為真正的IO讀取或者寫入操作已經由核心完成了。目前Java中還沒有支援此種IO模型。
Reactor和Proactor模式比較:
首先來看看Reactor模式,Reactor模式應用於同步I/O的場景。我們分別以讀操作和寫操作為例來看看Reactor中的具體步驟:
Reactor模式:
讀取操作:
1. Register_Handler:應用程式註冊讀就緒事件和相關聯的事件處理器。
2. Demultiplexer:事件分離器等待事件的發生
3. Notify:當發生讀就緒事件的時候,事件分離器呼叫第一步註冊的事件處理器。
4. Handle_Event:事件處理器首先執行實際的讀取操作,然後根據讀取到的內容進行進一步的處理
寫入操作類似於讀取操作,只不過第一步註冊的是寫就緒事件。
下面我們來看看Proactor模式中讀取操作和寫入操作的過程:
Proactor模式:
讀取操作:
1. 應用程式初始化一個非同步讀取操作,然後註冊相應的事件處理器,此時事件處理器不關注讀取就緒事件,而是關注讀取完成事件,這是區別於Reactor的關鍵。
2. 事件分離器等待讀取操作完成事件。
3. 在事件分離器等待讀取操作完成的時候,作業系統呼叫核心執行緒完成讀取操作,並將讀取的內容放入使用者傳遞過來的快取區中。這也是區別於Reactor的一點,Proactor中,應用程式需要傳遞快取區。
4. 事件分離器捕獲到讀取完成事件後,啟用應用程式註冊的事件處理器,事件處理器直接從快取區讀取資料,而不需要進行實際的讀取操作。
Proactor中寫入操作和讀取操作,只不過感興趣的事件是寫入完成事件。
從上面可以看出,Reactor和Proactor模式的主要區別就是真正的讀取和寫入操作是有誰來完成的,Reactor中需要應用程式自己讀取或者寫入資料,而Proactor模式中,應用程式不需要進行實際的讀寫過程,它只需要從快取區讀取或者寫入即可,作業系統會讀取快取區或者寫入快取區到真正的IO裝置.
綜上所述,同步和非同步是相對於應用和核心的互動方式而言的,同步 需要主動去詢問,而非同步的時候核心在IO事件發生的時候通知應用程式,而阻塞和非阻塞僅僅是系統在呼叫系統呼叫的時候函式的實現方式而已。
Cloud Foundry是一個開源的平臺即服務,它提供給開發者自由的去選擇雲平臺、開發框架和應用服務。Cloud Foundry最初由VMware發起,得到了業界廣泛的支援,更多關於Cloud Foundry的技術架構和分析,已經梳理成“Cloud Foundry技術架構詳解分析”,請點選原文連結獲取更多技術詳情。
溫馨提示:
請識別二維碼關注公眾號,點選原文連結獲取更多技術資料和文章。
相關文章
- 原始碼分析:Android訊息處理機制原始碼Android
- Android應用程式訊息處理機制Android
- Handler訊息處理機制原始碼解析 上原始碼
- Android 訊息處理機制:Handler|MessageAndroid
- Windows應用程式的訊息處理機制Windows
- Service初探與非同步訊息處理機制非同步
- Looper中的訊息佇列處理機制OOP佇列
- Android中的非同步訊息處理機制Android非同步
- 深入理解Android非同步訊息處理機制Android非同步
- OC訊息機制,訊息轉發機制
- Android應用程式訊息處理機制(Looper、Handler)分析AndroidOOP
- 訊息機制
- Android訊息處理機制(Handler、Looper、MessageQueue與Message)AndroidOOP
- 如何生動形象的理解Android Handler訊息處理機制Android
- (十七) 整合spring cloud雲架構 -訊息驅動 Spring Cloud StreamSpringCloud架構
- Linux訊號處理機制Linux
- Spring Cloud Stream如何處理訊息重複消費?SpringCloud
- 詳解 Handler 訊息處理機制(附自整理超全 Q&A)
- Android非同步訊息處理機制詳解及原始碼分析Android非同步原始碼
- 《C++ Primer》 P415 訊息處理機制 原始碼C++原始碼
- iOS訊息機制iOS
- SAP訊息機制
- MPP架構和批處理架構
- 處理器架構和配置架構
- Linux訊號機制與訊號處理Linux
- 如何處理RabbitMQ 訊息堆積和訊息丟失問題MQ
- Cloud Foundry 使用Cloud
- 訊息機制篇——初識訊息與訊息佇列佇列
- IOS 訊息推送處理iOS
- spring cloud微服務架構-Eureka保護機制SpringCloud微服務架構
- JMS java 訊息機制Java
- Windows訊息機制概述Windows
- OC訊息機制和super關鍵字
- 多種訊息傳送機制,處理合適不??
- Android訊息機制Message訊息池Android
- 回轉壽司你一定吃過!——Android訊息機制(處理)Android
- 從LinkedIn的資料處理機制學習資料架構架構
- php ActiveMQ的傳送訊息,與處理訊息PHPMQ