【編者按】本文作者 Rohit Dhall 是一名企業(yè)架構(gòu)師，目前就職于 HCL 科技公司。 Rohit 擁有 18 年的 IT 工作經(jīng)驗，熟悉 Java/J2ee 、 P2P 、 DWH 、SOA 等技術(shù)。本文介紹了五種微服務(wù)系統(tǒng)常見的性能挑戰(zhàn)，并探討了相應(yīng)的解決策略。
本文系 OneAPM 工程師編譯呈現(xiàn)，以下為正文。
在IT基礎(chǔ)設(shè)施中，基于微服務(wù)架構(gòu)的系統(tǒng)變得越來越受歡迎，在這種架構(gòu)中，但凡與業(yè)務(wù)相關(guān)的功能都會由多于一個的應(yīng)用組成，但是對于整個集成系統(tǒng)的性能而言，這種集成也帶來了巨大的挑戰(zhàn)。在基于微服務(wù)的系統(tǒng)中，功能通過多個服務(wù)組合提供，因此存在大量的集成點(diǎn)和接觸點(diǎn)。這反過來也加重了性能負(fù)擔(dān)，甚至?xí)绊懴到y(tǒng)的整體表現(xiàn)。本文主要討論一些微服務(wù)系統(tǒng)所面臨的關(guān)鍵性能挑戰(zhàn)，同時也向大家介紹一些能夠幫助大家解決問題的技術(shù)和模式。
集成系統(tǒng)所面臨的挑戰(zhàn)
分布式計算本來就有其自身的挑戰(zhàn)，所有這些挑戰(zhàn)不僅有據(jù)可查，而在分布式系統(tǒng)上工作的專業(yè)人士幾乎每天都在為之困擾，尤其在集成環(huán)境中接觸點(diǎn)超過了「正?！辜森h(huán)境時，情形則會更加糟糕。當(dāng)連接到應(yīng)用內(nèi)部或者遠(yuǎn)程外部系統(tǒng)中其他微服務(wù)時，很多環(huán)節(jié)都可能出錯。例如，被連接的微服務(wù)可能非常緩慢或宕機(jī)，那么如果應(yīng)用程序沒有提前設(shè)計好如何處理這種情況，將會對程序的性能和穩(wěn)定性產(chǎn)生不利影響。
緩解性能挑戰(zhàn)
在本節(jié)中，筆者將討論一些方法和設(shè)計策略，幫助在基于微服務(wù)的環(huán)境中實現(xiàn)更好的性能，增強(qiáng)系統(tǒng)的彈性和整體穩(wěn)定性。
節(jié)流模式
節(jié)流是一種用于規(guī)避異常應(yīng)用的技術(shù)，當(dāng)異常應(yīng)用發(fā)送的請求超過應(yīng)用程序的處理負(fù)載時，可能導(dǎo)致系統(tǒng)過載甚至崩潰。
一個實現(xiàn)節(jié)流的簡單方法是限定單個應(yīng)用程序的連接數(shù)。假設(shè)有兩個廠商調(diào)用微服務(wù)從賬戶中取錢。其中一個供應(yīng)商是像亞馬遜那樣龐大的應(yīng)用，那么它調(diào)用應(yīng)用的次數(shù)要比擁有小眾群體的供應(yīng)商多的多。因此，可以提供這兩家廠商兩個獨(dú)立的專用「入口點(diǎn)」，通過節(jié)流進(jìn)行連接限制。這樣，大量來自亞馬遜的請求就不會妨礙第二個供應(yīng)商的請求。此外，也可以限制各個協(xié)作對象的請求頻率，這樣發(fā)送請求的速度就不會超過微服務(wù)的處理速度了。
一般情況下，來自外部服務(wù)/系統(tǒng)的同步請求會通過負(fù)載均衡器、 HTTP 服務(wù)器或其他類似的入口點(diǎn)進(jìn)行節(jié)流限制。
超時
如果請求的微服務(wù)響應(yīng)緩慢，會使得應(yīng)用需要花費(fèi)很長時間才能完成一個請求，應(yīng)用線程在很長的時間內(nèi)都處于忙碌狀態(tài)。這會對應(yīng)用程序產(chǎn)生級聯(lián)影響，導(dǎo)致應(yīng)用或服務(wù)器完全堵塞甚至失去響應(yīng)。
大多數(shù)庫(libraries)、 API 、框架和服務(wù)器都為各種特定的請求超時提供配置，只需設(shè)置讀寫請求超時、等待超時、連接池等待超時、活躍會話超時等的數(shù)值即可，但這些超時需要通過適當(dāng)?shù)男阅軠y試或 SLA 驗證才能確定。
專用線程池
另一個重要的設(shè)計是將不同的任務(wù)請求或不同的微服務(wù)連接放到獨(dú)立的線程池中，就像Bulkheads那樣對資源進(jìn)行隔離。大家不妨設(shè)想一下這樣的場景，在應(yīng)用流中需要使用 REST 通過 HTTP 連接五個不同的微服務(wù)，也可以使用一個普通的線程池去維持這些連接，如果其中某個服務(wù)因為某種原因出現(xiàn)異常，那么池內(nèi)所有的微服務(wù)都會受到牽連。為了最大限度地減少這種異常的負(fù)面影響，將單獨(dú)的服務(wù)放進(jìn)專門的線程池顯然是更明智的做法。這不僅可以減少某個異常對其他服務(wù)的影響，還能保證應(yīng)用程序的其他部分繼續(xù)正常地工作。
這種模式通常被稱為Bulkheads模式。下圖描述了該模式的示例場景：在左側(cè)，微服務(wù) A 用同一個連接池去請求 X 和 Y 兩個服務(wù)。如果服務(wù) X 或 Y 其中任何一個行為異常，都將影響連接池的整體表現(xiàn)。如果采用Bulkheads模式，如該圖右側(cè)所示，即使微服務(wù) X 被錯誤操作，也只有 X 池受到影響，微服務(wù) Y 還可以繼續(xù)正常地為應(yīng)用程序提供服務(wù)。
Circuit Breakers
Circuit Breakers是一種設(shè)計模式，可以用來減少任何下游不可訪問或故障對系統(tǒng)整體的影響。Circuit Breakers用于檢查外部系統(tǒng)/服務(wù)的可用性，一旦外部系統(tǒng)或服務(wù)宕機(jī)，應(yīng)用程序就可以避免再次發(fā)送請求到這些外部系統(tǒng)。這種做法其實也是一種安全措施，可以避免超時或Bulkheads模式因某些故障而導(dǎo)致的不必要超時。如果下游系統(tǒng)宕機(jī)，請求就沒必要一直等待直至響應(yīng)超時，之后再收到超時異常的響應(yīng)。相反，當(dāng)下游系統(tǒng)處于宕機(jī)過程時，Circuit Breakers讓請求不再嘗試連接，進(jìn)而大大地縮減了響應(yīng)時間。
Circuit Breakers有內(nèi)置的邏輯來對外部系統(tǒng)進(jìn)行必要的健康檢查，從而確保這些系統(tǒng)正常工作后再開始轉(zhuǎn)發(fā)請求。
異步集成
解耦各個微服務(wù)之間的通信可以避免多數(shù)的集成性能問題，異步集成方法是一種解耦機(jī)制。如果系統(tǒng)是基于微服務(wù)系統(tǒng)設(shè)計的，而且各個微服務(wù)之間都是點(diǎn)到點(diǎn)的集成，那就需要認(rèn)真思考如何實現(xiàn)解耦了。任何標(biāo)準(zhǔn)的消息代理系統(tǒng)都可用于提供發(fā)布—訂閱功能。
總結(jié)
本文主要向大家介紹了集成到基于微服務(wù)的框架系統(tǒng)所面臨的一些性能挑戰(zhàn)，同時也提出了一些幫助大家避免上述的性能問題的系統(tǒng)模式，簡而言之，在考慮模式時，異步集成的方法應(yīng)該是首選，而其他設(shè)計模式可以根據(jù)具體的集成場景進(jìn)行選擇，從而避免下游系統(tǒng)異常引起的級聯(lián)副作用，幫助大家更好地解決集成系統(tǒng)的性能挑戰(zhàn)。
OneAPM 為您提供端到端的 Java 應(yīng)用性能解決方案，我們支持所有常見的 Java 框架及應(yīng)用服務(wù)器，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，Java 監(jiān)控從來沒有如此簡單。想閱讀更多技術(shù)文章，請訪問 OneAPM官方技術(shù)博客 。
本文轉(zhuǎn)自 OneAPM 官方博客
原文鏈接：https://dzone.com/articles/performance-patterns-in-microservices-based-integr
