微服務中服務調(diào)用的解決方案是什么

微服務中服務調(diào)用的解決方案是什么，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

微服務已經(jīng)成為越來越多企業(yè)IT部門研究的對象，逐步趨向于火熱，數(shù)人云之前給大家分享過：《實錄|微服務企業(yè)級落地將會帶來哪些轉變？》深入地闡述了微服務能夠帶來的利益，但是作為一項新興的技術，總難免會遇到這樣或那樣的難題，今天就來一起看看微服務的難點之一：服務調(diào)用的解決方案。

微服務有很多難點，比如分布式系統(tǒng)：

當繼續(xù)在服務架構的這些概念上進行探討時，不可避免的會對一些難題進行討論，作者希望在探索并實現(xiàn)微服務時，已經(jīng)看到并消化了分布式計算的錯誤，同時作者也推薦了Jeff Hodges的《Notes on Distributed Systems for Young Bloods 》。

大部分一直在用過時的方法去解決這些問題，并一直在尋找“如何讓開發(fā)者編寫能夠交付價值并嘗試抽象分布式系統(tǒng)的業(yè)務邏輯”的解決方案。所做的事情是為了讓服務調(diào)用看起來如本地調(diào)用通過抽象的網(wǎng)絡與本地接口（CORBA、DCOM、ejb等等），但后來發(fā)現(xiàn)這并不是一個好方法，然后切換到WSDL/SOAP/代碼生成類似的東西，以擺脫這些其他協(xié)議的脆弱性，但仍然使用相同的實踐（SOAP客戶機代碼生成），有些人確實讓這些方法奏效了，但也有很多不足之處，下面來看看當簡單地調(diào)用服務時會遇到的一些問題：

錯誤或延遲

當我們向服務發(fā)送消息時會發(fā)生什么？出于這個討論的目的，這個請求被分成小塊并通過網(wǎng)絡路由。

因為這個“網(wǎng)絡”，我們處理分布式計算錯誤想法，應用程序通過異步網(wǎng)絡進行通信，這意味著對時間沒有單一且統(tǒng)一的理解，服務以自己對“時間的含義”理解去工作，這可能與其他服務不同，更重要的是，這些異步網(wǎng)絡路由數(shù)據(jù)包根據(jù)可用性的路徑、擁堵、硬件鼓掌等，沒有保證消息在有限的時間內(nèi)將其接受者（注意，這個相同的現(xiàn)象發(fā)生在“同步”網(wǎng)絡沒有一個統(tǒng)一的理解時間）。

這其實很糟糕，現(xiàn)在不可能確定錯誤或只是緩慢，如果客戶要求在售票網(wǎng)站上搜索演唱會，可不想等到天荒地老，希望能得到響應，在某個時候，請求失敗，所以需要增加服務的超時時間，但也不僅限于增加服務時間。

在處理下游請求時，不能因為Down-Stream網(wǎng)絡交互速度而慢下來，要有一些時間去考慮設置：

• 建立到下游服務的鏈接需要多長時間，這樣才能去發(fā)送請求

• 是否收到回復

補充說明：構建系統(tǒng)作為服務架構的巨大優(yōu)勢是速度，包括對系統(tǒng)進行更改的速度，重視自治和系統(tǒng)的頻繁部署，但當去這樣做的時候會很快發(fā)現(xiàn)，在一切奇怪的情況下，超時工作，并不能很好地進行。

考慮到客戶機應用設置了3個超時，從推薦引擎中得到相應，但推薦引擎也咨詢相關引擎，因此，它發(fā)出了一個設置為2S的超時調(diào)用，這個應該沒有問題，因為尚有服務調(diào)用將等待最多3個，但如果關聯(lián)引擎必須與促銷服務進行對話該怎么辦呢？如果超時設置為5S呢？我們的測試（單元、本地、集成）的關聯(lián)引擎似乎通過了所有的測試，甚至在潛在的操作下，因為超時設置為5S，推廣服務也不會花那么長的時間，或者在超時結束后，關聯(lián)引擎適當?shù)亟Y束了調(diào)用。

最終得到的是一個繁瑣的，很難調(diào)試很多電話進來時的狀態(tài)（這可能發(fā)生在任何時間，因為網(wǎng)絡是“異步”的），超時是很重要的一個條件。

重試

由于確實沒有在分布式系統(tǒng)中有任何彈性的時間保證，所以需要在任務花費太長時間時超時，現(xiàn)在的情況是“超時后要做什么？”是不是向來電者拋出一個糟糕的HTTP 5XX？是否接受一些建議，讓微服務變得有彈性，承諾理論和回調(diào)？還是我們重試？

若要重試，如果調(diào)用了更改下游服務的數(shù)據(jù)會怎樣？作者在其他文章提到過，微服務最難的部分之一也是數(shù)據(jù)方面。

但更有意思的是，如果下游服務開始失敗，最終會重新嘗試所有的請求呢？如果有10個或100個實例的推薦引擎調(diào)用關聯(lián)引擎，但關聯(lián)引擎超時了怎么辦？最后得到了Thundering Herd Problem的一個變種，當試圖補救，并慢慢地恢復受影響的服務時，這就結束了DDoS的服務，即使我們試圖補救和緩慢地返回受影響的服務。

需要注意重試策略。指數(shù)重試的回退會有所幫助，但可能仍然會遇到同樣的問題。

路由

因為服務是在考慮彈性的情況下部署的，所以在理想的情況下，在不同的容錯區(qū)域中運行多個實例，這樣一些區(qū)域在不降低服務的可用性情況下就會失敗，但當事件開始失敗時，需要一種方法去繞過這些失敗，但在容錯區(qū)域執(zhí)劍，可能有其他的服務路由選擇原因。也許某些“區(qū)域”被實現(xiàn)作為備份的服務的地理部署；也許從延遲的角度去看，讓我們的流量在正常運行時訪問備份實例太貴了。

也許想要像這樣路由客戶端流量，但服務間通信呢？為了滿足客戶端請求，必須在服務之間進行反向對話，那么路由又如何選擇呢？

容錯性區(qū)域執(zhí)劍的路由變化可能是路由和負載均衡請求，而這些請求是在可能出現(xiàn)周期性的異常服務的情況下進行的，希望將路由調(diào)整到能夠與服務調(diào)用保持一致的服務，將流量發(fā)送到無法跟上的服務上是沒有什么意義的。

當討論如何部署服務的新版本時，應該去考慮更棘手的問題，正如前面所說，希望在服務之間保持某種程度上的自治，這樣就可以快速迭代和推動更改，不希望破壞依賴服務，因此，如果可以將某些流量路由到新版本，并將其綁定到構建和發(fā)布策略（即藍/綠，A/B測試，Canary發(fā)行版），這樣很快就變得復雜了，如何確定路線？也許正在做的是在一個特殊的“登臺環(huán)境”中進行測試，也許只是在做一個未經(jīng)宣布的Dark Launch，也許是A/B測試，但如果有某種狀態(tài)，需要考慮數(shù)據(jù)模式演化、多版本數(shù)據(jù)庫實現(xiàn)等。

服務發(fā)現(xiàn)

除了前面討論的一些彈性考慮之外，在Expect失敗的環(huán)境中，如何發(fā)現(xiàn)協(xié)作服務？怎么知道它們在哪里，如何和它們進行通信？在慘痛的靜態(tài)拓撲中，應用將被配置為需要討論服務的URL/IPs，還將構建這些依賴服務，以“用永不失敗”但不可避免的是，它們會以一些不能接受的方式失?。ɑ虿糠质。?，但在一個彈性的環(huán)境中，下游的服務可以自動伸縮，對不同的容錯區(qū)域進行改造，或簡單地被一些自動化系統(tǒng)去除和重新啟動，這些服務的客戶端需要能夠在運行時發(fā)現(xiàn)它們，并且不管拓撲是什么樣子都可以使用它們。

這不是一個要新解決的問題，而在彈性環(huán)境中變得困難，如DNS這樣的東西是起不到作用的（除非在Kubernetes中運行）。

信任自己的服務架構

本文將最重要的考慮/問題留到最后，微服務可以快速改變系統(tǒng)架構，如果你不能信任自己的系統(tǒng)，那么你就會猶豫是否要對它進行改造，這樣就會放慢發(fā)布速度，如果部署變慢，將意味著會需要更長的周期時間，導致了可能嘗試部署更大的更改，團隊之間需要更多的協(xié)調(diào)，在扼殺企業(yè)IT能力之前，你將會覺得“這就是我們的一貫態(tài)度”，聽起來是不是很熟悉？

需要對自己的系統(tǒng)有信心，去信任它，可能有些基礎設施的復雜組合（物理/虛擬/私有云/公有云/混合云/容器），有大量的中間件、服務、框架、語言和每個服務的部署，如果一個請求是緩慢的，那么要從哪里開始呢？

在系統(tǒng)中，需要很強的“觀察性”，需要有用且有效的日志記錄、度量和跟蹤，如果快速地迭代和發(fā)布服務，需要數(shù)據(jù)驅動，理解更改的影響，回滾的意義，或者快速發(fā)布新的版本去處理負面的影響，系統(tǒng)的所有部分都需要能夠提供可靠的可觀察性（日志/指標/監(jiān)控），越是相信這些數(shù)據(jù)，越是能信任自己的服務架構，也就越有信心去根據(jù)情況進行改進。

回顧

回顧一下，當服務調(diào)用其他服務時，需要去解決的問題：

• 服務發(fā)現(xiàn)

• 自動適應路由/客戶端負載均衡

• 自動重試

• 超時控制

• 速度限制

• 指標/統(tǒng)計數(shù)據(jù)收集

• 監(jiān)控

• A/B測試

• 服務重構/請求跟蹤

• 跨服務調(diào)用的服務期限/超時執(zhí)行

• 安全服務

• 邊緣網(wǎng)關/路由器

• 強制服務隔離/離群檢測

• 內(nèi)部版本/暗啟動

解決方案

接下來看看那些巨頭公司是如何做的，如果你看看Google/Twitter / Amazon / Netflix的人解決了這個問題，你會看到它們其實很暴力的就解決了這個問題，它們基本上會說：我們將使用Java/c++/Python，兵投入數(shù)不清的強大工程力量去構建庫，以幫助開發(fā)人員去解決這個問題?！币虼薌oogle創(chuàng)建了Stubby，Twitter創(chuàng)建了Finagle，Netflix創(chuàng)建和開源了Netflix OSS等等，其他的人也都是這樣做的。

但對于其他人來說，這種方式其實存在一個重大的問題：

你并不是這些巨頭公司。

投入大量的人力資本資源去解決這些問題是不切實際的，一些對微服務感興趣的公司其實感興趣的方向是對價值和創(chuàng)新的速度，但它們并沒有專業(yè)領域的知識。

也許可以重新使用它們的解決方案？但也又引出了另外一個問題：在最后，將會得到一個非常復雜、特別、只能實現(xiàn)部分的解決方案。

舉例說明，作者與許多客戶交互的是Java商店，它們考慮解決Java服務的這個問題，很自然地，會被Netflix的OSS或Spring Cloud所吸引，但是NodeJS服務呢？Python服務呢？遺留應用呢？Perl腳本呢？

每種語言都有自己對于這些問題的實現(xiàn)，每一種都被執(zhí)行到不同的質(zhì)量，它不像抓取開源庫并將其填充到應用中那樣簡單，必須測試并且驗證每個實現(xiàn)，需要負責是不是這些庫，而是服務體系結構，可能實現(xiàn)擴散/語言/版本很快就會成為一個不可逾越的復雜性。

作者正在應用層實現(xiàn)較低級別的網(wǎng)絡功能，比較喜歡Oliver Gould在提到這些問題時（如路由、重試、限速、斷路等），這些都是5層考慮的問題觀點：

那么為什么要把這些東西復雜化？一直在試圖解決這些問題的應用通過創(chuàng)建庫（服務發(fā)現(xiàn)，跟蹤，不同的數(shù)據(jù)集合，做更復雜的路由等）和干擾到的應用空間（依賴關系、傳遞依賴庫調(diào)用等等），如果服務開發(fā)者忘記添加該實現(xiàn)的一部分（例如跟蹤），會發(fā)生什么情況？因此，每個開發(fā)者都有責任去實現(xiàn)這些功能，引入到正確的庫，在代碼中編寫它們等等。

更不用說在Java環(huán)境中使用注釋的配置去緩解這些情況的一些框架，信任、可觀察性、調(diào)試性等的目標被這樣的方法所忽略。

作者更偏愛一種能夠以更優(yōu)雅的方式去實現(xiàn)這一點：

IMHO這是服務代理/Sidecar模式可以提供幫助的地方，如果能解出這些約束條件：

• 如果有的話，將任何應用級別的感知減少到瑣碎的庫

• 在一個地方實現(xiàn)所有的這些特性，而不是散布依賴項的傾卸區(qū)

• 使可觀察性成為一流的設計目標

• 使它對包括遺留服務在內(nèi)的服務透明

• 非常低的開銷/資源影響

• 為任何或所有的語言/框架工作

• 將這些考慮因素推到較低的堆棧級別

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業(yè)資訊頻道，感謝您對億速云的支持。