国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

微服務指南走北（二）：微服務架構的進程間通信（IPC）

beanlam / 1608人閱讀

摘要：微服務常用的進程間通信技術即表述性狀態傳遞英文，簡稱是博士在年他的博士論文中提出來的一種軟件架構風格。摘自微服務實戰從架構到部署處理部分請求失敗對于分布式的微服務，必須要面對的一大問題就是局部請求失敗的處理。

先拋出幾個問題 
微服務架構的交互模式有哪些？


微服務常用的進程間通信技術有哪些？


如何處理部分請求失敗?


API的定義需要注意的事項有哪些


微服務的通信機制與SOA的通信機制之間的關系與區別
微服務架構的交互模式 一對一還是一對多？ 
一對一：每個客戶端請求有一個服務實例來響應


一對多：每個客戶端請求有多個服務實例來響應
同步還是異步？ 
同步模式：客戶端請求需要服務端即時響應，甚至可能由于等待而阻塞


異步模式：客戶端請求不會阻塞進程，服務端的響應可以是非即時的
一對一的交互模式有以下幾種方式： 
請求/響應：一個客戶端向服務器端發起請求，等待響應，客戶端期望此響應即時到達。在一個基于線程的應用中，等待過程可能造成線程阻塞。


通知（也就是常說的單向請求）：一個客戶端請求發送到服務端，但是并不期望服務端響應。


請求/異步響應：客戶端發送請求到服務端，服務端異步響應請求。客戶端不會阻塞，而且被設計成默認響應不會立刻到達。
一對多的交互模式有以下幾種方式： 
發布/ 訂閱模式：客戶端發布通知消息，被零個或者多個感興趣的服務消費。


發布/異步響應模式：客戶端發布請求消息，然后等待從感興趣服務發回的響應。
微服務常用的進程間通信技術 
REST：REST即表述性狀態傳遞（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。它是一種針對網絡應用的設計和開發方式，可以降低開發的復雜性，提高系統的可伸縮性。


Thrift：thrift是一個軟件框架，用來進行可擴展且跨語言的服務的開發。它結合了功能強大的軟件堆棧和代碼生成引擎，以構建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語言間無縫結合的、高效的服務
API的定義需要注意的事項 
IPC通信方式的選擇：API的定義取決于選擇的IPC通信方式,如果是消息機制（如 AMQP 或者 STOMP），API則由消息頻道（channel）和消息類型；如果是使用HTTP機制，則是基于請求/響應（調用http的url）。


API的版本升級：服務的API往往隨著時間的推移而不斷變化。在單體應用中，往往會直接修改API的消費者。但是在微服務中，通常不能讓所有的API消費者保持與API同步更新，可能新版本和舊版本的API同時運行。


消息格式的選擇：為微服務來決定最適合的消息格式是另一個關鍵要素。傳統的單體的軟件使用復雜的二進制的格式，SOA/Web services的應用使用基于復雜消息格式（SOAP）和schema（xsd）的文本消息。在大多數的微服務里面，它們使用簡單的基于文本的消息格式，例如基于HTTP資源API風格之上的JSON/XML等。在某些情況下它們需要二進制的格式時（文本消息在某些場景下顯得啰嗦），可以使用二進制的協議例如二進制的Thrift、Protobuf、Arvo。（摘自《微服務實戰：從架構到部署》）
處理部分請求失敗

對于分布式的微服務，必須要面對的一大問題就是局部請求失敗的處理。

Netfilix 提供了一個比較好的解決方案，具體的應對措施包括(摘自“Chris Richardson 微服務系列”)：



網絡超時：在等待響應時，不設置無限期阻塞，而是采用超時策略。使用超時策略可以確保資源不被無限期占用。


限制請求的次數：可以為客戶端對某特定服務的請求設置一個訪問上限。如果請求已達上限，就要立刻終止請求服務。


斷路器模式（CircuitBreakerPattern）：記錄成功和失敗請求的數量。如果失效率超過一個閾值，觸發斷路器使得后續的請求立刻失敗。如果大量的請求失敗，就可能是這個服務不可用，再發請求也無意義。在一個失效期后，客戶端可以再試，如果成功，關閉此斷路器。


提供回滾：當一個請求失敗后可以進行回滾邏輯。例如，返回緩存數據或者一個系統默認值。
微服務的通信機制與SOA的通信機制之間的關系與區別 
在單體應用里面，不同組件的業務功能通過函數調用或者語言級別的方法調用來實現。在SOA中，這轉變為更加松耦合的Web Service級別的消息，主要是基于HTTP、JMS等不同協議的SOAP。Webservice 包含的幾十種操作以及復雜的消息機制是阻礙Web Services流行的一個重要因素。對于微服務架構而言，必須要有一個簡單且輕量級的消息機制。
參考文章：

微服務實戰：從架構到部署

by 劉迎光@螢火蟲工作室  
OpenBI交流群：495266201  
MicroService 微服務交流群：217722918    
mail: liuyg#liuyingguang.cn  
博主首頁（==防止爬蟲==）：http://blog.liuyingguang.cn  
OpenBI問答社區：http://www.openbi.tk

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/66808.html

相關文章

  • 微服務指南走北（一）：微服務是什么

    摘要：每個微服務提供一組，供其他微服務或者應用客戶端所用。由于微服務架構的分布式特點，測試一個基于微服務架構的應用也是很復雜的任務。微服務架構模式下，應用的改變將會波及多個服務。 微服務Microservices已經成為軟件架構最流行的熱詞之一。網絡上看到很多關于微服務的文章，但是感覺很多離我們還很遙遠，并且沒有找到多少真正在企業場景中應用的實例。此處省略一萬字~~~~于是想要將自己最近一段...

    sherlock221 評論0 收藏0

  • PHP進程通信

    摘要：一進程間通信理解間進程通信機制，先了解下進程間有哪些通訊機制歷史發展按照歷史來源主要有兩大塊的管道，，信號的消息隊列，共享內存，信號燈。信號量主要作為進程間，以及進程內部線程之間的通訊手段。主要依賴，兼容擴展實現方式的進程間通信之消息隊列。 PHP間進程如何通信，PHP相關的服務的IPC是實現方式，IPC的思想如何用到項目中。 一、linux進程間通信 理解php間進程通信機制，先了解...

    haobowd 評論0 收藏0

  • 微服務指南走北（三）：Restful API 設計簡述

    摘要：為了避免的變動導致用戶使用中產生意外結果或調用失敗，最好強制要求所有訪問都需要指定版本號。請避免提供默認版本號，一旦提供，日后想要修改它會相當困難。返回結果針對不同操作，服務器向用戶返回的結果應該符合以下規范。 API的定義取決于選擇的IPC通信方式,如果是消息機制（如 AMQP 或者 STOMP），API則由消息頻道（channel）和消息類型；如果是使用HTTP機制，則是基于請求/...

    TZLLOG 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<