并非所有的微服務(wù)性能問題都是平等的：一些易于修復(fù)，而另一些則需要更多的努力。查看您可能遇到的八個常見問題。現(xiàn)在是時候制定一個強有力的策略來解決今天的問題并在將來減輕它們的時候了。

微服務(wù)本來可以使一切變得更快，但是對于許多Java開發(fā)人員而言，現(xiàn)實是新的復(fù)雜性層，它可能導(dǎo)致性能問題。同時，開發(fā)人員的任務(wù)越來越多，需要對性能問題進行故障排除。例如，JRebel最近的一項調(diào)查發(fā)現(xiàn)，有51％的Java開發(fā)人員在開發(fā)過程中承擔(dān)了非功能性性能要求。

第一步是找到那些性能問題。應(yīng)用程序性能監(jiān)視工具可在開發(fā)和生產(chǎn)過程中識別問題，而服務(wù)網(wǎng)格解決方案可簡化服務(wù)間通信并提供見解。測試工具著眼于微服務(wù)在負載下如何運行或失敗，而性能分析工具則插入測試環(huán)境中以評估性能問題，例如內(nèi)存泄漏和線程問題。

早期分析和優(yōu)化也很重要?？吹酱a如何與其他服務(wù)交互非常適合DevOps，幫助開發(fā)人員了解他們的工作將對生產(chǎn)產(chǎn)生的影響。

八個常見的微服務(wù)性能問題

早期分析還可以幫助開發(fā)人員確定可能的性能原因。但是，正如我們在以下示例中所示，并非所有微服務(wù)性能問題都是平等的：一些易于修復(fù)，而另一些則需要更多的努力。

1. N + 1個問題

也稱為N + 1選擇問題或N + 1查詢，當(dāng)服務(wù)從數(shù)據(jù)庫請求列表時返回該列表，該列表返回對多個行或?qū)ο螅∟）的引用，然后分別請求這N個項目中的每一個。

幸運的是，解決方案可以像更改獲取類型一樣簡單。

2.性能反模式

N + 1問題是反模式的一個例子。性能反模式通常集中在效率低下或多余的查詢上，這些查詢會在負載或規(guī)模上復(fù)合。這些性能反模式可能由于多種原因而出現(xiàn)，并且僅在特定情況下出現(xiàn)，但可能導(dǎo)致性能不佳甚至失敗。

示例包括添加超時和重試功能。從理論上講是個好主意，但是如果調(diào)用的服務(wù)非常慢并且總是觸發(fā)超時，則重試會給已經(jīng)超載的系統(tǒng)帶來額外的壓力，從而加劇延遲問題。

3.同步請求

在錯誤的情況下同步調(diào)用服務(wù)可能會導(dǎo)致嚴重的性能瓶頸，無論是對于單個服務(wù)還是對于組合的應(yīng)用程序而言。

要解決此問題，請使用異步請求，從而服務(wù)可以向另一個服務(wù)發(fā)出請求，并在該請求得到滿足時立即返回，從而允許進行更多的并發(fā)工作。但是，開發(fā)人員需要確保接收服務(wù)可以快速滿足請求，并根據(jù)需要進行擴展以處理大量請求。

4.過度活躍的服務(wù)

微服務(wù)是否收到太多無法處理的請求？在每個服務(wù)的基礎(chǔ)上限制請求或使用固定的連接限制可以幫助接收服務(wù)滿足需求。節(jié)流還可以防止活動過度的服務(wù)耗盡活動較少但同樣重要的服務(wù)。

需要進行權(quán)衡—節(jié)流將使應(yīng)用程序變慢—但它比完全失敗的應(yīng)用程序要好。

5.第三方請求

有時，第三方服務(wù)或API可能導(dǎo)致應(yīng)用程序出現(xiàn)嚴重問題，例如不可接受的延遲。這就是為什么開發(fā)人員必須了解第三方的局限性的原因，特別是在大規(guī)模情況下。

要問的問題包括：他們能否跟上預(yù)期的需求并保持績效？SLA與應(yīng)用程序本身兼容嗎？

主動的最佳實踐步驟也有幫助，例如緩存，預(yù)取或使用彈性模式來防止服務(wù)引起級聯(lián)故障。

6.應(yīng)用天花板

即使正確配置和優(yōu)化的服務(wù)也可以達到性能上限。如果所有請求都被認為是必要的并且已被優(yōu)化，但是服務(wù)的過載仍在發(fā)生，則跨其他容器的負載平衡將改善可伸縮性。值得一提的是自動縮放，通過在必要時添加和刪除容器來動態(tài)調(diào)整傳入請求的負載。

但是，請確保實現(xiàn)最大的容器數(shù)，并制定防御分布式拒絕服務(wù)（DDoS）攻擊的策略，尤其是在應(yīng)用程序位于公共云中的情況下。

此外，集群技術(shù)以及潛在地將某些服務(wù)遷移到NoSQL解決方案以實現(xiàn)比RDBMS更高的規(guī)模。但是，如果跨服務(wù)需要類似ACID的事務(wù)，則要做好準備以處理最終的一致性并補償操作。

7.數(shù)據(jù)存儲

微服務(wù)使開發(fā)人員可以靈活地在一個應(yīng)用程序中使用多個數(shù)據(jù)存儲，但是選擇錯誤的數(shù)據(jù)庫類型可能會帶來重大的性能（和金錢）后果。

在逐個服務(wù)級別上為微服務(wù)選擇數(shù)據(jù)存儲，確保每個微存儲都適合該工作。

為了處理大量快速變化的非結(jié)構(gòu)化數(shù)據(jù)，最好使用可伸縮的或無模式的NoQSL數(shù)據(jù)存儲。

對于需要數(shù)據(jù)原子性，一致性，隔離性和持久性的情況，應(yīng)使用RDBMS。

8.數(shù)據(jù)庫調(diào)用

當(dāng)服務(wù)從多個數(shù)據(jù)庫請求數(shù)據(jù)時，這些數(shù)據(jù)庫中的每個數(shù)據(jù)庫都有能力承受該請求。如果這種情況經(jīng)常發(fā)生，則將信息緩存在一個易于訪問的位置（而不是依賴于多個數(shù)據(jù)庫）可以緩解此問題。可以設(shè)置通用規(guī)則，例如時間限制和防止通話過多。

內(nèi)存緩存用于高性能和分布式系統(tǒng)中，以存儲任意數(shù)據(jù)以進行快速本地訪問。一些數(shù)據(jù)庫系統(tǒng)提供本地內(nèi)存緩存。

最后的想法

顯然，解決基于Java的微服務(wù)中的性能問題不是一項簡單的一次性任務(wù)。但是，鑒于增長和對它們的依賴性越來越大，這是一個不容忽視的大問題。

現(xiàn)在是時候制定一個強有力的策略來解決今天的問題并在將來減輕它們的時候了。