摘要：微服務(wù)常用的進(jìn)程間通信技術(shù)即表述性狀態(tài)傳遞英文，簡(jiǎn)稱是博士在年他的博士論文中提出來的一種軟件架構(gòu)風(fēng)格。摘自微服務(wù)實(shí)戰(zhàn)從架構(gòu)到部署處理部分請(qǐng)求失敗對(duì)于分布式的微服務(wù)，必須要面對(duì)的一大問題就是局部請(qǐng)求失敗的處理。

微服務(wù)架構(gòu)的交互模式有哪些？

微服務(wù)常用的進(jìn)程間通信技術(shù)有哪些？

如何處理部分請(qǐng)求失敗?

API的定義需要注意的事項(xiàng)有哪些

微服務(wù)的通信機(jī)制與SOA的通信機(jī)制之間的關(guān)系與區(qū)別

一對(duì)一：每個(gè)客戶端請(qǐng)求有一個(gè)服務(wù)實(shí)例來響應(yīng)

一對(duì)多：每個(gè)客戶端請(qǐng)求有多個(gè)服務(wù)實(shí)例來響應(yīng)

同步模式：客戶端請(qǐng)求需要服務(wù)端即時(shí)響應(yīng)，甚至可能由于等待而阻塞

異步模式：客戶端請(qǐng)求不會(huì)阻塞進(jìn)程，服務(wù)端的響應(yīng)可以是非即時(shí)的

請(qǐng)求/響應(yīng)：一個(gè)客戶端向服務(wù)器端發(fā)起請(qǐng)求，等待響應(yīng)，客戶端期望此響應(yīng)即時(shí)到達(dá)。在一個(gè)基于線程的應(yīng)用中，等待過程可能造成線程阻塞。

通知（也就是常說的單向請(qǐng)求）：一個(gè)客戶端請(qǐng)求發(fā)送到服務(wù)端，但是并不期望服務(wù)端響應(yīng)。

請(qǐng)求/異步響應(yīng)：客戶端發(fā)送請(qǐng)求到服務(wù)端，服務(wù)端異步響應(yīng)請(qǐng)求。客戶端不會(huì)阻塞，而且被設(shè)計(jì)成默認(rèn)響應(yīng)不會(huì)立刻到達(dá)。

發(fā)布/ 訂閱模式：客戶端發(fā)布通知消息，被零個(gè)或者多個(gè)感興趣的服務(wù)消費(fèi)。

發(fā)布/異步響應(yīng)模式：客戶端發(fā)布請(qǐng)求消息，然后等待從感興趣服務(wù)發(fā)回的響應(yīng)。

REST：REST即表述性狀態(tài)傳遞（英文：Representational State Transfer，簡(jiǎn)稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構(gòu)風(fēng)格。它是一種針對(duì)網(wǎng)絡(luò)應(yīng)用的設(shè)計(jì)和開發(fā)方式，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。

Thrift：thrift是一個(gè)軟件框架，用來進(jìn)行可擴(kuò)展且跨語言的服務(wù)的開發(fā)。它結(jié)合了功能強(qiáng)大的軟件堆棧和代碼生成引擎，以構(gòu)建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語言間無縫結(jié)合的、高效的服務(wù)

IPC通信方式的選擇：API的定義取決于選擇的IPC通信方式,如果是消息機(jī)制（如 AMQP 或者 STOMP），API則由消息頻道（channel）和消息類型；如果是使用HTTP機(jī)制，則是基于請(qǐng)求/響應(yīng)（調(diào)用http的url）。

API的版本升級(jí)：服務(wù)的API往往隨著時(shí)間的推移而不斷變化。在單體應(yīng)用中，往往會(huì)直接修改API的消費(fèi)者。但是在微服務(wù)中，通常不能讓所有的API消費(fèi)者保持與API同步更新，可能新版本和舊版本的API同時(shí)運(yùn)行。

消息格式的選擇：為微服務(wù)來決定最適合的消息格式是另一個(gè)關(guān)鍵要素。傳統(tǒng)的單體的軟件使用復(fù)雜的二進(jìn)制的格式，SOA/Web services的應(yīng)用使用基于復(fù)雜消息格式（SOAP）和schema（xsd）的文本消息。在大多數(shù)的微服務(wù)里面，它們使用簡(jiǎn)單的基于文本的消息格式，例如基于HTTP資源API風(fēng)格之上的JSON/XML等。在某些情況下它們需要二進(jìn)制的格式時(shí)（文本消息在某些場(chǎng)景下顯得啰嗦），可以使用二進(jìn)制的協(xié)議例如二進(jìn)制的Thrift、Protobuf、Arvo。（摘自《微服務(wù)實(shí)戰(zhàn)：從架構(gòu)到部署》）

對(duì)于分布式的微服務(wù)，必須要面對(duì)的一大問題就是局部請(qǐng)求失敗的處理。

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

網(wǎng)絡(luò)超時(shí)：在等待響應(yīng)時(shí)，不設(shè)置無限期阻塞，而是采用超時(shí)策略。使用超時(shí)策略可以確保資源不被無限期占用。

限制請(qǐng)求的次數(shù)：可以為客戶端對(duì)某特定服務(wù)的請(qǐng)求設(shè)置一個(gè)訪問上限。如果請(qǐng)求已達(dá)上限，就要立刻終止請(qǐng)求服務(wù)。

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

提供回滾：當(dāng)一個(gè)請(qǐng)求失敗后可以進(jìn)行回滾邏輯。例如，返回緩存數(shù)據(jù)或者一個(gè)系統(tǒng)默認(rèn)值。

在單體應(yīng)用里面，不同組件的業(yè)務(wù)功能通過函數(shù)調(diào)用或者語言級(jí)別的方法調(diào)用來實(shí)現(xiàn)。在SOA中，這轉(zhuǎn)變?yōu)楦铀神詈系腤eb Service級(jí)別的消息，主要是基于HTTP、JMS等不同協(xié)議的SOAP。Webservice 包含的幾十種操作以及復(fù)雜的消息機(jī)制是阻礙Web Services流行的一個(gè)重要因素。對(duì)于微服務(wù)架構(gòu)而言，必須要有一個(gè)簡(jiǎn)單且輕量級(jí)的消息機(jī)制。

微服務(wù)實(shí)戰(zhàn)：從架構(gòu)到部署

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