2020国产成人精品视频,性做久久久久久久久,亚洲国产成人久久综合一区,亚洲影院天堂中文av色

分享

互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化?

 LZS2851 2017-02-14

近期參加一些業(yè)界的技術(shù)大會(huì), “ 微服務(wù)架構(gòu) ” 的話(huà)題非常之火,也在一些場(chǎng)合聊過(guò)服務(wù)化架構(gòu)實(shí)踐,最近幾期文章期望用通俗易懂的語(yǔ)言聊聊了個(gè)人對(duì)服務(wù)化以及微服務(wù)架構(gòu)的理解,希望能給大伙一些啟示。 如果有遺漏,也歡迎大家補(bǔ)充 。

一、互聯(lián)網(wǎng)高可用架構(gòu),為什么要服務(wù)化?

【服務(wù)化之前高可用架構(gòu)】

在服務(wù)化之前,互聯(lián)網(wǎng)的高可用架構(gòu)大致是這樣一個(gè)架構(gòu):

( 1 )用戶(hù)端是瀏覽器 browser , APP 客戶(hù)端

( 2 )后端入口是高可用的 nginx 集群,用于做反向代理

( 3 )中間核心是高可用的 web-server 集群, 研發(fā)工程師主要編碼工作就是在這一層

( 4 )后端存儲(chǔ)是高可用的 db 集群,數(shù)據(jù)存儲(chǔ)在這一層

更典型的, web-server 層是通過(guò) DAO/ORM 等技術(shù)來(lái)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的。

可以看到,最初都是沒(méi)有服務(wù)層的,此時(shí)架構(gòu)會(huì)碰到一些什么痛點(diǎn)呢?

【架構(gòu)痛點(diǎn)一:代碼到處拷貝】

舉一個(gè)最常見(jiàn)的業(yè)務(wù)的例子 -> 用戶(hù)數(shù)據(jù)的訪(fǎng)問(wèn),絕大部分公司都有一個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)用戶(hù)數(shù)據(jù),各個(gè)業(yè)務(wù)都有訪(fǎng)問(wèn)用戶(hù)數(shù)據(jù)的需求:

在有用戶(hù)服務(wù)之前, 各個(gè)業(yè)務(wù)線(xiàn)都是自己通過(guò) DAO 寫(xiě) SQL 訪(fǎng)問(wèn) user 庫(kù)來(lái)存取用戶(hù)數(shù)據(jù),這無(wú)形中就導(dǎo)致了代碼的拷貝 。

【架構(gòu)痛點(diǎn)二:復(fù)雜性擴(kuò)散】

隨著并發(fā)量的越來(lái)越高,用戶(hù)數(shù)據(jù)的訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)成了瓶頸,需要加入緩存來(lái)降低數(shù)據(jù)庫(kù)的讀壓力,于是架構(gòu)中引入了緩存,由于沒(méi)有統(tǒng)一的服務(wù)層, 各個(gè)業(yè)務(wù)線(xiàn)都需要關(guān)注緩存的引入導(dǎo)致的復(fù)雜性 :

對(duì)于用戶(hù)數(shù)據(jù)的寫(xiě)請(qǐng)求,所有業(yè)務(wù)線(xiàn)都要升級(jí)代碼:

( 1 )先淘汰 cache

( 2 )再寫(xiě)數(shù)據(jù)

對(duì)于用戶(hù)數(shù)據(jù)的讀請(qǐng)求,所有業(yè)務(wù)線(xiàn)也都要升級(jí)代碼:

( 1 )先讀 cache ,命中則返回

( 2 )沒(méi)命中則讀數(shù)據(jù)庫(kù)

( 3 )再把數(shù)據(jù)放入 cache

這個(gè)復(fù)雜性是典型的“業(yè)務(wù)無(wú)關(guān)”的復(fù)雜性,業(yè)務(wù)方需要被迫升級(jí)。

隨著數(shù)據(jù)量的越來(lái)越大,數(shù)據(jù)庫(kù)需要進(jìn)行水平拆分,于是架構(gòu)中又引入了分庫(kù)分表,由于沒(méi)有統(tǒng)一的服務(wù)層, 各個(gè)業(yè)務(wù)線(xiàn)都需要關(guān)注分庫(kù)分表的引入導(dǎo)致的復(fù)雜性 :

這個(gè)復(fù)雜性也是典型的“業(yè)務(wù)無(wú)關(guān)”的復(fù)雜性,業(yè)務(wù)方需要被迫升級(jí)。

包括 bug 的修改, 發(fā)現(xiàn)一個(gè) bug ,多個(gè)地方都需要修改 。

【架構(gòu)痛點(diǎn)三:庫(kù)的復(fù)用與耦合】

服務(wù)化并不是唯一的解決上述兩痛點(diǎn)的方法,抽象出統(tǒng)一的 “ 庫(kù) ” 是最先容易想到的解決:

( 1 )代碼拷貝

( 2 )復(fù)雜性擴(kuò)散

的方法。抽象出一個(gè) user.so ,負(fù)責(zé)整個(gè)用戶(hù)數(shù)據(jù)的存取,從而避免代碼的拷貝。至于復(fù)雜性,也只有 user.so 這一個(gè)地方需要關(guān)注了。

解決了舊的問(wèn)題,會(huì)引入新的問(wèn)題, 庫(kù)的版本維護(hù)與業(yè)務(wù)線(xiàn)之間代碼的耦合 :

業(yè)務(wù)線(xiàn) A 將 user.so 由版本 1 升級(jí)至版本 2 ,如果不兼容業(yè)務(wù)線(xiàn) B 的代碼,會(huì)導(dǎo)致 B 業(yè)務(wù)出現(xiàn)問(wèn)題;

業(yè)務(wù)線(xiàn) A 如果通知了業(yè)務(wù)線(xiàn) B 升級(jí),則是的業(yè)務(wù)線(xiàn) B 會(huì)無(wú)故做一些“自身業(yè)務(wù)無(wú)關(guān)”的升級(jí),非常郁悶。當(dāng)然,如果各個(gè)業(yè)務(wù)線(xiàn)都是拷貝了一份代碼則不存在這個(gè)問(wèn)題。

【架構(gòu)痛點(diǎn)四: SQL 質(zhì)量得不到保障,業(yè)務(wù)相互影響】

業(yè)務(wù)線(xiàn)通過(guò) DAO 訪(fǎng)問(wèn)數(shù)據(jù)庫(kù):

本質(zhì)上 SQL 語(yǔ)句還是各個(gè)業(yè)務(wù)線(xiàn)拼裝的,資深的工程師寫(xiě)出高質(zhì)量的 SQL 沒(méi)啥問(wèn)題,經(jīng)驗(yàn)沒(méi)有這么豐富的工程師可能會(huì)寫(xiě)出一些低效的 SQL , 假如業(yè)務(wù)線(xiàn) A 寫(xiě)了一個(gè)全表掃描的 SQL ,導(dǎo)致數(shù)據(jù)庫(kù)的 CPU100% ,影響的不只是一個(gè)業(yè)務(wù)線(xiàn),而是所有的業(yè)務(wù)線(xiàn)都會(huì)受影響 。

【架構(gòu)痛點(diǎn)五:瘋狂的 DB 耦合】

業(yè)務(wù)線(xiàn)不至訪(fǎng)問(wèn) user 數(shù)據(jù),還會(huì)結(jié)合自己的業(yè)務(wù)訪(fǎng)問(wèn)自己的數(shù)據(jù):

典型的,通過(guò) join 數(shù)據(jù)表來(lái)實(shí)現(xiàn)各自業(yè)務(wù)線(xiàn)的一些業(yè)務(wù)邏輯。

這樣的話(huà),業(yè)務(wù)線(xiàn) A 的 table-user 與 table-A 耦合在了一起,業(yè)務(wù)線(xiàn) B 的 table-user 與 table-B 耦合在了一起,業(yè)務(wù)線(xiàn) C 的 table-user 與 table-C 耦合在了一起,結(jié)果就是: table-user , table-A , table-B , table-C 都耦合在了一起。

隨著數(shù)據(jù)量的越來(lái)越大,業(yè)務(wù)線(xiàn) ABC 的數(shù)據(jù)庫(kù)是無(wú)法垂直拆分開(kāi)的 ,必須使用一個(gè)大庫(kù)(瘋了,一個(gè)大庫(kù) 300 多個(gè)業(yè)務(wù)表 =_= )。

【架構(gòu)痛點(diǎn)六: …

二、服務(wù)化解決什么問(wèn)題?

為了解決上面的諸多問(wèn)題,互聯(lián)網(wǎng)高可用分層架構(gòu)演進(jìn)的過(guò)程中,引入了“服務(wù)層”。

以上文中的用戶(hù)業(yè)務(wù)為例,引入了 user-service ,對(duì)業(yè)務(wù)線(xiàn)響應(yīng)所用用戶(hù)數(shù)據(jù)的存取。引入服務(wù)層有什么好處,解決什么問(wèn)題呢?

【好處一:調(diào)用方爽】

有服務(wù)層之前:業(yè)務(wù)方訪(fǎng)問(wèn)用戶(hù)數(shù)據(jù),需要通過(guò) DAO 拼裝 SQL 訪(fǎng)問(wèn)

有服務(wù)層之后: 業(yè)務(wù)方通過(guò) RPC 訪(fǎng)問(wèn)用戶(hù)數(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è)不展開(kāi)敘述,所有 user 數(shù)據(jù)的存取,都通過(guò) user-service 來(lái)進(jìn)行,代碼只此一份,不存在拷貝。

升級(jí)一處升級(jí), bug 修改一處修改。

【好處三:專(zhuān)注性,屏蔽底層復(fù)雜度】

互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化?

在沒(méi)有服務(wù)層之前,所有業(yè)務(wù)線(xiàn)都需要關(guān)注緩存、分庫(kù)分表這些細(xì)節(jié)。

在有了服務(wù)層之后,只有服務(wù)層需要專(zhuān)注關(guān)注底層的復(fù)雜性了,向上游屏蔽了細(xì)節(jié) 。

【好處四: SQL 質(zhì)量得到保障】

互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化?

原來(lái)是業(yè)務(wù)向上游直接拼接 SQL 訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)。

有了服務(wù)層之后,所有的 SQL 都是服務(wù)層提供的,業(yè)務(wù)線(xiàn)不能再為所欲為了 。底層服務(wù)對(duì)于穩(wěn)定性的要求更好的話(huà),可以由更資深的工程師維護(hù),而不是像原來(lái) SQL 難以收口,難以控制。

【好處五:數(shù)據(jù)庫(kù)解耦】

互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化?

原來(lái)各個(gè)業(yè)務(wù)的數(shù)據(jù)庫(kù)都混在一個(gè)大庫(kù)里,相互 join ,難以拆分。

互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化?

服務(wù)化之后, 底層的數(shù)據(jù)庫(kù)被隔離開(kāi)了,可以很方便的拆分出來(lái),進(jìn)行擴(kuò)容 。

【好處六:提供有限接口,無(wú)限性能】

在服務(wù)化之前,各業(yè)務(wù)線(xiàn)上游想怎么操縱數(shù)據(jù)庫(kù)都行,遇到了性能瓶頸,各業(yè)務(wù)線(xiàn)容易扯皮,相互推諉。

服務(wù)化之后, 服務(wù)只提供有限的通用接口,理論上服務(wù)集群能夠提供無(wú)限性能,性能出現(xiàn)瓶頸,服務(wù)層一處集中優(yōu)化 。

 

來(lái)自:http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959519&idx=1&sn=065074b135fc9cb243abe897261e1a72&scene=0

 

    本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間,所有內(nèi)容均由用戶(hù)發(fā)布,不代表本站觀(guān)點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購(gòu)買(mǎi)等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請(qǐng)點(diǎn)擊一鍵舉報(bào)。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評(píng)論

    發(fā)表

    請(qǐng)遵守用戶(hù) 評(píng)論公約

    類(lèi)似文章 更多