如何通過AWS的Lambda和API Gateway走向Serverless

本篇內容介紹了“如何通過AWS的Lambda和API Gateway走向Serverless”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

簡短回憶下計算領域的發展

早期，出現了……好吧，這有點復雜。很早的時候，出現了機械計算機，后來又有了埃尼阿克 ENIAC(Electronic Numerical  Integrator And Computer，很早的電子計算機)，但是都沒有規模生產。直到大型機出現后，計算領域才快速發展。

• 上世紀 50 年代 - 大型機

• 上世紀 60 年代 - 微型機

• 1994 - 機架服務器

• 2001 - 刀片服務器

• 本世紀初 - 虛擬服務器

• 2006 - 服務器云化

• 2013 - 容器化

• 2014 - serverless(計算資源服務化)

這些日期是大概的發布或者流行日期，無需和我爭論時間的準確性。計算領域的演進趨勢是執行的功能單元越來越小。每一次演進通常都意味著運維負擔的減小和運維靈活性的增加。

發展前景

喔，Serverless!但是，serverless 能給我們帶來什么好處? 我們將面臨什么挑戰呢?

未執行代碼時無需付費。我認為，這是個巨大的賣點。當無人訪問你的站點或用你的 API  時，你無需付錢。沒有持續支出的基礎設施成本，僅僅支付你需要的部分。換句話說，這履行了云計算的承諾：“僅僅支付你真正用的資源”。

無需維護服務器，也無需考慮服務器安全。服務器的維護和安全將由你的服務提供商來處理(當然，你也可以架設自己的 serverless  主機，只是這似乎是在向錯誤的方向前進)。由于你的執行時間也是受限的，安全補丁也被簡化了，因為完全不需要重啟。這些都應該由你的服務提供商無縫地處理。

***的可擴展性。這是又一個大的好處。假設你又開發了一個 Pokemon Go, 與其頻繁地把站點下線維護升級，不如用 serverless  來不斷地擴展。當然，這也是個雙刃劍，大量的賬單也會隨之而來。如果你的業務的利潤強依賴于站點上線率的話，serverless 確實能幫上忙。

強制的微服務架構。這也有兩面性，一方面，微服務似乎是一種好的構建靈活可擴展的、容錯的架構的方式。另一方面，如果你的業務沒有按照這種方式設計，你將很難在已有的架構中引入  serverless。

但是現在你被限制在他們的平臺上

受限的環境。你只能用服務提供商提供的環境，你想在 Rust 中用 serverless?你可能不會太幸運。

受限的預裝包。你只有提供商預裝的包。但是你或許能夠提供你自己的包。

受限的執行時間。你的 Function 只可以運行這么長時間。如果你必須處理 1TB 的文件，你可能需要有一個解決辦法或者用其他方案。

強制的微服務架構。參考上面的描述。

受限的監視和診斷能力。例如，你的代碼在干什么? 在 serverless  中，基本不可能在調試器中設置斷點和跟蹤流程。你仍然可以像往常一樣記錄日志并發出統計度量，但是這帶來的幫助很有限，無法定位在 serverless  環境中發生的難點問題。

競爭領域

自從 2014 年出現 AWS Lambda 以后，serverless 的提供商已經增加了一些。下面是一些主流的服務提供商:

• AWS Lambda - 起步最早的

• OpenWhisk - 在 IBM 的 Bluemix 云上可用

• Google Cloud Functions

• Azure Functions

這些平臺都有它們的相對優勢和劣勢(例如，Azure 支持 C#，或者緊密集成在其他提供商的平臺上)。這里面***的玩家是 AWS。

通過 AWS 的 Lambda 和 API Gateway 構建你的***個 API

我們來試一試 serverless。我們將用 AWS Lambda 和 API Gateway 來構建一個能返回 Jimmy 所說的“Guru  Meditations”的 API。

所有代碼在 GitHub 上可以找到。

API文檔：

POST / {     "status": "success",     "meditation": "did u mention banana cognac shower" }

怎樣組織工程文件

文件結構樹:

. ├── LICENSE ├── README.md ├── server │   ├── __init__.py │   ├── meditate.py │   └── swagger.json ├── setup.py ├── tests │   └── test_server │       └── test_meditate.py └── tools     ├── deploy.py     ├── serve.py     ├── serve.sh     ├── setup.sh     └── zip.sh

AWS 中的信息

• API。實際構建的對象。它在 AWS 中表示為一個單獨的對象。

• 執行角色。在 AWS 中，每個 Function 作為一個單獨的角色執行。在這里就是 meditations。

• 角色策略。每個 Function 作為一個角色執行，每個角色需要權限來干活。我們的 Lambda Function  不干太多活，故我們只添加一些日志記錄權限。

• Lambda Function。運行我們的代碼的地方。

• Swagger。 Swagger 是 API 的規范。API Gateway 支持解析 swagger 的定義來為 API 配置大部分資源。

• 部署。API Gateway 提供部署的概念。我們只需要為我們的 API 用一個就行(例如，所有的都用生產或者  yolo等)，但是得知道它們是存在的，并且對于真正的產品級服務，你可能想用開發和暫存環境。

• 監控。在我們的業務崩潰的情況下(或者因為使用產生大量賬單時)，我們想以云告警查看方式為這些錯誤和費用添加一些監控。注意你應該修改  tools/deploy.py 來正確地設置你的 email。

代碼

Lambda Function 將從一個硬編碼列表中隨機選擇一個并返回 guru meditations，非常簡單：

import logging import random  logger = logging.getLogger() logger.setLevel(logging.INFO)  def handler(event, context):      logger.info(u"received request with id '{}'".format(context.aws_request_id))      meditations = [     "off to a regex/",     "the count of machines abides",     "you wouldn't fax a bat",     "HAZARDOUS CHEMICALS + RKELLY",     "your solution requires a blood eagle",     "testing is broken because I'm lazy",     "did u mention banana cognac shower",     ]     meditation = random.choice(meditations)      return {         "status": "success",         "meditation": meditation,     }

deploy.py 腳本

這個腳本相當長，我沒法貼在這里。它基本只是遍歷上述“AWS 中的信息”下的項目，確保每項都存在。

我們來部署這個腳本

只需運行 ./tools/deploy.py。

基本完成了。不過似乎在權限申請上有些問題，由于 API Gateway 沒有權限去執行你的 Function，所以你的 Lambda Function  將不能執行，報錯應該是“Execution failed due to configuration error: Invalid permissions on  Lambda function”。我不知道怎么用 botocore 添加權限。你可以通過 AWS console 來解決這個問題，找到你的 API, 進到  /POST 端點，進到“integration request”，點擊“Lambda  Function”旁邊的編輯圖標，修改它，然后保存。此時將彈出一個窗口提示“You are about to give API Gateway  permission to invoke your Lambda function”， 點擊“OK”。

當你完成后，記錄下 ./tools/deploy.py 打印出的 URL，像下面這樣調用它，然后查看你的新 API 的行為：

$ curl -X POST https://a1b2c3d4.execute-api.us-east-1.amazonaws.com/prod/ {"status": "success", "meditation": "the count of machines abides"}

本地運行

不幸的是，AWS Lambda 沒有好的方法能在本地運行你的代碼。在這個例子里，我們將用一個簡單的 flask 服務器來在本地托管合適的端點，并調用  handler 函數。

from __future__ import absolute_import  from flask import Flask, jsonify  from server.meditate import handler  app = Flask(__name__)  @app.route("/", methods=["POST"]) def index():     class FakeContext(object):         aws_request_id = "XXX"      return jsonify(**handler(None, FakeContext()))  app.run(host="0.0.0.0")

你可以在倉庫中用 ./tools/serve.sh 運行它，像這樣調用：

$ curl -X POST http://localhost:5000/ {     "meditation": "your solution requires a blood eagle",     "status": "success" }

測試

你總是應該測試你的代碼。我們的測試方法是導入并運行我們的 handler 函數。這是最基本的 python 測試方法：

from __future__ import absolute_import  import unittest  from server.meditate import handler  class SubmitTestCase(unittest.TestCase):  def test_submit(self):  class FakeContext(object):  aws_request_id = "XXX"  response = handler(None, FakeContext())  self.assertEquals(response["status"], "success")  self.assertTrue("meditation" in response)

你可以在倉庫里通過 nose2 運行這個測試代碼。

“如何通過AWS的Lambda和API Gateway走向Serverless”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！