微服務的性能模式

【編者按】本文做者 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