什麽是微服務
“Mesh App and Service Architecture”作為Gartner2016 十大戰略技術趨勢中之壹，裏面大量提到微服務的概念。微服務（Microservices）這個概念不是新概念，很多公司已經在實踐了，例如Google、Netflix、Facebook、Twiter、Alibaba。微服務架構模式（Microservices Architecture Pattern）的目的是將大型的、復雜的、長期運行的應用程序構建為壹組相互配合的服務，每個服務都可以很容易得局部改良。
微服務從去年以來壹直受到眾多開發者的熱捧，已經看到有許多項目嘗試使用微服務架構，結果很鼓舞人心。然而，在微服務架構帶來可獨立部署、高擴展與伸縮、自由選擇開發語言、高效利用資源、故障隔離等優點，同時也因為服務多帶來分布式事務、服務之間通信、監控、部署等新的問題。
提到微服務架構時，我們常常會做的壹件事情，就是會拿來與單體架構進行比較，單體架構存在如下缺點：代碼維護難度大，臃腫的部署，局限的彈性與擴展能力，阻礙團隊與技術革新等等；微服務架構存在如下優點：代碼維護簡化，可獨立部署，高擴展與伸縮，自由選擇開發語言等優點。那麽單體架構真的如此不堪壹擊嗎？答案顯然不是這樣，下面我們來看Martin Fowler在其壹篇文章裏面給出關系圖：
上面的圖來自 Martin Fowler 的文章，揭示了生產率和復雜度的壹個關系。在復雜度較小時采用單體應用（Monolith）的生產率更高，復雜度到了壹定規模時，單體應用的生產率開始急劇下降，這時對其進行微服務化的拆分才是合算的。所以說脫離業務場景，空談架構絕對是耍流氓。異常牛逼的架構設計，如果無法在業務場景中落地實施，也只是空談。因此架構需要服務於業務，針對不同的業務場景架構設計也會不同，架構設計不必追求高大上，簡而美的架構，若能滿足業務發展需求，便是好架構。此外，好的架構不完全是設計出來的，隨著業務量、請求量的增長，好的架構是演化而來的。微服務架構之所以得到廣泛認可，源於對於業務多變性的不可預測，微服務架構能夠不斷的自演化，進而快速適應業務變化。但相對於單體架構且經過嚴格定義的大規模開發項目，微服務架構要求大家面對由眾多小型服務所構成的復雜生態系統。
鑒於此，如果長期業務規劃不需要微服務架構或者團隊不具備實施微服務壹些基本的條件，不建議各位盲目邁向微服務這壹新興架構領域，或者從試點入手，逐步在團隊中推行微服務架構。