微服務優缺點

Ⅰ 什麼是微服務

「Mesh App and Service Architecture」作為Gartner2016 十大戰略技術趨勢中之一，裡面大量提到微服務的概念。微服務（Microservices）這個概念不是新概念，很多公司已經在實踐了，例如Google、Netflix、Facebook、Twiter、Alibaba。微服務架構模式（Microservices Architecture Pattern）的目的是將大型的、復雜的、長期運行的應用程序構建為一組相互配合的服務，每個服務都可以很容易得局部改良。

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

提到微服務架構時，我們常常會做的一件事情，就是會拿來與單體架構進行比較，單體架構存在如下缺點：代碼維護難度大，臃腫的部署，局限的彈性與擴展能力，阻礙團隊與技術革新等等；微服務架構存在如下優點：代碼維護簡化，可獨立部署，高擴展與伸縮，自由選擇開發語言等優點。那麼單體架構真的如此不堪一擊嗎？答案顯然不是這樣，下面我們來看Martin Fowler在其一篇文章裡面給出關系圖：

上面的圖來自 Martin Fowler 的文章，揭示了生產率和復雜度的一個關系。在復雜度較小時採用單體應用（Monolith）的生產率更高，復雜度到了一定規模時，單體應用的生產率開始急劇下降，這時對其進行微服務化的拆分才是合算的。所以說脫離業務場景，空談架構絕對是耍流氓。異常牛逼的架構設計，如果無法在業務場景中落地實施，也只是空談。因此架構需要服務於業務，針對不同的業務場景架構設計也會不同，架構設計不必追求高大上，簡而美的架構，若能滿足業務發展需求，便是好架構。此外，好的架構不完全是設計出來的，隨著業務量、請求量的增長，好的架構是演化而來的。微服務架構之所以得到廣泛認可，源於對於業務多變性的不可預測，微服務架構能夠不斷的自演化，進而快速適應業務變化。但相對於單體架構且經過嚴格定義的大規模開發項目，微服務架構要求大家面對由眾多小型服務所構成的復雜生態系統。

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

Ⅱ 微服務架構的優缺點是什麼

Ⅲ 微服務的優點

微服務是指提供單個業務功能的服務，從技術角度看就是一種小而獨立的處理過程，類似流程概念，能夠自行單獨啟動或銷毀，擁有自己獨立的資料庫。

一個復雜軟體架構是由很多這樣小而獨立運行（有自己的埠）微服務組成，這些獨立處理組件之間通訊是通過與語言無關的API進行，簡單協議有同步性質的RMI/RPC和 RESTful Web Services，非同步的消息推送和Reactive方式。

這些模塊化的方式能夠使得公司將項目分解分散到多個開發團隊，跨不同業務部門，提供非常充分的靈活性，幫助提高項目的生命周期，加快項目開發完成效率。

每個微服務組件都有自己分配的存儲 內存和CPU資源，這就使得硬體利用更加易於優化和跟蹤，特別是在基於雲的Pass環境，開發團隊可以使用他們喜歡的技術，任何語言都可以，只要確保微服務之間是可交互的，能夠最終組合起最後的應用。

當管理復雜性會因為採取微服務架構而降低，通常更新其中一個微服務組件不會引起連鎖反應，因為微服務之間是松耦合的。

目前使用微服務的企業有：Netflix Twitter Amazon Web Services (AWS), Google, eBay等。

因為有很多應用和服務部署在基於雲主機的環境中，微服務架構將會嚴重依賴容器技術，容器隔離了微服務處理過程，將一個應用切分為一個個小的實例，這些容器中的小實例有自己的埠和虛擬化環境。

廣泛使用的容器技術是Docker, 一種基於Linux的開源實現，由很多軟體公司支持如 Canonical, Red Hat,和Parallels. PaaS服務支持包括Google App Engine, Red Hat Open Shift,和VMware的 Cloud Foundry,。