微服務架構理解及微服務架構侷限性

　　雖然微服務是下降總體結構的最佳方式。然而，它有其自身的一些缺點。但在得出任何結論以前，讓咱們來看看其中的一些。

1.開發環境超載

　　隨着應用程序及其數據庫的增加，代碼庫也在不斷擴展。隨着針對每一個微服務的代碼擴展，它會使每一個加載的應用程序的開發環境過載。這可能致使生產力的重大延遲。

2. DevOps複雜性

　　單功能微服務的開發和部署並不是易事。使用多種技術並建立API來集中系統是一項挑戰。這須要一個經驗豐富的DevOps團隊。採購這樣一個經驗豐富的DevOps團隊對於維護基於微服務的應用程序的複雜性相當重要。

3.增長資源和網絡使用

　　因爲多個組件協同工做，所以在某種程度上彼此進行通訊很是重要。此通訊將致使網絡使用量增長。這須要高速可靠的網絡鏈接。此外，運行這些應用程序的費用也會增長。全部服務都單獨運行，增長了運營成本。

4.測試

　　測試應用程序可能具備挑戰性，由於有單獨的組件。與單片應用程序相比，微服務須要更長的時間進行測試，而且在出現任何錯誤時更加複雜。有時，因爲測試最終會影響整個應用程序，可能會致使延遲。

5.安全

　　在Web應用程序方面，安全性相當重要。使用微服務，實現這一點很困難。當存在獨立模塊的集羣時，每一個模塊都須要遵照爲整個系統定義的認證和受權規範。

　　除此以外，每一個模塊可能與其餘模塊通訊，跟蹤數據流變得很是困難。須要其餘措施，例如具備負載平衡的API網關，以確保行爲一致。這些額外的步驟致使每一個微服務的開銷。

6.應用程序的複雜性

　　因爲微服務是獨立組件，所以每一個微服務一般都有一個最適合其需求的技術堆棧。例如，機器學習模塊可能使用python堆棧，而計量服務可能使用Java堆棧，UI服務可能使用MEAN堆棧。這會致使複雜性，由於資源池和管理和構建新功能所需的技能將很是高。

7.高初始投資

　　微服務獨立運行，它們須要獨立的容器或資源來運行它們。每一個項目可能有不少微服務一塊兒工做，須要更高的投資來設置包括微服務，安全容器，負載平衡器，API網關等的全部集羣。