微服務架構可能并不適合于所有企業。對于那些IT資源有限的小公司來說，微服務并不可行。對于那些遺留系統運行尚可的公司來說，可能不值得嘗試將他們的系統分解為多個微服務。它甚至可能不適合于DevOps文化。

這個觀點來自于Stripe工程師Susan Fowler，她同時也是“生產就緒的微服務”的作者，前Uber公司微服務團隊的一名工程師。最近Fowler與InfoQ的Thomas Betts進行交談，提出微服務項目的最佳候選者是那些遇到了可擴展性問題的公司。微服務可以幫助管理應用，在這些應用中“可擴展性方面的局限可導致服務器性能和穩定性的問題，無法在這個應用上進行任何工作，開發者速度顯然也受到了影響”。

（巧合的是，另外一位Fowler——Martin Fowler早在2014年為微服務奠定了基礎，包括對微服務進行定義：“微服務架構是一種把單一應用作為一套小型服務進行開發的方法，每個微服務都運行著它自己的進程，與輕量級機制——通常是HTTP資源API——進行通信”。）

對于很多組織機構來說，要想實現一個運行良好的微服務架構也許并不困難。“大多數系統并不是以考慮微服務架構而設計的，”Susan Fowler這樣表示。因此，很多微服務最終被設計成了獨立于孤島環境，或者孤島環境中的孤島。

據Fowler的觀察，微服務也不一定能與DevOps環境很好地融合。特別是在大型數據中心內，開發工作和運營工作顯然是分離的。然而在微服務架構中，“會有數十個、數百個甚至數千個微服務，因此，許多微服務開發團隊，以及這些團隊中既是開發者又是運營工程師的工作人員可能從組織架構上來說都是沒有意義的。”

但是，微服務架構也需要很好地適應所在的組織機構。在另外一篇博客文章中，Fowler主張采取一種四層方法：

硬件層：配置管理工具、數據據、服務器、主機層日志記錄和監控、操作系統、資源隔離、資源抽象。

通信層：DNS端點、負載均衡、通訊、網絡、遠程過程調用、服務發現、服務注冊。

應用層：部署管道、開發環境、微服務層日志記錄和監控、自助服務式內部開發工具、測試、包、構建和發布工具。

原文出處：科技行者 轉載請與作者聯系，同時請務必標明文章原始出處和原文鏈接及本聲明。 《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的微服务架构可能不适合所有企业的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。