在使用云函式進行專案開發的時候，當函式數量變多后，經常碰到的一個問題，就是對這些函式的依賴庫的管理問題，由于云函式在創建或更新時，需要將函式的業務代碼，和依賴庫一同打包上傳，因此在本地開發時，也經常是將依賴庫和業務代碼放置在一個檔案夾下，
在這種情況下，每個云函式的代碼目錄下均有一套依賴庫代碼，而這其中有很多在若干個函式中都是重復的，不但占用了大量的空間，而且管理麻煩，在某些依賴庫需要進行升級時，要進入到每個函式專案中去檢查依賴關系和升級操作，而另一方面，這些依賴庫通常不會有大的變動，但是卻需要在每次函式進行更新時，都要和業務代碼一同打包上傳，導致實際的代碼更新可能就一兩行，但是需要生成一個十幾兆甚至幾十兆的包去上傳，在網路環境不好的情況下還需要忍受緩慢的上傳速度，
騰訊云的 SCF 云函式近期推出的層功能，就是為了這類不經常變動的依賴庫或靜態檔案而準備的產品功能，通過使用層功能來存盤及管理依賴庫，并在使用時按需與函式進行系結，就可以實作依賴庫的多函式共享，僅需上傳一份，就可以在多個要使用到的函式中系結并參考；通過與云函式系結的使用方式，也就意味著不需要在云函式的業務代碼中再附上相應的依賴庫了，可以將業務代碼和依賴庫分開進行管理和部署，降低云函式每次上傳時需要提交的包大小，加快上傳更新的速度，
在實際案例介紹前，先介紹一下層的功能點，
層作為一個和云函式獨立的資源，有獨立的創建、管理流程，和函式創建類似，可以通過上傳 zip 包，或者控制臺上選擇檔案夾，或者將 zip 包提前上傳 cos 后再參考的方式，來將檔案內容提交到云上，并創建好層，每一個提交到層中的檔案包，都將生成一個新的版本，
因此，在創建好一個層以后，就將具有了第一個版本；而后續如果依賴庫或檔案內容有升級，可以繼續更新層，并生成新的版本，版本號依次增大，在創建層，或發布新版本的時候，還可以指定當前層所可支持的 runtime，這樣相應 runtime 的函式，才可以瀏覽或系結當前層，
在使用層時，通過云函式與具體層的具體版本系結，來實作層內容的引入和使用，在函式的配置管理界面，新增加了層的系結配置界面，通過選擇層及期望系結的版本，就可以完成系結操作，系結了層以后，在函式運行時，運行環境中的 /opt 目錄下就會有層的內容，當然，系統中的 NODE_PATH，PYTHONPATH 已經指定好了 /opt 目錄，系結好的層中如果包含有依賴庫，在函式代碼中可以直接通過 import，require 等方法直接參考，與常規寫法一致，不需要額外進行路徑的指定，同時，目前一個函式支持最多系結 5 個層的版本，因此可以通過這種方法，將所需的依賴庫分別引入到層中，
在多個層系結到同一個函式時，層之間有一定的順序關系，層是按照順序關系依次加載的，如果在相同路徑下有同名檔案，會產生后加載的檔案覆寫先加載檔案的問題，需要在此處注意多個層系結時是否會有內容覆寫，以及加載循序是否是按自身的控制需要來的，另一方面，層與函式的系結關系，也作為函式的配置保存，$LATEST版本的函式可以按需修改調整系結配置，而一旦發布版本后，生成的函式版本中的配置就固定了，無法再次修改，因此，通過發布版本來固化已經開發完成的版本，可以避免函式代碼或層內容的修改導致的代碼不可用，
接下來，我們就將通過一個使用案例來介紹層功能的使用，
在這個案例中，我們將實作一個撥測網站，并在檢測到例外時發送訊息到 cmq 訊息佇列中的云函式，這個云函式由 python 寫成，將使用兩個依賴庫，requests 庫用來實作 url 地址的 http 訪問檢測，及 cmq 庫用來實作向 cmq 的佇列發送訊息，
在創建函式前，我將使用這兩個庫分別創建兩個層，并在后續將函式與這兩個層系結來使用依賴庫，
首先在本地分別創建兩個檔案夾： requests-lib 和 cmq-lib
通過命令列進入 requests-lib 檔案夾后，執行命令
pip install requests -t
在此目錄下完成 requests 庫的下載安裝，而在 cmq-lib 檔案夾內，我們通過下載或 clone https://github.com/tencentyun/cmq-python-sdk 專案，將 cmq 的 sdk 下載到本地，
接下來，使用這兩個檔案夾分別創建兩個層，
同樣命名為 requests-lib 和 cmq-lib，
通過直接選擇檔案夾創建，并選擇好適配 runtime 為 python2
在創建完成兩個層后，他們都具有版本 1可供函式系結，
同時，我在相同地域下也創建好了名字為 testq 的 cmq 佇列，并根據 sdk 需要準備好了賬號 id，secret id，secret key 等資訊，
接下來，我將使用如下代碼創建函式 detect-sendmsg，實作 url 的撥測，并向 cmq 訊息佇列中發送訊息，代碼中的 appid、secretid、secretkey，需要替換為自身賬號下的相關內容，
# -*- coding: utf8 -*-
import json
import logging
import os
from cmq.account import Account
from cmq.cmq_exception import *
from cmq.topic import *
import requests
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)
print('Loading function')
appid = 1252724xxx #please change to your appid. Find it in Account Info
secretId = 'AKIDkkxxxxxxxxxxxxxxx' #please change to your API secret id. Find it in API secret key pair
secretKey = ‘xxxxxxxxxxxxxxxxxx' #please change to your API secret key. Find it in API secret key pair
region = u'gz'
endpoint = 'https://cmq-queue-gz.api.qcloud.com'
my_account = Account(endpoint, secretId, secretKey)
my_account.set_log_level(logging.INFO)
queue_name = 'testq'
my_queue = my_account.get_queue(queue_name)
test_url_list = [
"http://www.baidu.com",
"http://www.qq.com",
"http://cloud.tencent.com",
"http://unkownurl.com"
]
def test_url(url_list):
errorinfo = []
for url in url_list:
resp = None
try:
resp = requests.get(url,timeout=3)
except (requests.exceptions.Timeout, requests.exceptions.ConnectionError, requests.exceptions.ConnectTimeout) as e:
logger.warn("request exceptions:"+str(e))
errorinfo.append("Access "+ url + " timeout")
else:
if resp.status_code >= 400:
logger.warn("response status code fail:"+str(resp.status_code))
errorinfo.append("Access "+ url + " fail, status code:" + str(resp.status_code))
if len(errorinfo) != 0:
send_msg("撥測例外通知:"+"\r\n".join(errorinfo))
def send_msg(msg_body):
try:
logger.info("send msg"+msg_body)
msg = Message(msg_body)
ret_msg = my_queue.send_message(msg)
except CMQExceptionBase as e:
logger.warn("Send msg to queue Fail! Exception:%s\n" % e)
raise e
def main_handler(event, context):
test_url(test_url_list)
return “finish"
使用此代碼創建好函式，并在函式的層管理中，分別系結好 requests-lib、cmq-lib 兩個層，由于這兩個層沒有重復部分，因此可以以任意順序系結，
完成系結后，可以直接通過控制臺觸發函式，查看運行情況，一切正常的情況下，可以看到撥測的程序，以及訊息發送到訊息佇列中的記錄，同時，也可以到訊息佇列的對應 queue 中，通過獲取訊息，獲取到發送到其中的訊息記錄，
從這個例子中可以看到，函式代碼中應用了 requests 庫，和 cmq 的 sdk，但并未通過和函式一同打包上傳來實作，而是將依賴庫放置到層里面后，通過系結關系來參考，通過這種方式，如果下次我們啟動一個新的函式也需要使用到 requests 庫，直接與已有的層系結即可使用，而同樣不需要再次打包上傳，而函式代碼僅一個檔案，不需要帶有較大的依賴庫，也可以降低每次更新上傳時的包大小，甚至直接快速的使用 WebIDE 來進行編輯就行，
層的功能為依賴庫和不經常修改的靜態檔案提供了新的存盤方案，與函式的剝離使得這類檔案能夠多函式復用，版本化管理；隨著層功能的發展，騰訊云 Serverless team 也將進一步拓展層功能的使用，包括了在開發工具中實作自動化的層創建和系結、層的共享、提供公共層供用戶直接復用等，都已經在 roadmap 中，將在接下來的發展中逐步落地，供云函式的開發體驗更加便利，
Tencent Serverless Hours 線上分享會第一期回放觀看請戳：
https://cloud.tencent.com/edu/learning/live-2437
Serverless Framework 30 天試用計劃
我們誠邀您來體驗最便捷的 Serverless 開發和部署方式，在試用期內，相關聯的產品及服務均提供免費資源和專業的技術支持，幫助您的業務快速、便捷地實作 Serverless！
詳情可查閱：Serverless Framework 試用計劃
One More Thing
3 秒你能做什么？喝一口水，看一封郵件，還是 —— 部署一個完整的 Serverless 應用？
復制鏈接至 PC 瀏覽器訪問：https://serverless.cloud.tencent.com/deploy/express
3 秒極速部署，立即體驗史上最快的 Serverless HTTP 實戰開發！
傳送門：
- GitHub: github.com/serverless
- 官網：serverless.com
歡迎訪問：Serverless 中文網，您可以在 最佳實踐 里體驗更多關于 Serverless 應用的開發！
推薦閱讀：《Serverless 架構：從原理、設計到專案實戰》
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/18057.html
標籤：其他
下一篇：關于docker常用指令