在云應用開發時，微服務可能是開發人員最好的朋友，但他們也可能是有害的。行業專家湯姆·諾勒為此分析了人們所關注的重點。

很少有技術工具是如此的優秀，以至于它們不能被濫用。最近行業人士對微服務的興趣已經產生了一些試驗，其中包括令人印象深刻的成功和可怕的失敗。這些試驗的目的是確保用戶的微服務和云計劃不會在性能和體驗質量（QoE）上出現歧異；了解微服務對性能的具體影響，構建基于微服務的應用程序以最大化QoE，并采取計算和網絡架構中的步驟，以最小化延遲，并最大限度地提高可用性。

在專家所提供的手冊中，探討了云計算開發中的問題和趨勢，并提供了有關開發人員如何選擇正確平臺的提示。

基于微服務的應用擴展了組件化的基本概念。它們創建了大量的功能上專用的部分，它們通過企業的網絡連接，跨應用程序共享。許多人將微服務視為面向服務的體系結構（SOA）或抽象資源和代表性狀態轉移（REST）的Web原理的應用的自然演進。其他人認為他們是利用云計算的敏捷性的一種方式。在這兩個愿景的平衡中，性能的好處和風險并存。

通過網絡連接綁定其組件的任何應用程序將引入延遲，如果這些組件緊密耦合在單個機器映像中，則不會出現延遲。因為微服務組件化應用程序更多，它們引入更多的網絡綁定和潛在的更多的延遲。問題是如何最小化或補償該延遲，使得性能在微服務轉換之后可以總體上穩定或甚至改善。

至少它是可擴展的

能夠改進微服務和云應用性能的第一個因素是微服務實例在負載下的可擴展性。正確設計的微服務可以橫向擴展，這意味著可以創建服務的其他實例，以響應工作負載。為了做到這一點，在實例之間需要用于負載平衡的機制。如果企業將微服務設計為無狀態或使用類似后端狀態控制的方式，則更容易。

這里的訣竅是將用戶的擴展工作集中于實際受益的微服務。負載平衡會引入額外的網絡處理延遲。因此，從專注于微服務開始，可以合理地縮放到四個或更多實例來證明平衡延遲。計算約束過程容易實現規模化。但是那些需要大量磁盤訪問或使用其他微服務的可能會更困難。

第二種方法是通過將數據庫訪問抽象為邏輯查詢來提高微服務和云應用程序的性能。數據庫幾乎總是托管在一個固定位置，通常位于混合云的數據中心側。訪問數據庫，然后進行網絡連接，并且如果要檢查大量記錄，則延遲可以累積。在數據庫附近托管并將高級查詢或請求而不是I/O命令作為其輸入的微服務可以顯著提高應用程序的用戶體驗質量。

雖然這些因素中的任何一個都可以改善微服務和云應用性能，但是它們可能不足以克服基本網絡延遲問題，除非優化應用設計和微服務的使用。人們已經注意到，最好的微服務是以無狀態形式開發的。因此，微服務的任何副本都可以在不使用其中保存的信息的情況下從事務對話的較早部分發出任何請求。無狀態設計經常用于Web編程，但在SOA和.NET本機開發中較為少見。開發人員可能不熟悉這些技術。開發工具和中間件可以幫助每個人加快速度和標準化方法以獲得最佳性能。

不要過分考慮設計

微服務設計中的一個常見錯誤是過度思考服務耦合以支持運行時綁定。SOA被設計為允許應用程序動態地查找服務，但在大多數設施中，服務位置和工作流轉向實際上是相當恒定的。這在微服務應用中也可能是真實的，但是許多仍然設計為使用API代理來將應用與其需要的微服務鏈接。

API代理可以提高開發敏捷性，但它們幾乎總是限制性能。如果用戶需要一個代理，請嘗試將該功能與微服務負載平衡組合。然后，用戶不必在其微服務工作流程中引入另外兩個步驟。如果用戶知道一些微服務將被大量使用，那么可以考慮將它們移到代理框架之外，并將它們作為簡單的RESTful服務發布。這將減少這些應用程序的微服務開銷，而那些被大量使用的應用程序并不真正需要運行時綁定。

要避免的另一個常見錯誤是低效的微服務結構。微服務應該足夠小，并通常有用，但不能小到將連貫的邏輯功能分解成塊。過度分割會增加延遲，用戶可能還希望避免讓微服務調用其他微服務，因為這一系列的API調用將增加延遲，這可能很難檢測，而不檢查所有微服務邏輯。

在微服務本身之外還有有用的性能增強步驟。一個值得注意的步驟是負載平衡。用戶的微服務可擴展性實踐的效率在很大程度上將取決于用戶是否可以有效地將工作分配給所有實例。然而，效率也受到用戶和負載平衡器之間，以及負載平衡器和所有微服務實例之間的網絡延遲的影響。如果用戶的微服務使用數據庫資源，那么還需要考慮這些資源的訪問延遲。所有這些都需要仔細的策略控制微服務實例的托管。這意味著用戶的DevOps或部署工具將必須實施托管和連接策略，以確保最小的延遲。

因此，微服務和云計算應用程序性能可能會提高或可能嚴重降低。微服務對性能的影響通常很難評估。這意味著用戶不僅必須在設計和初始部署期間，而且在每當對應用程序工作流或結構進行更改時，都要對其進行處理。因為問題可能隨時發生，只有仔細審查和測試才能確保在微服務和云應用程序性能方面取得成功。