微服務架構，這 5 年左右一直被認可，是軟體架構的未來方向。需要大家理解的是，為什麼需要服務化。比如微服務架構對企業來說，帶來什麼價值？有啥弊端？
這裡**一下微服務架構，主要還是在理解 why ：為什麼需要服務化？
微服務架構，主要是多了個 「微」。亞馬遜有個粗粗的定義：乙個微服務應用工程的所有開發、測試、運維加起來大約 6 到 8 個人，只需要兩個披薩就可以聚餐了。
反例：不是乙個 service 類組成的應用工程，發布成服務就是微服務。這樣分的太小，理解微服務就很片面。杭州某金融大廠，曾經分的很細，造成了運維測試成本巨大。開始分了合，折騰...
由 soa 架構 -> 微服務架構的轉變，得理解為什麼微服務架構被廣泛提到並實踐。它解決了什麼問題，帶來了什麼價值？
傳統企業或者很多企業的軟體，大多不止一套系統，都是各個獨立大系統的堆砌。整體存在的問題是：
那麼這些問題，可以想到的解決方案就是：
微服務架構，將各個元件或者模組分散到各個服務中，對整個系統實現解耦。那微服務架構強調的重中之重就是業務系統需要完善的元件化和服務化。什麼是元件化？
元件化，即將乙個大系統，按照一定的業務或者技術維度關注形式，拆分成獨立的元件。目的是為了分而治之，為了可重用，為了減少耦合度。比如按照技術維度：搜尋元件、快取元件；按照業務維度：使用者中心、支付中心等
元件化是不是有點中颱的意思？阿里巴巴提出 大中台，小前台；就是把元件化、外掛程式化、服務化解決方案到極致。通過產品線公共業務或者技術下沉，形成各種技術或者業務中臺
（圖來自漫畫程式設計師小灰）
分布式，就是多個例項提供相同的服務。比如多個地方動車站裡面，多個機器提供取票服務。多個地方，北京上海等，就是多機房，多個取票服務一起組成了集群，形成分布式服務。那啥是服務化？
服務化，強調 「化」！核心就是不同服務之間的通訊。是一種以服務為中心的解決方案：
沒有服務化前，舉個例子，會更形象：
假設有個取票服務、買票服務、改座服務都需要驗證下使用者身份真實性，那麼會存在下面的問題：
明顯的問題是：
自然也有解決方案是：lib。維護乙個 user-dao-lib 1.0.0 release 包，給各個業務方。
解決了問題，引入了新的問題，lib 公升級是巨大而又漫長的問題。比如小李是維護 user-dao-lib 的人，有一次寫了隱蔽的 bug 。user-lib 公升級到了 1.0.1 release，花了 1 個月左右時間，推幾十個業務方公升級完畢。然後這個 bug 執行了幾天出現了，考慮公升級fix或者回滾都是巨大的成本
基於服務化，就可以完美解決問題。
服務化後的好處：
1、本身不大的系統，業務不複雜的系統也不需要微服務架構。微服務架構會帶來一定的複雜性，是一套完整的服務治理方案
2、多個模組資料庫，分布式事務是乙個挑戰
3、開發過程，增加了測試等一定的複雜性
有利必有弊，具體場景具體選擇
本小結，不是講how，講的是 why。只有懂 why ，才能更好地 do。從為啥服務化？到為啥微服務架構這麼流行：
參考資料
網際網路架構，究竟為啥要做服務化？
微服務
為什麼要微服務（服務化）？
微服務架構 的話題非常之火，很多朋友都在小窗我，說怎麼做服務化？解答 怎麼做 之前，先得了解 為什麼做 畫外音 做技術千萬不能是這種思路，別人都在做，所以我們也要搞 並不是所有的業務都適合 服務化 網際網路高可用架構，到底為什麼要服務化？服務化之前，高可用架構是什麼樣的？在服務化之前，網際網路的典型...
為什麼使用微服務
1.單機服務 此時我們就多加了幾台web伺服器，從單機變成了乙個集群，甚至我們可以寫乙個指令碼，當web伺服器壓力過大時動態增加web伺服器。這下web伺服器的壓力不大了，我們就這樣安穩的過上了幾個月。然而有一天伺服器又出問題了 先是mysql伺服器cpu標高，然後是web伺服器宕機。此時我們會發現...
什麼是微服務架構？
微服務架構是解決企業 it 長期演進的一種方案，適用於迭代很快的系統，10年不變的系統就算了。簡述 martin flower 大神的系統闡述 微服務是一種架構風格，也是一種服務 微服務的顆粒比較小，乙個大型複雜軟體應用由多個微服務組成，比如netflix目前由500多個的微服務組成 它採用unix...