「微服務架構」的話題非常之火，很多朋友都在小窗我，說怎麼做服務化？解答「怎麼做」之前，先得了解「為什麼做」。
畫外音：做技術千萬不能是這種思路，「別人都在做，所以我們也要搞」。
並不是所有的業務都適合「服務化」，網際網路高可用架構，到底為什麼要服務化？
服務化之前，高可用架構是什麼樣的？
在服務化之前，網際網路的典型高可用架構如下：
（2）後端入口，高可用的反向**nginx集群；
（3）站點應用，高可用的web-server集群；
（4）後端儲存，高可用db集群；
更典型的，web-server集群通過dao/orm等技術來訪問資料庫。
可以看到，最初是沒有服務層的，此時架構會碰到什麼典型痛點呢？
架構痛點一：**到處拷貝
舉乙個最常見的業務例子，使用者資料訪問，絕大部分公司都有乙個資料庫儲存使用者資料，各個業務都有訪問使用者資料的需求。
在有使用者服務之前，各個業務線都是自己通過dao寫sql訪問user庫來訪問使用者資料，這無形中就導致了**的拷貝。
架構痛點二：複雜性擴散
隨著併發量的越來越高，使用者資料的訪問資料庫成了瓶頸，需要加入快取來降低資料庫的讀壓力，於是架構中引入了快取，如果沒有統一的服務層，各個業務線都需要關注快取的引入導致的複雜性。
對於寫請求，所有業務線都要公升級**：
（1）先淘汰cache；
（2）再寫db；
對於讀請求，所有業務線也都要公升級**：
（1）先讀cache，命中則返回；
（2）沒命中則讀db；
（3）再把資料放入cache；
這個複雜性是典型的「業務無關」的複雜性，業務方需要被迫公升級。
隨著資料量的越來越大，資料庫需要進行水平拆分，於是架構中又引入了分庫分表，如果沒有統一的服務層，各個業務線都需要關注分庫分表的引入導致的複雜性。
這個複雜性也是典型的「業務無關」的複雜性，業務方需要被迫公升級。
典型的耦合，還包括bug的修改，發現乙個bug，多個地方都需要修改。
架構痛點三：庫的復用與耦合
服務化並不是唯一的解決上述兩痛點的方法，抽象出統一的「庫」是最先容易想到的解決（1）**拷貝；（2）複雜性擴散；的方法。
抽象出乙個user.so，負責整個使用者資料的訪問，從而避免**的拷貝。至於複雜性，也只有user.so這乙個地方需要關注了。
解決了舊的問題，會引入新的問題，庫的版本維護會導致業務線之間的耦合。
業務線a將user.so由版本1公升級至版本2，如果不相容業務線b的**，會導致b業務出現問題。
業務線a如果通知了業務線b公升級，則是的業務線b會無故做一些「自身業務無關」的公升級，非常鬱悶。當然，如果各個業務線都是拷貝了乙份**則不存在這個問題。
畫外音：有時候拷貝**也是有好處的。
架構痛點四：sql質量無法保障，業務相互影響
業務線通過dao訪問資料庫，本質上sql語句還是各個業務線拼裝的，資深的工程師寫出高質量的sql，經驗沒有這麼豐富的工程師可能會寫出一些低效的sql。
假如業務線a寫了乙個全表掃瞄的sql，導致資料庫的cpu100%，影響的不只是乙個業務線，而是所有的業務線都會受影響。
畫外音：臨時工程式設計師要背鍋了。
架構痛點五：瘋狂的db耦合
業務線不只訪問user資料，還會結合自己的業務訪問自己的資料。
畫外音：user_biz表，也是用uid做主鍵。
典型的，通過join資料表來實現各自業務線的一些業務邏輯。
業務線a的table-user與table-a耦合在了一起，業務線b的table-user與table-b耦合在了一起，業務線c的table-user與table-c耦合在了一起，結果就是：table-user，table-a，table-b，table-c都耦合在了一起。
隨著資料量的越來越大，業務線abc的資料庫是無法垂直拆分開的，必須使用乙個大庫（瘋了，乙個大庫300多個業務表 =_=）。
架構痛點六：…
網際網路高可用分層架構演進的過程中，引入了「服務層」。
以上文中的使用者業務為例，引入了高可用user-service，對業務線響應所用使用者資料的訪問。
引入服務層有什麼好處，到底解決什麼問題呢？
好處一：呼叫方爽
有服務層之前，業務方訪問使用者資料，需要通過dao拼裝sql訪問。
有服務層之後，業務方通過rpc訪問使用者資料，就像呼叫乙個本地函式一樣，非常之爽：
user = userservice::getuserbyid(uid);
傳入乙個uid，得到乙個user實體，就像呼叫本地函式一樣，不需要關心序列化，網路傳輸，後端執行，網路傳輸，範序列化等複雜性。
好處二：復用性，防止**拷貝
所有user資料的訪問，都通過user-service來進行，**只此乙份，不存在拷貝。
公升級一處公升級，bug修改一處修改。
好處三：專注性，遮蔽底層複雜度
在沒有服務層之前，所有業務線都需要關注快取、分庫分表這些細節。
在有了服務層之後，只有服務層需要專注關注底層的複雜性了，向上游遮蔽了細節。
好處四：sql質量得到保障
原來是業務向上游直接拼接sql訪問資料庫。
有了服務層之後，所有的sql都是服務層提供的，業務線不能再為所欲為了。底層服務對於穩定性的要求更好的話，可以由更資深的工程師維護，而不是像原來sql難以收口，難以控制。
好處五：資料庫解耦
原來各個業務的資料庫都混在乙個大庫里，相互join，難以拆分。
服務化之後，底層的資料庫被隔離開了，可以很方便的拆分出來，進行擴容。
好處六：提供有限介面，無限效能
在服務化之前，各業務線上游想怎麼操縱資料庫都行，遇到了效能瓶頸，各業務線容易扯皮，相互推諉。
服務化之後，服務只提供有限的通用介面，理論上服務集群能夠提供無限效能，效能出現瓶頸，服務層一處集中優化。
服務化不能解決所有問題，如果沒有碰到這些問題，架構未必需要服務化。
一切脫離業務的架構設計，都是耍流氓。
為什麼要微服務架構服務化？
微服務架構，這 5 年左右一直被認可，是軟體架構的未來方向。需要大家理解的是，為什麼需要服務化。比如微服務架構對企業來說，帶來什麼價值？有啥弊端？這裡 一下微服務架構，主要還是在理解 why 為什麼需要服務化？微服務架構，主要是多了個 微 亞馬遜有個粗粗的定義 乙個微服務應用工程的所有開發 測試 運...
為什麼使用微服務
1.單機服務 此時我們就多加了幾台web伺服器，從單機變成了乙個集群，甚至我們可以寫乙個指令碼，當web伺服器壓力過大時動態增加web伺服器。這下web伺服器的壓力不大了，我們就這樣安穩的過上了幾個月。然而有一天伺服器又出問題了 先是mysql伺服器cpu標高，然後是web伺服器宕機。此時我們會發現...
微服務為什麼要有服務發現與註冊？
前文中提到，微服務獨立部署 具有清晰的邊界，服務之間通過遠端呼叫來構建複雜的業務功能。那為什麼要引用服務註冊與發現呢？服務註冊與發現具體要解決什麼問題？服務註冊與發現主要解決了如下兩個重要問題 1 遮蔽，解耦服務之間相互依賴的細節 我們知道服務之間的遠端呼叫必須要知道對方的ip 埠資訊。我們可以在呼...