在云應(yīng)用開發(fā)時，微服務(wù)可能是開發(fā)人員最好的朋友，但他們也可能是有害的。行業(yè)專家湯姆·諾勒為此分析了人們所關(guān)注的重點。

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

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

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

通過網(wǎng)絡(luò)連接綁定其組件的任何應(yīng)用程序?qū)⒁胙舆t，如果這些組件緊密耦合在單個機器映像中，則不會出現(xiàn)延遲。因為微服務(wù)組件化應(yīng)用程序更多，它們引入更多的網(wǎng)絡(luò)綁定和潛在的更多的延遲。問題是如何最小化或補償該延遲，使得性能在微服務(wù)轉(zhuǎn)換之后可以總體上穩(wěn)定或甚至改善。

至少它是可擴展的

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

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

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

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

不要過分考慮設(shè)計

微服務(wù)設(shè)計中的一個常見錯誤是過度思考服務(wù)耦合以支持運行時綁定。SOA被設(shè)計為允許應(yīng)用程序動態(tài)地查找服務(wù)，但在大多數(shù)設(shè)施中，服務(wù)位置和工作流轉(zhuǎn)向?qū)嶋H上是相當(dāng)恒定的。這在微服務(wù)應(yīng)用中也可能是真實的，但是許多仍然設(shè)計為使用API代理來將應(yīng)用與其需要的微服務(wù)鏈接。

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

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

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

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