架構系列 網際網路架構為什麼要做服務化

2021-10-09 09:35:51 字數 3635 閱讀 6293

【服務化之前高可用架構】

在服務化之前,網際網路的高可用架構大致是這樣乙個架構:

(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 語句還是各個業務線拼裝的,資深的工程師...