互聯(lián)網(wǎng)高可用架構為什么要服務化

近期參加一些業(yè)界的技術大會，“微服務架構”的話題非常之火，也在一些場合聊過服務化架構實踐，最近幾期文章期望用通俗易懂的語言聊聊了個人對服務化以及微服務架構的理解，希望能給大伙一些啟示。如果有遺漏，也歡迎大家補充。一、互聯(lián)網(wǎng)高可用架構，為什么要服務化？【服務化之前高可用架構】在服務化之前，互聯(lián)網(wǎng)的高可用架構大致是這樣一個架構：（1）用戶端是瀏覽器browser，APP客戶端（2）后端入口是高可用的nginx集群，用于做反向代理（3）中間核心是高可用的web-server集群，研發(fā)工程師主要編碼工作就是在這一層（4）后端存儲是高可用的db集群，數(shù)據(jù)存儲在這一層更典型的，web-server層是通過DAO/ORM等技術來訪問數(shù)據(jù)庫的。可以看到，最初都是沒有服務層的，此時架構會碰到一些什么痛點呢？【架構痛點一：代碼到處拷貝】舉一個最常見的業(yè)務的例子->用戶數(shù)據(jù)的訪問，絕大部分公司都有一個數(shù)據(jù)庫存儲用戶數(shù)據(jù)，各個業(yè)務都有訪問用戶數(shù)據(jù)的需求：在有用戶服務之前，各個業(yè)務線都是自己通過DAO寫SQL訪問user庫來存取用戶數(shù)據(jù)，這無形中就導致了代碼的拷貝?！炯軜嬐袋c二：復雜性擴散】隨著并發(fā)量的越來越高，用戶數(shù)據(jù)的訪問數(shù)據(jù)庫成了瓶頸，需要加入緩存來降低數(shù)據(jù)庫的讀壓力，于是架構中引入了緩存，由于沒有統(tǒng)一的服務層，各個業(yè)務線都需要關注緩存的引入導致的復雜性：對于用戶數(shù)據(jù)的寫請求，所有業(yè)務線都要升級代碼：（1）先淘汰cache（2）再寫數(shù)據(jù)對于用戶數(shù)據(jù)的讀請求，所有業(yè)務線也都要升級代碼：（1）先讀cache，命中則返回（2）沒命中則讀數(shù)據(jù)庫（3）再把數(shù)據(jù)放入cache這個復雜性是典型的“業(yè)務無關”的復雜性，業(yè)務方需要被迫升級。隨著數(shù)據(jù)量的越來越大，數(shù)據(jù)庫需要進行水平拆分，于是架構中又引入了分庫分表，由于沒有統(tǒng)一的服務層，各個業(yè)務線都需要關注分庫分表的引入導致的復雜性：這個復雜性也是典型的“業(yè)務無關”的復雜性，業(yè)務方需要被迫升級。包括bug的修改，發(fā)現(xiàn)一個bug，多個地方都需要修改。【架構痛點三：庫的復用與耦合】服務化并不是唯一的解決上述兩痛點的方法，抽象出統(tǒng)一的“庫”是最先容易想到的解決：（1）代碼拷貝（2）復雜性擴散的方法。抽象出一個user.so，負責整個用戶數(shù)據(jù)的存取，從而避免代碼的拷貝。至于復雜性，也只有user.so這一個地方需要關注了。解決了舊的問題，會引入新的問題，庫的版本維護與業(yè)務線之間代碼的耦合：業(yè)務線A將user.so由版本1升級至版本2，如果不兼容業(yè)務線B的代碼，會導致B業(yè)務出現(xiàn)問題；業(yè)務線A如果通知了業(yè)務線B升級，則是的業(yè)務線B會無故做一些“自身業(yè)務無關”的升級，非常郁悶。當然，如果各個業(yè)務線都是拷貝了一份代碼則不存在這個問題。【架構痛點四：SQL質(zhì)量得不到保障，業(yè)務相互影響】業(yè)務線通過DAO訪問數(shù)據(jù)庫：本質(zhì)上SQL語句還是各個業(yè)務線拼裝的，資深的工程師寫出高質(zhì)量的SQL沒啥問題，經(jīng)驗沒有這么豐富的工程師可能會寫出一些低效的SQL，假如業(yè)務線A寫了一個全表掃描的SQL，導致數(shù)據(jù)庫的CPU100%，影響的不只是一個業(yè)務線，而是所有的業(yè)務線都會受影響?！炯軜嬐袋c五：瘋狂的DB耦合】業(yè)務線不至訪問user數(shù)據(jù)，還會結(jié)合自己的業(yè)務訪問自己的數(shù)據(jù)：典型的，通過join數(shù)據(jù)表來實現(xiàn)各自業(yè)務線的一些業(yè)務邏輯。這樣的話，業(yè)務線A的table-user與table-A耦合在了一起，業(yè)務線B的table-user與table-B耦合在了一起，業(yè)務線C的table-user與table-C耦合在了一起，結(jié)果就是：table-user，table-A，table-B，table-C都耦合在了一起。隨著數(shù)據(jù)量的越來越大，業(yè)務線ABC的數(shù)據(jù)庫是無法垂直拆分開的，必須使用一個大庫（瘋了，一個大庫300多個業(yè)務表=_=）。【架構痛點六：…】二、服務化解決什么問題？為了解決上面的諸多問題，互聯(lián)網(wǎng)高可用分層架構演進的過程中，引入了“服務層”。以上文中的用戶業(yè)務為例，引入了user-service，對業(yè)務線響應所用用戶數(shù)據(jù)的存取。引入服務層有什么好處，解決什么問題呢？【好處一：調(diào)用方爽】有服務層之前：業(yè)務方訪問用戶數(shù)據(jù)，需要通過DAO拼裝SQL訪問有服務層之后：業(yè)務方通過RPC訪問用戶數(shù)據(jù)，就像調(diào)用一個本地函數(shù)一樣，非常之爽User=UserService::GetUserById(uid);傳入一個uid，得到一個User實體，就像調(diào)用本地函數(shù)一樣，不需要關心序列化，網(wǎng)絡傳輸，后端執(zhí)行，網(wǎng)絡傳輸，范序列化等復雜性。【好處二：復用性，防止代碼拷貝】這個不展開敘述，所有user數(shù)據(jù)的存取，都通過user-service來進行，代碼只此一份，不存在拷貝。升級一處升級，bug修改一處修改?！竞锰幦簩Ｗ⑿裕帘蔚讓訌碗s度】在沒有服務層之前，所有業(yè)務線都需要關注緩存、分庫分表這些細節(jié)。在有了服務層之后，只有服務層需要專注關注底層的復雜性了，向上游屏蔽了細節(jié)?！竞锰幩模篠QL質(zhì)量得到保障】原來是業(yè)務向上游直接拼接SQL訪問數(shù)據(jù)庫。有了服務層之后，所有的SQL都是服務層提供的，業(yè)務線不能再為所欲為了。底層服務對于穩(wěn)定性的要求更好的話，可以由更資深的工程師維護，而不是像原來SQL難以收口，難以控制。【好處五：數(shù)據(jù)庫解耦】原來各個業(yè)務的數(shù)據(jù)庫都混在一個大庫里，相互join，難以拆分。服務化之后，底層的數(shù)據(jù)庫被隔離開了，可以很方便的拆