資訊專欄INFORMATION COLUMN
摘要：微服務(wù)常用的進程間通信技術(shù)即表述性狀態(tài)傳遞英文，簡稱是博士在年他的博士論文中提出來的一種軟件架構(gòu)風(fēng)格。摘自微服務(wù)實戰(zhàn)從架構(gòu)到部署處理部分請求失敗對于分布式的微服務(wù)，必須要面對的一大問題就是局部請求失敗的處理。
先拋出幾個問題
微服務(wù)架構(gòu)的交互模式 一對一還是一對多？微服務(wù)架構(gòu)的交互模式有哪些？
微服務(wù)常用的進程間通信技術(shù)有哪些？
如何處理部分請求失敗?
API的定義需要注意的事項有哪些
微服務(wù)的通信機制與SOA的通信機制之間的關(guān)系與區(qū)別
同步還是異步？一對一：每個客戶端請求有一個服務(wù)實例來響應(yīng)
一對多：每個客戶端請求有多個服務(wù)實例來響應(yīng)
一對一的交互模式有以下幾種方式：同步模式：客戶端請求需要服務(wù)端即時響應(yīng)，甚至可能由于等待而阻塞
異步模式：客戶端請求不會阻塞進程，服務(wù)端的響應(yīng)可以是非即時的
一對多的交互模式有以下幾種方式：請求/響應(yīng)：一個客戶端向服務(wù)器端發(fā)起請求，等待響應(yīng)，客戶端期望此響應(yīng)即時到達。在一個基于線程的應(yīng)用中，等待過程可能造成線程阻塞。
通知（也就是常說的單向請求）：一個客戶端請求發(fā)送到服務(wù)端，但是并不期望服務(wù)端響應(yīng)。
請求/異步響應(yīng)：客戶端發(fā)送請求到服務(wù)端，服務(wù)端異步響應(yīng)請求。客戶端不會阻塞，而且被設(shè)計成默認(rèn)響應(yīng)不會立刻到達。
微服務(wù)常用的進程間通信技術(shù)發(fā)布/ 訂閱模式：客戶端發(fā)布通知消息，被零個或者多個感興趣的服務(wù)消費。
發(fā)布/異步響應(yīng)模式：客戶端發(fā)布請求消息，然后等待從感興趣服務(wù)發(fā)回的響應(yīng)。
API的定義需要注意的事項REST：REST即表述性狀態(tài)傳遞（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構(gòu)風(fēng)格。它是一種針對網(wǎng)絡(luò)應(yīng)用的設(shè)計和開發(fā)方式，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。
Thrift：thrift是一個軟件框架，用來進行可擴展且跨語言的服務(wù)的開發(fā)。它結(jié)合了功能強大的軟件堆棧和代碼生成引擎，以構(gòu)建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語言間無縫結(jié)合的、高效的服務(wù)
處理部分請求失敗IPC通信方式的選擇：API的定義取決于選擇的IPC通信方式,如果是消息機制（如 AMQP 或者 STOMP），API則由消息頻道（channel）和消息類型；如果是使用HTTP機制，則是基于請求/響應(yīng)（調(diào)用http的url）。
API的版本升級：服務(wù)的API往往隨著時間的推移而不斷變化。在單體應(yīng)用中，往往會直接修改API的消費者。但是在微服務(wù)中，通常不能讓所有的API消費者保持與API同步更新，可能新版本和舊版本的API同時運行。
消息格式的選擇：為微服務(wù)來決定最適合的消息格式是另一個關(guān)鍵要素。傳統(tǒng)的單體的軟件使用復(fù)雜的二進制的格式，SOA/Web services的應(yīng)用使用基于復(fù)雜消息格式（SOAP）和schema（xsd）的文本消息。在大多數(shù)的微服務(wù)里面，它們使用簡單的基于文本的消息格式，例如基于HTTP資源API風(fēng)格之上的JSON/XML等。在某些情況下它們需要二進制的格式時（文本消息在某些場景下顯得啰嗦），可以使用二進制的協(xié)議例如二進制的Thrift、Protobuf、Arvo。（摘自《微服務(wù)實戰(zhàn)：從架構(gòu)到部署》）
對于分布式的微服務(wù)，必須要面對的一大問題就是局部請求失敗的處理。
微服務(wù)的通信機制與SOA的通信機制之間的關(guān)系與區(qū)別Netfilix 提供了一個比較好的解決方案，具體的應(yīng)對措施包括(摘自“Chris Richardson 微服務(wù)系列”)：
網(wǎng)絡(luò)超時：在等待響應(yīng)時，不設(shè)置無限期阻塞，而是采用超時策略。使用超時策略可以確保資源不被無限期占用。
限制請求的次數(shù)：可以為客戶端對某特定服務(wù)的請求設(shè)置一個訪問上限。如果請求已達上限，就要立刻終止請求服務(wù)。
斷路器模式（CircuitBreakerPattern）：記錄成功和失敗請求的數(shù)量。如果失效率超過一個閾值，觸發(fā)斷路器使得后續(xù)的請求立刻失敗。如果大量的請求失敗，就可能是這個服務(wù)不可用，再發(fā)請求也無意義。在一個失效期后，客戶端可以再試，如果成功，關(guān)閉此斷路器。
提供回滾：當(dāng)一個請求失敗后可以進行回滾邏輯。例如，返回緩存數(shù)據(jù)或者一個系統(tǒng)默認(rèn)值。
參考文章：在單體應(yīng)用里面，不同組件的業(yè)務(wù)功能通過函數(shù)調(diào)用或者語言級別的方法調(diào)用來實現(xiàn)。在SOA中，這轉(zhuǎn)變?yōu)楦铀神詈系腤eb Service級別的消息，主要是基于HTTP、JMS等不同協(xié)議的SOAP。Webservice 包含的幾十種操作以及復(fù)雜的消息機制是阻礙Web Services流行的一個重要因素。對于微服務(wù)架構(gòu)而言，必須要有一個簡單且輕量級的消息機制。
微服務(wù)實戰(zhàn)：從架構(gòu)到部署
by 劉迎光@螢火蟲工作室
OpenBI交流群：495266201
MicroService 微服務(wù)交流群：217722918
mail: liuyg#liuyingguang.cn
博主首頁（==防止爬蟲==）：http://blog.liuyingguang.cn
OpenBI問答社區(qū)：http://www.openbi.tk
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/66808.html
摘要：每個微服務(wù)提供一組，供其他微服務(wù)或者應(yīng)用客戶端所用。由于微服務(wù)架構(gòu)的分布式特點，測試一個基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。微服務(wù)架構(gòu)模式下，應(yīng)用的改變將會波及多個服務(wù)。 微服務(wù)Microservices已經(jīng)成為軟件架構(gòu)最流行的熱詞之一。網(wǎng)絡(luò)上看到很多關(guān)于微服務(wù)的文章，但是感覺很多離我們還很遙遠(yuǎn)，并且沒有找到多少真正在企業(yè)場景中應(yīng)用的實例。此處省略一萬字~~~~于是想要將自己最近一段...
摘要：為了避免的變動導(dǎo)致用戶使用中產(chǎn)生意外結(jié)果或調(diào)用失敗，最好強制要求所有訪問都需要指定版本號。請避免提供默認(rèn)版本號，一旦提供，日后想要修改它會相當(dāng)困難。返回結(jié)果針對不同操作，服務(wù)器向用戶返回的結(jié)果應(yīng)該符合以下規(guī)范。 API的定義取決于選擇的IPC通信方式,如果是消息機制（如 AMQP 或者 STOMP），API則由消息頻道（channel）和消息類型；如果是使用HTTP機制，則是基于請求/...
閱讀 797·2021-11-11 16:54
閱讀 1532·2021-08-24 10:01
閱讀 1922·2019-08-30 15:54
閱讀 3302·2019-08-29 14:02
閱讀 3138·2019-08-28 18:22
閱讀 2253·2019-08-28 18:09
閱讀 3714·2019-08-26 10:26
閱讀 2674·2019-08-23 18:23
