不知道什麼是「微服務」

1樓：匿名使用者

這裡從其中一篇摘了些內容。

微服務從去年以來一直受到眾多開發者的熱捧，已經看到有許多專案嘗試使用微服務架構，結果很鼓舞人心。然而，在微服務架構帶來可獨立部署、高擴充套件與伸縮、自由選擇開發語言、高效利用資源、故障隔離等優點，同時也因為服務多帶來分散式事務、服務之間通訊、監控、部署等新的問題。

提到微服務架構時，我們常常會做的一件事情，就是會拿來與單體架構進行比較，單體架構存在如下缺點：**維護難度大，臃腫的部署，侷限的彈性與擴充套件能力，阻礙團隊與技術革新等等；微服務架構存在如下優點：**維護簡化，可獨立部署，高擴充套件與伸縮，自由選擇開發語言等優點。

上面的圖來自 martin fowler 的文章，揭示了生產率和複雜度的一個關係。在複雜度較小時採用單體應用（monolith）的生產率更高，複雜度到了一定規模時，單體應用的生產率開始急劇下降，這時對其進行微服務化的拆分才是合算的。所以說脫離業務場景，空談架構絕對是耍流氓。

異常牛逼的架構設計，如果無法在業務場景中落地實施，也只是空談。因此架構需要服務於業務，針對不同的業務場景架構設計也會不同，架構設計不必追求高大上，簡而美的架構，若能滿足業務發展需求，便是好架構。此外，好的架構不完全是設計出來的，隨著業務量、請求量的增長，好的架構是演化而來的。

微服務架構之所以得到廣泛認可，源於對於業務多變性的不可**，微服務架構能夠不斷的自演化，進而快速適應業務變化。但相對於單體架構且經過嚴格定義的大規模開發專案，微服務架構要求大家面對由眾多小型服務所構成的複雜生態系統。

鑑於此，如果長期業務規劃不需要微服務架構或者團隊不具備實施微服務一些基本的條件，不建議各位盲目邁向微服務這一新興架構領域，或者從試點入手，逐步在團隊中推行微服務架構。