**：
【服務化之前高可用架構】
在服務化之前，網際網路的高可用架構大致是這樣乙個架構：
（ 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 ，難以拆分。
服務化之後， 底層的資料庫被隔離開了，可以很方便的拆分出來，進行擴容 。
【好處六：提供有限介面，無限效能】
在服務化之前，各業務線上游想怎麼操縱資料庫都行，遇到了效能瓶頸，各業務線容易扯皮，相互推諉。
服務化之後， 服務只提供有限的通用介面，理論上服務集群能夠提供無限效能，效能出現瓶頸，服務層一處集中優化 。
網際網路架構為什麼要做服務化？
服務化之前高可用架構 在服務化之前，網際網路的高可用架構大致是這樣乙個架構 使用者端是瀏覽器 browser 客戶端 2 後端入口是高可用的nginx集群，用於做反向 3 中間核心是高可用的web server集群，研發工程師主要編碼工作就是在這一層 4 後端儲存是高可用的db集群，資料儲存在這一層...
網際網路架構為什麼要做服務化？
1 使用者端是瀏覽器 browser 客戶端 web server 層是通過 dao orm 等技術來訪問資料庫的。各個業務線都是自己通過 dao寫 sql訪問 user 庫來訪問使用者資料，這無形中就導致了 的拷貝 發現乙個bug，多個地方都需要修改 sql 語句還是各個業務線拼裝的，資深的工程師...
網際網路架構為什麼要做服務化？
1 使用者端是瀏覽器 browser 客戶端 web server 層是通過 dao orm 等技術來訪問資料庫的。各個業務線都是自己通過 dao寫 sql訪問 user 庫來訪問使用者資料，這無形中就導致了 的拷貝 發現乙個bug，多個地方都需要修改 sql 語句還是各個業務線拼裝的，資深的工程師...