今天給大家分享一個 API 網關的知識,很多兄弟可能平時經常搞的都是一些 CRUD 的業務系統開發,從來沒接觸過 API 網關。

那今天來講講,API 網關是啥,到底能對我們起到什么作用呢?這個一般面試的時候也很可能會問到這個知識點的。

先來看看業務系統技術棧

平時咱們可能寫系統的時候,往往就是基于 SpringBoot+Spring MVC+Spring+Mybatis 這套技術棧來開發業務代碼,然后連接一個 MySQL 就行了。

你調用別的系統往往就是基于 Dubbo,注冊中心可能是 Zookeeper 也可能是 Nacos。

就類似下面的這個圖,對不對?

網關路由請求轉發功能

好,那么現在給大家講第一個痛點,那就是你們公司可能存在 n 多個業務系統,那琳瑯滿目的,可能有幾十個系統。

此時對于前端/APP 端他們還能知道哪個請求發送給哪個系統嗎,這真的是太麻煩了,對不對?所以說,此時一般會引入一個 API 網關。

你每個業務系統吧,在 API 網關里配置一下,自己要處理什么樣的請求 url,然后 API 網關收到請求以后,根據請求 url 路徑判斷一下,就知道應該把請求轉發給哪個業務系統了,完美,對不對?

看看下圖吧:

網關統一授權和鑒權功能

下一個問題來了,你這個系統能允許別人誰來都隨便調用你嗎?你不得搞一個授權和鑒權的過程?你不得甄別甄別發送請求來的這個人是好人壞人?

你不得想想發送過來的這個請求到底應該不應該處理嗎?所以這個時候這個鑒權的事情你自己搞嗎?那太麻煩了吧,你也鑒權,別的系統自己也鑒權,那真的是麻煩大了。

所以這個時候,我們就直接在 API 網關里加入鑒權功能不就完了,一個請求過來是好人還是壞人,API 網關就幫你鑒權了,通過鑒權的請求才能往后端發送。

如下圖:

API 網關層流控功能

再下一個痛點來了,那就是假設咱們系統一共就部署了幾臺機器,總共每秒幾千請求了不得了,結果有一天運營搞了一個特別棒的活動,每秒來了幾萬流量和請求,一下子給你擊垮了,你說你怎么辦,你扛不住啊?

所以這個時候啊,還得在 API 網關層加入流控的功能,每個業務系統可以配置自己能抗的 QPS,他根據這個來限制每秒轉發給你的請求不就完了。

如下圖:

API 網關層灰度發布功能

然后呢,還有一個經常遇到的痛點,那就是咱們每次系統上線部署,如果一下子把新的版本部署到所有機器里去,就怕新版本上線就掉倆字,直接就崩潰,這可怎么辦。

所以一般來說,可以引入一個灰度發布,這個灰度發布意思就是說,假設你系統部署了 3 臺機器,每次上線先部署 1 臺機器,然后線上的流量里劃分 5% 給這個新部署的灰度版本機器,先觀察一下咋樣,要是沒問題,再把后續兩臺機器給部署了,這就是灰度發布。

灰度發布也可以叫做金絲雀發布,這個金絲雀發布是啥意思呢,就是以前古代有盜版的人下墓的時候先把金絲雀扔進去看看,如果他不叫了,說明墓里有毒氣,現在這個灰度發布也是一個意思,先把新版本部署到一臺機器里去,觀察一下,要是他崩了,就說明代碼有問題。

所以此時就可以基于 API 網關來實現灰度發布了,每次部署了灰度版本以后,讓 API 網關就劃分 5% 的流量給這個灰度版本,一切正常了再全量部署。

如下圖:

好了,到這里為止,就給大家把這個 API 網關的作用講清楚了,大家平時不要老是埋頭寫 crud 代碼啊,對 API 網關這些東西,也是要了解一下的,別啥都不知道。

標簽: