[b]網際網路高可用架構為什麼要服務化？[/b]
【服務化之前高可用架構】
在服務化之前，網際網路的高可用架構大致是這樣乙個架構：
（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多個業務表 =_=）。
[b]服務化解決什麼問題？[/b]
為了解決上面的諸多問題，網際網路高可用分層架構演進的過程中，引入了「服務層」。
以上文中的使用者業務為例，引入了user-service，對業務線響應所用使用者資料的訪問。引入服務層有什麼好處，解決什麼問題呢？
【好處一：呼叫方爽】
有服務層之前：業務方訪問使用者資料，需要通過dao拼裝sql訪問
有服務層之後：業務方通過rpc訪問使用者資料，就像呼叫乙個本地函式一樣，非常之爽
user = userservice::getuserbyid(uid);
傳入乙個uid，得到乙個user實體，就像呼叫本地函式一樣，不需要關心序列化，網路傳輸，後端執行，網路傳輸，範序列化等複雜性。
【好處二：復用性，防止**拷貝】
這個不展開敘述，所有user資料的訪問，都通過user-service來進行，**只此乙份，不存在拷貝。
公升級一處公升級，bug修改一處修改。
【好處三：專注性，遮蔽底層複雜度】
在沒有服務層之前，所有業務線都需要關注快取、分庫分表這些細節。
在有了服務層之後，只有服務層需要專注關注底層的複雜性了，向上游遮蔽了細節。
【好處四：sql質量得到保障】
原來是業務向上游直接拼接sql訪問資料庫。
有了服務層之後，所有的sql都是服務層提供的，業務線不能再為所欲為了。底層服務對於穩定性的要求更好的話，可以由更資深的工程師維護，而不是像原來sql難以收口，難以控制。
【好處五：資料庫解耦】
原來各個業務的資料庫都混在乙個大庫里，相互join，難以拆分。
服務化之後，底層的資料庫被隔離開了，可以很方便的拆分出來，進行擴容。
【好處六：提供有限介面，無限效能】
在服務化之前，各業務線上游想怎麼操縱資料庫都行，遇到了效能瓶頸，各業務線容易扯皮，相互推諉。
服務化之後，服務只提供有限的通用介面，理論上服務集群能夠提供無限效能，效能出現瓶頸，服務層一處集中優化。
網際網路架構
網際網路架構，主要追求的是高可用，可擴充套件 這兩個特性 在這裡做了一些個人的總結，算是給2014年的工作做個總結。推陳出新 一定要做的，死守積累會逐漸丟失人才，但凡技術公司都會不斷更新技術 kiss原則 keep it stupid優秀的 都會很簡單，簡單理解，簡單更改，能把複雜的事情做簡單是一種...
網際網路架構
使用者在同一時間內大量的訪問伺服器，tomcat伺服器併發能力為 200 250左右 jvm調優為1000 硬體條件 物理伺服器處理能力 網路頻寬 2.1 分布式計算 由多個執行緒，共同來完成某項特定的任務，拆合問題 2.2 分布式系統 distributed system 是建立在網路之上的軟體系...
網際網路架構為什麼要做服務化？
服務化之前高可用架構 在服務化之前，網際網路的高可用架構大致是這樣乙個架構 使用者端是瀏覽器 browser 客戶端 2 後端入口是高可用的nginx集群，用於做反向 3 中間核心是高可用的web server集群，研發工程師主要編碼工作就是在這一層 4 後端儲存是高可用的db集群，資料儲存在這一層...