閱讀792 返回首頁    go 阿裏雲 go 技術社區[雲棲]

通過 AWS 的 Lambda 和 API Gateway 走向 Serverless

近來，在計算領域出現了很多關於 serverless 的討論。serverless 是一個概念，它允許你提供代碼或可執行程序給某個服務，由服務來為你執行它們，而你無需自己管理服務器。這就是所謂的執行即服務execution-as-a-service，它帶來了很多機會，同時也遇到了它獨有的挑戰。

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

早期，出現了……好吧，這有點複雜。很早的時候，出現了機械計算機，後來又有了埃尼阿克 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文檔：



    

  1. POST /
    2. 

  2. {
    3. 

  3.  "status": "success",
    4. 

  4.  "meditation": "did u mention banana cognac shower"
    5. 

  5. }
    6. 




怎樣組織工程文件


文件結構樹:




    

  1. .
    2. 

  2. ├── LICENSE
    3. 

  3. ├── README.md
    4. 

  4. ├── server
    5. 

  5. │ ├── __init__.py
    6. 

  6. │ ├── meditate.py
    7. 

  7. │ └── swagger.json
    8. 

  8. ├── setup.py
    9. 

  9. ├── tests
    10. 

  10. │ └── test_server
    11. 

  11. │ └── test_meditate.py
    12. 

  12. └── tools
    13. 

  13.  ├── deploy.py
    14. 

  14.  ├── serve.py
    15. 

  15.  ├── serve.sh
    16. 

  16.  ├── setup.sh
    17. 

  17.  └── zip.sh
    18. 



AWS 中的信息（想了解這裏究竟在做什麼的詳細信息，可查看源碼 tools/deploy.py）。


    

  • 
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，非常簡單：




    

  1. import logging
    2. 

  2. import random
    3. 

    4. 

  4. logger = logging.getLogger()
    5. 

  5. logger.setLevel(logging.INFO)
    6. 

    7. 

  7. def handler(event, context):
    8. 

    9. 

  9.  logger.info(u"received request with id '{}'".format(context.aws_request_id))
    10. 

    11. 

  11.  meditations = [
    12. 

  12.  "off to a regex/",
    13. 

  13.  "the count of machines abides",
    14. 

  14.  "you wouldn't fax a bat",
    15. 

  15.  "HAZARDOUS CHEMICALS + RKELLY",
    16. 

  16.  "your solution requires a blood eagle",
    17. 

  17.  "testing is broken because I'm lazy",
    18. 

  18.  "did u mention banana cognac shower",
    19. 

  19.  ]
    20. 

    21. 

  21.  meditation = random.choice(meditations)
    22. 

    23. 

  23.  return {
    24. 

  24.  "status": "success",
    25. 

  25.  "meditation": meditation,
    26. 

  26.  }
    27. 




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 的行為：




    

  1. $ curl -X POST https://a1b2c3d4.execute-api.us-east-1.amazonaws.com/prod/
    2. 

  2. {"status": "success", "meditation": "the count of machines abides"}
    3. 




本地運行


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




    

  1. from __future__ import absolute_import
    2. 

    3. 

  3. from flask import Flask, jsonify
    4. 

    5. 

  5. from server.meditate import handler
    6. 

    7. 

  7. app = Flask(__name__)
    8. 

    9. 

  9. @app.route("/", methods=["POST"])
    10. 

  10. def index():
    11. 

    12. 

  12.  class FakeContext(object):
    13. 

  13.  aws_request_id = "XXX"
    14. 

    15. 

  15.  return jsonify(**handler(None, FakeContext()))
    16. 

    17. 

  17. app.run(host="0.0.0.0")
    18. 



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




    

  1. $ curl -X POST http://localhost:5000/
    2. 

  2. {
    3. 

  3.  "meditation": "your solution requires a blood eagle",
    4. 

  4.  "status": "success"
    5. 

  5. }
    6. 




測試


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




    

  1. from __future__ import absolute_import
    2. 

    3. 

  3. import unittest
    4. 

    5. 

  5. from server.meditate import handler
    6. 

    7. 

  7. class SubmitTestCase(unittest.TestCase):
    8. 

    9. 

  9.  def test_submit(self):
    10. 

    11. 

  11.  class FakeContext(object):
    12. 

    13. 

  13.  aws_request_id = "XXX"
    14. 

    15. 

  15.  response = handler(None, FakeContext())
    16. 

    17. 

  17.  self.assertEquals(response["status"], "success")
    18. 

  18.  self.assertTrue("meditation" in response)
    19. 



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



更多前景


    

  • 
和 AWS 服務的無縫集成。通過 boto，你可以完美地輕易連接到任何其他的 AWS 服務。你可以輕易地讓你的執行角色用 IAM 訪問這些服務。你可以從 S3 取文件或放文件到 S3，連接到 Dynamo DB，調用其他 Lambda Function，等等。
    • 

  • 
訪問數據庫。你也可以輕易地訪問遠程數據庫。在你的 Lambda handler 模塊的最上麵連接數據庫，並在handler 函數中執行查詢。你很可能必須從它的安裝位置上傳相關的包內容才能使它正常工作。可能你也需要靜態編譯某些庫。
    • 

  • 
調用其他 webservices。API Gateway 也是一種把 webservices 的輸出從一個格式轉換成另一個格式的方法。你可以充分利用這個特點通過不同的 webservices 來代理調用，或者當業務變更時提供後向兼容能力。
    • 





原文發布時間為：2016-10-26


本文來自雲棲社區合作夥伴“Linux中國”


最後更新：2017-05-22 15:02:57
  上一篇：go  案例 | 從RISC到 x86，飛機維修業翹楚Ameco 轉型記
  下一篇：go  ajax實現JSONP跨域