微服務不是軟體工程銀彈的10個原因

peida發表於2023-05-10

hi,我是熵減,見字如面。

微服務是一種軟體架構風格,其旨在透過將應用程式拆分為小型、獨立的服務,來增強應用程式的可伸縮性、可維護性和可測試性。

雖然微服務可以為軟體開發提供許多好處,但它們並不總是適用於所有情況的最佳選擇。

換句話說,微服務架構,也不是軟體工程的銀彈。

所以,技術團隊再考慮是否使用微服務架構時,有以下10個點,是需要慎重考慮的。

增加了複雜性

世界上沒有免費的東西。實現微服務架構,需要有大量的基礎設施來配套的,譬如服務發現、負載均衡和服務間通訊等。這些機制和體系,會增加系統的複雜性,讓維護成本更高。

微服務可以解決許多問題,例如應用程式可伸縮性和可維護性,但它並不是一個單一的解決方案。它需要與其他技術和最佳實踐結合使用,例如DevOps、CI/CD和容器化。

測試更困難的

使用微服務架構時,系統的測試工作會變的更為的複雜。除了每一個服務需要必須的單獨測試外,還需要與其所依賴的其他服務一起來測試,才能最終保障系統的質量。

部署成本更高

微服務需要更多的開發、部署和測試工作,並且需要更多的伺服器資源。

對於中小型的應用程式和簡單系統,微服務架構可能過於複雜和昂貴,是不值得采用。

運維成本更高

即是每一個服務都很簡單,管理和支援一個服務,總是比管理100個服務要容易的多。

當使用微服務架構時,你就必須管理和監控多個服務,這可能會增加不少的運維資源的開銷。

在微服務架構下,開發人員仍然需要投入大量的工作,例如設計和實施服務,以及監控和故障排除。

除錯更困難了

微服務架構最大一個挑戰就是:在分散式系統中,定位和除錯系統問題時,會異常的困難。

在一個巨大的分散式的微服務系統中,要定位和識別出問題的根本原因,其困難程度是不言而喻的。譬如,需要在多個系統中去獲取資訊,再加上覆雜的呼叫關係,要理清楚後,才能做資訊的整合和串聯等。

系統時延會更高

微服務是透過網路相互通訊的,這可能會給你的系統帶來額外的時延。

所以,對於時延要求較高的場景,就需要慎重考慮微服務的呼叫層級關係和具體的程式碼實現方式,以滿足場景所需。

難以理解的系統

當系統內多個服務獨立開發和執行時,我們就很難以掌握系統整體的執行狀況了。

系統之間是如何組合的,呼叫請求是如何流轉的,資料是如何傳遞的等。

都會讓理解成本增加不少,系統變得難以掌控,可觀測性降低,分險也就增加了。

需要專職團隊

微服務並不是無代價的。

微服務架構的有效落地,需要一個具備分散式系統、網路和DevOps專業技能的團隊。

採用微服務架構需要大量的投資,例如培訓、開發、測試、部署和維護。

企業需要考慮這些成本,並權衡微服務架構的優點和缺點。

安全的問題

微服務並不是無風險的,保護微服務架構比保護單體應用更具挑戰性。

採用微服務架構可能會引入新的風險,例如服務之間的通訊問題、服務部署和版本控制問題、以及依賴關係的複雜性。這些風險需要被認真評估,並且需要採取適當的措施來減輕這些風險。

並不總是必要的

微服務並不是適用於所有團隊的。

採用微服務架構需要更高的技術能力和開發經驗。

對於一些中小型團隊或初創公司來說,可能沒有足夠的資源和技能來開發和維護微服務架構。

因此,需要根據團隊的技能和經驗,以及專案的規模和複雜度來評估,是否適合採用微服務架構。

微服務不是一個必選項,只是一個可選項而已。

最後

儘管微服務架構在很多情況下可以提供一些優勢,但也需要根據具體情況進行評估和決策。

技術團隊,需要考慮技術和業務需求,以及組織的能力和資源等多個方面,並綜合權衡微服務架構的優缺點,才能做出正確的決策。


閱讀,思考,練習,分享,日日不斷之功。

嗯,寫完了。

新的一天,加油哦 (ง •̀_•́)ง

相關文章