建站
咨詢
售后
建站咨詢
新聞中心
近期參加一些業(yè)界的技術(shù)大會(huì)，“微服務(wù)架構(gòu)”的話題非常之火，也在一些場(chǎng)合聊過服務(wù)化架構(gòu)實(shí)踐，最近幾期文章期望用通俗易懂的語言聊聊了個(gè)人對(duì)服務(wù)化以及微服務(wù)架構(gòu)的理解，希望能給大伙一些啟示。如果有遺漏，也歡迎大家補(bǔ)充。
在襄州等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站 網(wǎng)站設(shè)計(jì)制作定制開發(fā),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),網(wǎng)絡(luò)營銷推廣,成都外貿(mào)網(wǎng)站制作,襄州網(wǎng)站建設(shè)費(fèi)用合理。
一、互聯(lián)網(wǎng)高可用架構(gòu)，為什么要服務(wù)化?
【服務(wù)化之前高可用架構(gòu)】
在服務(wù)化之前，互聯(lián)網(wǎng)的高可用架構(gòu)大致是這樣一個(gè)架構(gòu)：
(1)用戶端是瀏覽器browser，APP客戶端
(2)后端入口是高可用的nginx集群，用于做反向代理
(3)中間核心是高可用的web-server集群，研發(fā)工程師主要編碼工作就是在這一層
(4)后端存儲(chǔ)是高可用的db集群，數(shù)據(jù)存儲(chǔ)在這一層
更典型的，web-server層是通過DAO/ORM等技術(shù)來訪問數(shù)據(jù)庫的。
可以看到，最初都是沒有服務(wù)層的，此時(shí)架構(gòu)會(huì)碰到一些什么痛點(diǎn)呢?
【架構(gòu)痛點(diǎn)一：代碼到處拷貝】
舉一個(gè)最常見的業(yè)務(wù)的例子->用戶數(shù)據(jù)的訪問，絕大部分公司都有一個(gè)數(shù)據(jù)庫存儲(chǔ)用戶數(shù)據(jù)，各個(gè)業(yè)務(wù)都有訪問用戶數(shù)據(jù)的需求：
在有用戶服務(wù)之前，各個(gè)業(yè)務(wù)線都是自己通過DAO寫SQL訪問user庫來存取用戶數(shù)據(jù)，這無形中就導(dǎo)致了代碼的拷貝。
【架構(gòu)痛點(diǎn)二：復(fù)雜性擴(kuò)散】
隨著并發(fā)量的越來越高，用戶數(shù)據(jù)的訪問數(shù)據(jù)庫成了瓶頸，需要加入緩存來降低數(shù)據(jù)庫的讀壓力，于是架構(gòu)中引入了緩存，由于沒有統(tǒng)一的服務(wù)層，各個(gè)業(yè)務(wù)線都需要關(guān)注緩存的引入導(dǎo)致的復(fù)雜性：
對(duì)于用戶數(shù)據(jù)的寫請(qǐng)求，所有業(yè)務(wù)線都要升級(jí)代碼：
(1)先淘汰cache
(2)再寫數(shù)據(jù)
對(duì)于用戶數(shù)據(jù)的讀請(qǐng)求，所有業(yè)務(wù)線也都要升級(jí)代碼：
(1)先讀cache，命中則返回
(2)沒命中則讀數(shù)據(jù)庫
(3)再把數(shù)據(jù)放入cache
這個(gè)復(fù)雜性是典型的“業(yè)務(wù)無關(guān)”的復(fù)雜性，業(yè)務(wù)方需要被迫升級(jí)。
隨著數(shù)據(jù)量的越來越大，數(shù)據(jù)庫需要進(jìn)行水平拆分，于是架構(gòu)中又引入了分庫分表，由于沒有統(tǒng)一的服務(wù)層，各個(gè)業(yè)務(wù)線都需要關(guān)注分庫分表的引入導(dǎo)致的復(fù)雜性：
這個(gè)復(fù)雜性也是典型的“業(yè)務(wù)無關(guān)”的復(fù)雜性，業(yè)務(wù)方需要被迫升級(jí)。
包括bug的修改，發(fā)現(xiàn)一個(gè)bug，多個(gè)地方都需要修改。
【架構(gòu)痛點(diǎn)三：庫的復(fù)用與耦合】
服務(wù)化并不是唯一的解決上述兩痛點(diǎn)的方法，抽象出統(tǒng)一的“庫”是最先容易想到的解決：
(1)代碼拷貝
(2)復(fù)雜性擴(kuò)散
的方法。抽象出一個(gè)user.so，負(fù)責(zé)整個(gè)用戶數(shù)據(jù)的存取，從而避免代碼的拷貝。至于復(fù)雜性，也只有user.so這一個(gè)地方需要關(guān)注了。
解決了舊的問題，會(huì)引入新的問題，庫的版本維護(hù)與業(yè)務(wù)線之間代碼的耦合：
業(yè)務(wù)線A將user.so由版本1升級(jí)至版本2，如果不兼容業(yè)務(wù)線B的代碼，會(huì)導(dǎo)致B業(yè)務(wù)出現(xiàn)問題;
業(yè)務(wù)線A如果通知了業(yè)務(wù)線B升級(jí)，則是的業(yè)務(wù)線B會(huì)無故做一些“自身業(yè)務(wù)無關(guān)”的升級(jí)，非常郁悶。當(dāng)然，如果各個(gè)業(yè)務(wù)線都是拷貝了一份代碼則不存在這個(gè)問題。
【架構(gòu)痛點(diǎn)四：SQL質(zhì)量得不到保障，業(yè)務(wù)相互影響】
業(yè)務(wù)線通過DAO訪問數(shù)據(jù)庫：
本質(zhì)上SQL語句還是各個(gè)業(yè)務(wù)線拼裝的，資深的工程師寫出高質(zhì)量的SQL沒啥問題，經(jīng)驗(yàn)沒有這么豐富的工程師可能會(huì)寫出一些低效的SQL，假如業(yè)務(wù)線A寫了一個(gè)全表掃描的SQL，導(dǎo)致數(shù)據(jù)庫的CPU100%，影響的不只是一個(gè)業(yè)務(wù)線，而是所有的業(yè)務(wù)線都會(huì)受影響。
【架構(gòu)痛點(diǎn)五：瘋狂的DB耦合】
業(yè)務(wù)線不至訪問user數(shù)據(jù)，還會(huì)結(jié)合自己的業(yè)務(wù)訪問自己的數(shù)據(jù)：
典型的，通過join數(shù)據(jù)表來實(shí)現(xiàn)各自業(yè)務(wù)線的一些業(yè)務(wù)邏輯。
這樣的話，業(yè)務(wù)線A的table-user與table-A耦合在了一起，業(yè)務(wù)線B的table-user與table-B耦合在了一起，業(yè)務(wù)線C的table-user與table-C耦合在了一起，結(jié)果就是：table-user，table-A，table-B，table-C都耦合在了一起。
隨著數(shù)據(jù)量的越來越大，業(yè)務(wù)線ABC的數(shù)據(jù)庫是無法垂直拆分開的，必須使用一個(gè)大庫(瘋了，一個(gè)大庫300多個(gè)業(yè)務(wù)表 =_=)。
【架構(gòu)痛點(diǎn)六：…】
二、服務(wù)化解決什么問題?
為了解決上面的諸多問題，互聯(lián)網(wǎng)高可用分層架構(gòu)演進(jìn)的過程中，引入了“服務(wù)層”。
以上文中的用戶業(yè)務(wù)為例，引入了user-service，對(duì)業(yè)務(wù)線響應(yīng)所用用戶數(shù)據(jù)的存取。引入服務(wù)層有什么好處，解決什么問題呢?
【好處一：調(diào)用方爽】
有服務(wù)層之前：業(yè)務(wù)方訪問用戶數(shù)據(jù)，需要通過DAO拼裝SQL訪問
有服務(wù)層之后：業(yè)務(wù)方通過RPC訪問用戶數(shù)據(jù)，就像調(diào)用一個(gè)本地函數(shù)一樣，非常之爽
User = UserService::GetUserById(uid);
傳入一個(gè)uid，得到一個(gè)User實(shí)體，就像調(diào)用本地函數(shù)一樣，不需要關(guān)心序列化，網(wǎng)絡(luò)傳輸，后端執(zhí)行，網(wǎng)絡(luò)傳輸，范序列化等復(fù)雜性。
【好處二：復(fù)用性，防止代碼拷貝】
這個(gè)不展開敘述，所有user數(shù)據(jù)的存取，都通過user-service來進(jìn)行，代碼只此一份，不存在拷貝。
升級(jí)一處升級(jí)，bug修改一處修改。
【好處三：專注性，屏蔽底層復(fù)雜度】
在沒有服務(wù)層之前，所有業(yè)務(wù)線都需要關(guān)注緩存、分庫分表這些細(xì)節(jié)。
在有了服務(wù)層之后，只有服務(wù)層需要專注關(guān)注底層的復(fù)雜性了，向上游屏蔽了細(xì)節(jié)。
【好處四：SQL質(zhì)量得到保障】
原來是業(yè)務(wù)向上游直接拼接SQL訪問數(shù)據(jù)庫。
有了服務(wù)層之后，所有的SQL都是服務(wù)層提供的，業(yè)務(wù)線不能再為所欲為了。底層服務(wù)對(duì)于穩(wěn)定性的要求更好的話，可以由更資深的工程師維護(hù)，而不是像原來SQL難以收口，難以控制。
【好處五：數(shù)據(jù)庫解耦】
原來各個(gè)業(yè)務(wù)的數(shù)據(jù)庫都混在一個(gè)大庫里，相互join，難以拆分。
服務(wù)化之后，底層的數(shù)據(jù)庫被隔離開了，可以很方便的拆分出來，進(jìn)行擴(kuò)容。
【好處六：提供有限接口，無限性能】
在服務(wù)化之前，各業(yè)務(wù)線上游想怎么操縱數(shù)據(jù)庫都行，遇到了性能瓶頸，各業(yè)務(wù)線容易扯皮，相互推諉。
服務(wù)化之后，服務(wù)只提供有限的通用接口，理論上服務(wù)集群能夠提供無限性能，性能出現(xiàn)瓶頸，服務(wù)層一處集中優(yōu)化。
【好處七：…】
三、其他
服務(wù)化的其他好處，以及帶來的問題，歡迎大家暢所欲言，我下期再來補(bǔ)充。
下期和大伙聊聊怎么“微”才是“微服務(wù)”，以及服務(wù)化的常見實(shí)踐。
幫忙隨手轉(zhuǎn)發(fā)喲。
文章轉(zhuǎn)載自微信公眾號(hào)“架構(gòu)師之路”
網(wǎng)站標(biāo)題：互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化？
轉(zhuǎn)載注明：http://m.5511xx.com/article/cocdihp.html
