近期參加一些業界的技術大會，“微服務架構”的話題非常之火，也在一些場合聊過服務化架構實踐，最近幾期文章期望用通俗易懂的語言聊聊了個人對服務化以及微服務架構的了解，希望能給大夥一些啟示。如果有遺漏，也歡迎大家補充。
一、網際網路高可用架構，為什麼要服務化？
【服務化之前高可用架構】
在服務化之前，網際網路的高可用架構大緻是這樣一個架構：
（1）使用者端是浏覽器browser，APP用戶端
（2）後端入口是高可用的nginx叢集，用于做反向代理
（3）中間核心是高可用的web-server叢集，研發工程師主要編碼工作就是在這一層
（4）後端存儲是高可用的db叢集，資料存儲在這一層
更典型的，web-server層是通過DAO/ORM等技術來通路資料庫的。
可以看到，最初都是沒有服務層的，此時架構會碰到一些什麼痛點呢？
【架構痛點一：代碼到處拷貝】
舉一個最常見的業務的例子->使用者資料的通路，絕大部分公司都有一個資料庫存儲使用者資料，各個業務都有通路使用者資料的需求：
在有使用者服務之前，各個業務線都是自己通過DAO寫SQL通路user庫來存取使用者資料，這無形中就導緻了代碼的拷貝。
【架構痛點二：複雜性擴散】
随着并發量的越來越高，使用者資料的通路資料庫成了瓶頸，需要加入緩存來降低資料庫的讀壓力，于是架構中引入了緩存，由于沒有統一的服務層，各個業務線都需要關注緩存的引入導緻的複雜性：
對于使用者資料的寫請求，所有業務線都要更新代碼：
（1）先淘汰cache
（2）再寫資料
對于使用者資料的讀請求，所有業務線也都要更新代碼：
（1）先讀cache，命中則傳回
（2）沒命中則讀資料庫
（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資料，還會結合自己的業務通路自己的資料：
典型的，通過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，難以拆分。
服務化之後，底層的資料庫被隔離開了，可以很友善的拆分出來，進行擴容。
【好處六：提供有限接口，無限性能】
在服務化之前，各業務線上遊想怎麼操縱資料庫都行，遇到了性能瓶頸，各業務線容易扯皮，互相推诿。
服務化之後，服務隻提供有限的通用接口，理論上服務叢集能夠提供無限性能，性能出現瓶頸，服務層一處集中優化。
【好處七：…】
三、其他
服務化的其他好處，以及帶來的問題，歡迎大家暢所欲言，我下期再來補充。
下期和大夥聊聊怎麼“微”才是“微服務”，以及服務化的常見實踐。
幫忙随手轉發喲。
==【完】==