今天給大家分享一個 API 網(wǎng)關的知識，很多兄弟可能平時經(jīng)常搞的都是一些 CRUD 的業(yè)務系統(tǒng)開發(fā)，從來沒接觸過 API 網(wǎng)關。

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

先來看看業(yè)務系統(tǒng)技術棧

平時咱們可能寫系統(tǒng)的時候，往往就是基于 SpringBoot+Spring MVC+Spring+Mybatis 這套技術棧來開發(fā)業(yè)務代碼，然后連接一個 MySQL 就行了。

你調用別的系統(tǒng)往往就是基于 Dubbo，注冊中心可能是 Zookeeper 也可能是 Nacos。

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

網(wǎng)關路由請求轉發(fā)功能

好，那么現(xiàn)在給大家講第一個痛點，那就是你們公司可能存在 n 多個業(yè)務系統(tǒng)，那琳瑯滿目的，可能有幾十個系統(tǒng)。

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

你每個業(yè)務系統(tǒng)吧，在 API 網(wǎng)關里配置一下，自己要處理什么樣的請求 url，然后 API 網(wǎng)關收到請求以后，根據(jù)請求 url 路徑判斷一下，就知道應該把請求轉發(fā)給哪個業(yè)務系統(tǒng)了，完美，對不對?

看看下圖吧：

網(wǎng)關統(tǒng)一授權和鑒權功能

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

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

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

如下圖：

API 網(wǎng)關層流控功能

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

所以這個時候啊，還得在 API 網(wǎng)關層加入流控的功能，每個業(yè)務系統(tǒng)可以配置自己能抗的 QPS，他根據(jù)這個來限制每秒轉發(fā)給你的請求不就完了。

如下圖：

API 網(wǎng)關層灰度發(fā)布功能

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

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

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

所以此時就可以基于 API 網(wǎng)關來實現(xiàn)灰度發(fā)布了，每次部署了灰度版本以后，讓 API 網(wǎng)關就劃分 5% 的流量給這個灰度版本，一切正常了再全量部署。

如下圖：

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