| 導讀 | 微服務架構是一項在雲中部署應用和服務的新技術。大部分圍繞微服務的爭論都集中在容器或其餘技術是否能很好的實施微服務，而紅帽說API應該是重點。 |
對微服務架構的理解linux
微服務架構數據庫
微服務架構，主要是多了個 「微」。亞馬遜有個粗粗的定義：一個微服務應用工程的全部開發、測試、運維加起來大約 6 到 8 我的，只須要兩個披薩就能夠聚餐了。緩存
反例：不是一個 Service 類組成的應用工程，發佈成服務就是微服務。這樣分的過小，理解微服務就很片面。杭州某金融大廠，曾經分的很細，形成了運維測試成本巨大。開始分了合，折騰…架構
爲啥須要微服務？負載均衡
由 SOA 架構 -> 微服務架構的轉變，得理解爲何微服務架構被普遍提到並實踐。它解決了什麼問題，帶來了什麼價值？運維
傳統企業或者不少企業的軟件，大多不止一套系統，都是各個獨立大系統的堆砌。總體存在的問題是：分佈式
擴展性差ide
可靠性不高微服務
維護成本還很大組件化
重複輪子不少
那麼這些問題，能夠想到的解決方案就是：
組件化
服務化
微服務架構，將各個組件或者模塊分散到各個服務中，對整個系統實現解耦。那微服務架構強調的重中之重就是業務系統須要完善的組件化和服務化。什麼是組件化？
組件化，即將一個大系統，按照必定的業務或者技術維度關注形式，拆分紅獨立的組件。目的是爲了分而治之，爲了可重用，爲了減小耦合度。好比按照技術維度：搜索組件、緩存組件；按照業務維度：用戶中心、支付中心等
組件化是否是有點中臺的意思？阿里巴巴提出 大中臺，小前臺；就是把組件化、插件化、服務化解決方案到極致。經過產品線公共業務或者技術下沉，造成各類技術或者業務中臺
服務化前的問題
沒有服務化，不表明不是分佈式或集羣
分佈式，就是多個實例提供相同的服務。好比多個地方動車站裏面，多個機器提供取票服務。多個地方，北京上海等，就是多機房，多個取票服務一塊兒組成了集羣，造成分佈式服務。那啥是服務化？
服務化，強調 「化」！核心就是不一樣服務之間的通訊。是一種以服務爲中心的解決方案：
服務註冊
服務發佈
服務調用
服務監控
服務負載均衡
沒有服務化的架構問題
沒有服務化前，舉個例子，會更形象：
假設有個取票服務、買票服務、改座服務都須要驗證下用戶身份真實性，那麼會存在下面的問題：
取票服務 -> 調用用戶DB代碼 -> 用戶DB
買票服務 -> 調用用戶DB代碼 -> 用戶DB
改座服務 -> 調用用戶DB代碼 -> 用戶DB
明顯的問題是：
代碼重複：不一樣業務相同訪問 DB 的 userDAO 代碼邏輯。並且每一個服務這塊代碼是不一樣人維護的。
可維護性低：不一樣人維護；不一樣地方維護；每次 DB 字段改變或者遷庫，所有業務都有修改
DB 訪問耦合
天然也有解決方案是：lib。維護一個 user-DAO-lib 1.0.0 release 包，給各個業務方。
解決了問題，引入了新的問題，lib 升級是巨大而又漫長的問題。好比小李是維護 user-DAO-lib 的人，有一次寫了隱蔽的 bug 。user-lib 升級到了 1.0.1 release，花了 1 個月左右時間，推幾十個業務方升級完畢。而後這個 bug 運行了幾天出現了，考慮升級fix或者回滾都是巨大的成本
基於服務化，就能夠完美解決問題。
服務化後的好處
如圖 Post 文章服務調用 Video 視頻服務，須要經過最上層的 Service 之間相互調用。服務化明顯改變：
DB 隔離：這樣底層細節設計能夠屏蔽，後續加上其餘存儲 Cache 等對業務調用方無感知。
經過 Service 之間通訊：具體協議能夠 RPC / HTTP 等
服務化後的好處：
調用簡單：不用寫相同的訪問用戶服務代碼，調用一個服務便可
代碼複用：跟 lib 形式的代碼複用有所區別在於，服務化經過通訊的方式解決
業務隔離
數據庫解耦
不能否認的微服務架構或者服務化帶來新的問題
一、自己不大的系統，業務不復雜的系統也不須要微服務架構。微服務架構會帶來必定的複雜性，是一套完整的服務治理方案
二、多個模塊數據庫，分佈式事務是一個挑戰
三、開發過程，增長了測試等必定的複雜性
有利必有弊，具體場景具體選擇
小結
本小結，不是講how，講的是 why。只有懂 why ，才能更好地 do。從爲啥服務化？到爲啥微服務架構這麼流行：
微服務擴展性高
微服務可靠性高
微服務 維護成本小
微服務幾乎沒有重複輪子
微服務直接調用調用簡單
微服務業務隔離
微服務數據庫解耦Linux就該這麼學