微服務的效能模式

【編者按】本文作者 Rohit Dhall 是一名企業架構師，目前就職於 HCL 科技公司。 Rohit 擁有 18 年的 IT 工作經驗，熟悉 Java/J2ee 、 P2P 、 DWH 、SOA 等技術。本文介紹了五種微服務系統常見的效能挑戰，並探討了相應的解決策略。

本文系 OneAPM 工程師編譯呈現，以下為正文。

在IT基礎設施中，基於微服務架構的系統變得越來越受歡迎，在這種架構中，但凡與業務相關的功能都會由多於一個的應用組成，但是對於整個整合系統的效能而言，這種整合也帶來了巨大的挑戰。在基於微服務的系統中，功能通過多個服務組合提供，因此存在大量的整合點和接觸點。這反過來也加重了效能負擔，甚至會影響系統的整體表現。本文主要討論一些微服務系統所面臨的關鍵效能挑戰，同時也向大家介紹一些能夠幫助大家解決問題的技術和模式。

整合系統所面臨的挑戰

分散式計算本來就有其自身的挑戰，所有這些挑戰不僅有據可查，而在分散式系統上工作的專業人士幾乎每天都在為之困擾，尤其在整合環境中接觸點超過了「正常」整合環境時，情形則會更加糟糕。當連線到應用內部或者遠端外部系統中其他微服務時，很多環節都可能出錯。例如，被連線的微服務可能非常緩慢或當機，那麼如果應用程式沒有提前設計好如何處理這種情況，將會對程式的效能和穩定性產生不利影響。

緩解效能挑戰

在本節中，筆者將討論一些方法和設計策略，幫助在基於微服務的環境中實現更好的效能，增強系統的彈性和整體穩定性。

節流模式

節流是一種用於規避異常應用的技術，當異常應用傳送的請求超過應用程式的處理負載時，可能導致系統過載甚至崩潰。

一個實現節流的簡單方法是限定單個應用程式的連線數。假設有兩個廠商呼叫微服務從賬戶中取錢。其中一個供應商是像亞馬遜那樣龐大的應用，那麼它呼叫應用的次數要比擁有小眾群體的供應商多的多。因此，可以提供這兩家廠商兩個獨立的專用「入口點」，通過節流進行連線限制。這樣，大量來自亞馬遜的請求就不會妨礙第二個供應商的請求。此外，也可以限制各個協作物件的請求頻率，這樣傳送請求的速度就不會超過微服務的處理速度了。

一般情況下，來自外部服務/系統的同步請求會通過負載均衡器、 HTTP 伺服器或其他類似的入口點進行節流限制。

超時

如果請求的微服務響應緩慢，會使得應用需要花費很長時間才能完成一個請求，應用執行緒在很長的時間內都處於忙碌狀態。這會對應用程式產生級聯影響，導致應用或伺服器完全堵塞甚至失去響應。

大多數庫(libraries)、 API 、框架和伺服器都為各種特定的請求超時提供配置，只需設定讀寫請求超時、等待超時、連線池等待超時、活躍會話超時等的數值即可，但這些超時需要通過適當的效能測試或 SLA 驗證才能確定。

專用執行緒池

另一個重要的設計是將不同的任務請求或不同的微服務連線放到獨立的執行緒池中，就像Bulkheads那樣對資源進行隔離。大家不妨設想一下這樣的場景，在應用流中需要使用 REST 通過 HTTP 連線五個不同的微服務，也可以使用一個普通的執行緒池去維持這些連線，如果其中某個服務因為某種原因出現異常，那麼池內所有的微服務都會受到牽連。為了最大限度地減少這種異常的負面影響，將單獨的服務放進專門的執行緒池顯然是更明智的做法。這不僅可以減少某個異常對其他服務的影響，還能保證應用程式的其他部分繼續正常地工作。

這種模式通常被稱為Bulkheads模式。下圖描述了該模式的示例場景：在左側，微服務 A 用同一個連線池去請求 X 和 Y 兩個服務。如果服務 X 或 Y 其中任何一個行為異常，都將影響連線池的整體表現。如果採用Bulkheads模式，如該圖右側所示，即使微服務 X 被錯誤操作，也只有 X 池受到影響，微服務 Y 還可以繼續正常地為應用程式提供服務。

Circuit Breakers

Circuit Breakers是一種設計模式，可以用來減少任何下游不可訪問或故障對系統整體的影響。Circuit Breakers用於檢查外部系統/服務的可用性，一旦外部系統或服務當機，應用程式就可以避免再次傳送請求到這些外部系統。這種做法其實也是一種安全措施，可以避免超時或Bulkheads模式因某些故障而導致的不必要超時。如果下游系統當機，請求就沒必要一直等待直至響應超時，之後再收到超時異常的響應。相反，當下遊系統處於當機過程時，Circuit Breakers讓請求不再嘗試連線，進而大大地縮減了響應時間。

Circuit Breakers有內建的邏輯來對外部系統進行必要的健康檢查，從而確保這些系統正常工作後再開始轉發請求。

非同步整合

解耦各個微服務之間的通訊可以避免多數的整合效能問題，非同步整合方法是一種解耦機制。如果系統是基於微服務系統設計的，而且各個微服務之間都是點到點的整合，那就需要認真思考如何實現解耦了。任何標準的訊息代理系統都可用於提供釋出—訂閱功能。

總結

本文主要向大家介紹了整合到基於微服務的框架系統所面臨的一些效能挑戰，同時也提出了一些幫助大家避免上述的效能問題的系統模式，簡而言之，在考慮模式時，非同步整合的方法應該是首選，而其他設計模式可以根據具體的整合場景進行選擇，從而避免下游系統異常引起的級聯副作用，幫助大家更好地解決整合系統的效能挑戰。

OneAPM 為您提供端到端的 Java 應用效能解決方案，我們支援所有常見的 Java 框架及應用伺服器，助您快速發現系統瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，Java 監控從來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM官方技術部落格 。 本文轉自 OneAPM 官方部落格 原文連結：https://dzone.com/articles/performance-patterns-in-microservices-based-integr