API網關是什麼？和SCF有什麼應用？

騰小雲導讀：

本文內容分為四部分：

第一，API網關這個產品本身的簡單介紹和一些能力。

第二，API網關和SCF也就是我們無伺服器函數結合使用的時候提供了哪些能力跟它結合方便大家使用。

第三，在比較常用的場景中我們整體的使用架構以及現在客戶真正使用的案例。

最後是大家關心的費用問題。

本文是劉敏潔在雲+社區沙龍《Serverless架構開發與無伺服器雲函數(Serverless Cloud Function,SCF)部署實踐》上的分享。

本文共：6215字，預計閱讀時間： 16 分鐘

這次我們主要介紹面向於API網關和SCF深度結合應用，API網關與SCF結合可以形成比較完整的Serverless方案。

今天的內容分為四部分：第一，API網關這個產品本身的簡單介紹和一些能力。第二，API網關和SCF也就是我們無伺服器函數結合使用的時候提供了哪些能力跟它結合方便大家使用。第三，在比較常用的場景中我們整體的使用架構以及現在客戶真正使用的案例。最後是大家關心的費用問題。

我們做API網關這個產品的初衷不單單是一定說跟SCF強綁定的，是在用戶使用中，遇到了很多問題。那麼最開始我們為什麼會做這個產品？在場大家多數都是做開發的應該很清楚了，比如前端的調用方式越來越多了，後端的部署方式越來越多了，可以用自己的物理機，可以買一個雲主機，可以搞一個容器，可以像使用現在更新的微服務，無伺服器計算。那麼在這種複雜的情況下前端和後端的耦合就會造成業務上在擴容，在做一些新的業務增加的時候變得麻煩。那麼此時，解耦就變得異常重要。

市面上也有一些API網關這樣的開源產品，但是運維的成本，費用問題也會分攤到每個開發同學身上，既然如此我們就在想何不做一個以服務的形式提供API網關能力的產品給客戶呢。所以有了今天給大家介紹的API網關這樣一款產品。

API網關在一般場景下怎麼使用的？

有一個很簡單的電商例子，多數情況下客戶後端有很多的業務模塊，有商品、用戶這些常用的業務模塊。如果在以前，可能是前端的APP，小程序，直接調用這些模塊，後端也是以API形式提供給前端調用的。但是前端需要理解每個模塊的API。現在我們提供API網關服務，客戶在使用API網關後，我們建議客戶把他們的每個業務模塊跟我們API網關進行對接。由API網關統一輸出一個API提供給前端調用。包括前面說的小程序，外部API，都是這樣的一種可以在前端調用的方式。

其實用一句話來總結一下，我們API網關這個服務是什麼呢？就是API的一個託管服務，可以對多種後端能力進行統一的管理，輸出無狀態服務的API給到前端調用。用戶可以在API網關上創建API，發布API，上線、下線等。包括建成限流，監控這樣的一些能力，這些能力在解耦過程中都是非常需要的。

這裡總結了幾個比較大的能力點：首先，統一鑒權認證，這是非常重要安全防護的能力。API轉化和隱藏，像參數，位置，名稱都可以做轉化和映射，經過映射後真正的調用者不一定拿到這些後端的真實數據。

流控和配額也是常見的能力，通常後端業務資源其實是有限的，所以前端需要將API的QPS和配額做限制。另外還有輸出API能力，現在騰訊雲提供了API市場，如果用戶後台有一些業務，有一些能力，有一些數據，想通過API提供出去給第三方夥伴直接進行售賣，都可以通過這個網關輸出到API網關進行直接售賣。

自動化文檔和SDK這個能力呢，其實是針對方便調用者進行調用的，如果我們有了業務後再手寫文檔，這個工作量也很大，所以API網關可以自動幫助客戶生成文檔，還有SDK供客戶調用。

強負載能力，騰訊雲API網關依賴於騰訊大的負載平台，可以應對大的突發請求不懼怕大的負載，性能方面是很有保證的。最後，API網關可以對API進行安全防護，對調用API原IP做白名單。

這裡其實是比較完整的流轉方式。API網關分兩種角色：一個是發布API的人，一個是調用API的人，他們可能是同一些人，也可能是分別兩撥人。發布者先把API發布到API網關中，參數，認證，鑒權，映射等等都需要進行配置，發布者配置後可以直接在API網關控制台上進行調試，在控制台上看看這個通不通，後台響應正不正常，Ok不Ok。如果調試都成功了進行API的發布。發布後就可以把API提供給調用者了。

那麼API網關怎麼提供API給調用者呢？

我們的服務其實是以域名的形式提供給調用者的。我們會提供默認的二級域名。當然客戶有自己的域名，也可以把這個域名綁到我們二級域名上。另外API網關可以生成文檔SDK，提供給調用者。調用者直接使用文檔、SDK可以方便的調用。調用後，前端請求到API網關後，API網關會根據之前發布的配置做一些認證，鑒權這樣一些基礎的校驗。到後端我們會做參數的映射，最終把這個請求發到後端業務。其實後端可以對接很多雲服務，像SCF，像其他雲服務統統都是可以對接的。當然今天主角是無伺服器函數，所以我們主要講一下對接到SCF。對接後它會拉起它的服務響應，根據響應看是不是做一些映射，最後把結果丟會調用者。在這個過程中發布者可以看到監控的信息是怎樣，也可以查詢到調用。如果調用失敗，或者有什麼錯誤，是前端的還是後端的，整個日誌都是可以查詢到的。這是一個比較完整的流程。

我們現在可以看一下API怎麼跟SCF結合使用。其實很簡單，前面是API網關做一個觸發器。用觸發器的形式來觸發SCF後端的函數。然後SCF做一些計算處理，結束後它可能落到後邊的像資料庫這些服務，在圖中的沒有畫出來。這種方式現在APP，小程序都是很常用的，包括給第三方合作夥伴，就是它們直接提供API給第三方合作夥伴，不走任何的平台，這種都是非常常用的一種方式。

安全與限流，剛剛在我們整個功能里其實有做了一個簡單的說明。這裡分幾塊說：第一，我們提供認證能力。認證的能力像密鑰對是現在常用的認證方式，我們在網關上生成密鑰對，把這個提供給調用者。這個密鑰對常用是伺服器端對伺服器端。也有像用OAuth這種單點登錄，客戶有自己認證伺服器的，我們也是支持的，可以去用API網關對接認證伺服器。認證伺服器去對調用做認證鑒權，然後我們在做一些校驗。這是對整個認證管理做一個安全性的保障。

其實還有剛才說的源IP黑白名單。這個常見於大家內部用的，比如我是一個大的公司，內部幾個部門之間用。另外限流的部分，當後端業務能承載的QPS有限的時候，在API這邊做一個限流控制，如果超過這個QPS，就把這個調用丟掉，後端不會過載。

CORS，現在跨域的調用非常多的，比如電商，還有一些WEB頁，像CSS、JS靜態調用，訪問時需要瀏覽器跨域調用。當請求是跨域請求時，API網關會根據發布者的配置做一些處理，比如配置支持跨域，API網關會把這個CORS頭去。直接響應回來後我們再把CORS頭放迴響應中。這完成的是跨域調用。這樣的話其實對SCF開發者會比較方便使用，就不用再操心跨域的問題。

響應集成這種也是常見的使用，用戶開發小程序時的場景也是響應集成可能比較常用到。比如在對接前面的介面時，需要把SCF抽取成真正的HTTP格式請求返回給前端。API網關與SCF之間同樣為HTTP請求，SCF函數返回的響應在響應透傳模式時，會被全部放進API網關的響應body中，返回給調用者。這樣的話可以直接對接很多已經有一些規範，已經有一些介面的，像小程序這種，會不適用這種方式。那麼就需要API網關把SCF的響應抽取為一個標準HTTP的respond返回個標準介面。

Websocket能力算是在函數計算里的一個難點，因為本身函數不是常駐的，比如說這個函數跑一跑，在沒有觸發的時候，可能有一個時間段過去後，目前的資源就釋放掉了，下次再觸發的時候再拉起來，這很難跟前端保持長連接。

那我們怎麼幫SCF處理長連接問題的呢？API網關會幫每一個前端的調用者生成一個唯一的ID，這個ID就註冊到後面客戶的業務函數里。當客戶業務函數需要推送的時候，他只要帶到這個唯一ID給API網關，API網關就會將這個唯一ID的消息丟給前端，這樣我們唯一ID和前面的連接保持了長連接，也保證了後端推送的正確性。舉個例子，一個聊天室，有三個人聊天，范冰冰，李晨和黃曉明。他們三個都有唯一ID。黃曉明發出來一句話，後面的函數收到這句話，並且要把他說的話推送給范冰冰和李晨，那麼通過唯一ID，可以識別到三個人，後端業務將黃曉明ID的聊天語句推送到API網關，告訴API網關要將此信息推送給范冰冰和李晨ID的前端，API網關收到信息後，則將此信息推送到與范冰冰李晨的客戶端保持的長連接中，他們就看到了這條信息。這就是處理Websocket長連接的方式。

開放到API市場上，剛才我們也簡單說了一下，其實很多能力，我們自己一些能力和數據想直接開放出去給別人，但是並不想做一個頁面，計費流程，那麼可以放到API市場來進行售賣。其實後端業務放到SCF上是提供服務的一種方式，這樣有些用戶業務是放在API市場上來進行售賣的。這是把我們技術能力變現的一種方式。

文檔與SDK剛才也說了很多，這裡再來介紹一下。如果用戶配了10個API，API網關會幫用戶生成這10個API的文檔和SDK。swagger文檔有點像代碼式的文檔另外還有普通文字描述的API文檔，這兩種我們都能生成。生成後可以直接下載下來提供給別人。SDK中有鑒權相關的代碼，調用者使用時把自己的參數填進去，對調用者來說更方便。

高並發，這裡我們還是想強調一下，API網關可以扛住非常非常大的並發請求。當用戶請求的並發量極大時，並且有大量HTTPS時，大量請求十分消耗CPU。ABI網關的高性能，及時HTTPS請求的非同步處理，可以應對高並發場景，保證服務可用。

場景方面，剛才說的是一些具體功能，我們能幫SCF做哪些具體的能力。在整體結構的使用場景這裡做一些介紹，這裡是小程序公眾號，電商這種業務場景現在使用的一些客戶的架構，客戶的很多業務模塊放到SCF上面，然後用API網關作為API服務提供出去。前端無論是小程序還是APP只要有鑒權，有密鑰對都可以來進行調用。後端根據自己的業務去跟MySQL等能力來進行對接。

剛剛這種方式，像樂凱撒是一個很典型的例子。他們把他們的菜單系統，還有微信支付都放在SCF上面。前端會對接一些固有的HTTP介面，所以用了我們的響應集成的能力，就是API網關幫他抽取成一個標準的HTTP響應返回給前面的調用者。另外因為有很多圖片靜態資源，他們也使用了跨域能力，這樣後端上線的時候非常快。樂凱撒現在有一個小程序用戶可以直接在上面下單買披薩，這個小程序中的很多能力是使用上述架構完成的。他們的ERP也有一些後台的系統，也是直接在SCF上進行後台計算，用API網關直接出介面。其實很多能力可以復用，那麼API本身就可以進行復用。這樣的開發流程，會讓整個上線過程非常的迅速。

現在用的多的還有AI推理和翻譯。用戶將自身的計算模型，翻譯模型等放在SCF上，每次通過API網關觸發來觸發計算。API網關將請求帶來的數據給到後端，並對每個請求做鑒權認證或ACL管理保障使用的安全性。

比較典型的就是搜狗，搜狗在這裡其實有一個翻譯推理的模型，放在SCF上， SCF跑在GPU上，然後通過API網關做觸發。這裡用API網關主要是想做前後的解耦。因為搜狗的業務本身解耦是C++寫的，所有的請求都是用http的方式傳遞，請求端和後台解耦合後，很多後端業務不再需要用python重寫。

荔枝微課是一個在線教育課程。

它的情況是，後端SCF跑了一個模型計算。每次當客戶在他的頁面上搜某個課程。它的前端會把這個課程，用戶感興趣的課程信息，包括客戶的ID，之前的一些信息帶到後端帶給SCF。SCF模型拿到了客戶信息，它本身也會有一些自己的原有的信息，這些信息結合起來，再根據其演算法進行計算。最後得出的結論，這個客戶喜歡某些課程，再把這個課程推送到前端來，最終展示在WEB頁上。在這個中間，其實API網關和SCF解耦的時候，對API網關的模型調用，需要有安全保證的，就是有不同IP的時候有源IP調用，還有密鑰對的鑒權對後端進行安全保障。另外如果說這個SCF或者調用有任何問題的話，監控報警也是可以快速讓我感知到這個模型的狀態。

最後看一下費用，我們費用也是有很大力度減免的，每月有一百萬次的免費調用。網路費用跟公網的的價格是一樣的，調用次數0.04元/萬次。目前沒有收費，預計到年底收費。但是整個資源費用是非常便宜的，所以如果有想試用的同學不用很猶豫。

Q：主要想請問涉及到有時候有自己的線上環境和我們的測試環境，我想知道我們現在如果使用你們的API網關還有SCF，我們怎麼去部署這樣兩套環境？怎麼樣去完成像我們現在使用的這些持續集成，怎麼結合到我現有的產品？因為我目前看到的展示都是基於控制台，沒有看到說基於CLI的操作，所以想了解一下。

A：其實我們API網關有環境管理和版本管理。版本管理也分了環境，測試環境這些標準環境。後續還會開放這些環境讓用戶自定義這些環境。CLI部分我理解需要在公台操作，還是命令行操作，本身跟我提不提供環境管理，版本能力應該是兩個事情。所以CLI後續會提供。但是本身需要的開發和測試環境我們已經分環境提供。

Q：新的代碼更新後要上線到SCF上怎麼部署？

A：後面我們會做一個工具，在這個工具上，比如CLI，可以一鍵上傳，並且配一些API網關。目前這個都在開發中。

Q：怎麼樣買伺服器便宜，怎麼樣買按調用次數的偏移？

A：這個還是需要你本身業務來計算一下。比如說我這個業務就是一個觸髮型的業務，我如果用一個CPM或者物理機部署的話，如果常駐型的話需要佔到多少錢，這個錢其實是固定的，每個月需要多少錢。但是如果我知道這個業務是觸髮型，假如每天就調用一萬次，這個也是能算出來的錢。這個錢一比較就很簡單就出來了。但是這個都得基於你本身業務的調用量和你本身業務後端消耗資源的情況來進行計算的。所以我沒法兒給你一個直接的值。

如果真的需要一個常駐的業務，一天二十四小時一直在跑的話，其實這個也是要看，這二十四小時在跑的，我對我本身的伺服器我的消耗情況，比如說我買完了一台伺服器，市面上的伺服器可能就那麼多，或者說CPM就那麼多，即便買了最小的4核伺服器都沒跑滿，如果計算很輕量沒法兒跑滿的話，用SCF也會很划算。但是需要大量的，可能用本身的傳統的方式會比較簡單。

Q：在調用的穩定性，延時方面Serverless會有優勢嗎？

A：其實調用的穩定性是我們服務穩定性的保障，這個不用擔心，因為我們有承諾。至於延時，是有很多因素影響的，如果你是公網調用，這基於網路的一些情況。如果說API網關到SCF結合的話，本身API網關和SCF可以走內網和公網。API網關本身的延時是在毫秒級別，這個我們測試過的，還是很小的。如果部署一個伺服器或者資源，你到那個網路之間的延時，你自己本身原來延時是多少還是要算一下。我可以告訴你我們的延時本身是多少，在可測的環境下我們的延時是多少。但是到你們具體的網路環境下還是要具體測量的。

劉敏潔：具有多年雲計算行業經驗，曾任職於華為、UCloud等企業擔任產品開發、產品經理。目前負責騰訊雲API生態的推廣，幫助開發者進行API網關與無伺服器函數、容器、微服務等產品的結合使用，提供完整解決方案。

—— 完 ——

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！