3分鐘乾貨之微服務架構的侷限性
雖然微服務是降低整體結構的最佳方式。然而，它有其自身的一些缺點。但在得出任何結論之前，讓我們來看看其中的一些。
1.開發環境超載
隨著應用程式及其資料庫的增長，程式碼庫也在不斷擴充套件。隨著針對每個微服務的程式碼擴充套件，它會使每個載入的應用程式的開發環境過載。這可能導致生產力的重大延遲。
- DevOps複雜性
單功能微服務的開發和部署並非易事。使用多種技術並建立API來集中系統是一項挑戰。這需要一個經驗豐富的DevOps團隊。採購這樣一個經驗豐富的DevOps團隊對於維護基於微服務的應用程式的複雜性至關重要。
3.增加資源和網路使用
由於多個元件協同工作，因此在某種程度上彼此進行通訊非常重要。此通訊將導致網路使用量增加。這需要高速可靠的網路連線。此外，執行這些應用程式的費用也會增加。所有服務都單獨執行，增加了運營成本。
4.測試
測試應用程式可能具有挑戰性，因為有單獨的元件。與單片應用程式相比，微服務需要更長的時間進行測試，並且在出現任何錯誤時更加複雜。有時，由於測試最終會影響整個應用程式，可能會導致延遲。
5.安全
在Web應用程式方面，安全性至關重要。使用微服務，實現這一點很困難。當存在獨立模組的叢集時，每個模組都需要遵守為整個系統定義的認證和授權規範。
除此之外，每個模組可能與其他模組通訊，跟蹤資料流變得非常困難。需要其他措施，例如具有負載平衡的API閘道器，以確保行為一致。這些額外的步驟導致每個微服務的開銷。
6.應用程式的複雜性
由於微服務是獨立元件，因此每個微服務通常都有一個最適合其需求的技術堆疊。例如，機器學習模組可能使用python堆疊，而計量服務可能使用Java堆疊，UI服務可能使用MEAN堆疊。這會導致複雜性，因為資源池和管理和構建新功能所需的技能將非常高。
7.高初始投資
微服務獨立執行，它們需要獨立的容器或資源來執行它們。每個專案可能有很多微服務一起工作，需要更高的投資來設定包括微服務，安全容器，負載平衡器，API閘道器等的所有叢集。