您好,登錄后才能下訂單哦!
本篇文章為大家展示了Serverless架構的編程學習小工具有哪些,內容簡明扼要并且容易理解,絕對能使你眼前一亮,通過這篇文章的詳細介紹希望你能有所收獲。
之前我做過一個在線編程的軟件,目前用戶量大概有幾十萬,通過這個 App 不僅僅可以進行代碼的編寫、運行還可以進行編程的學習。自己一直對 Serverless 架構情有獨鐘,恰好趕到我的這個 App 學習板塊被很多人吐槽難用,索性就對這個學習板塊進行重構,并且打算在重構的時候,直接將這個學習板塊搬上 Serverless 架構。
基于 Serverless 架構重構是出于兩個方面考慮 —— 一是 Serverless 架構能讓個人開發者的運維工作變得簡單,尤其是不用操心服務器,也不用關心流量洪峰(當然,對于我的個人項目而言,也沒太多的洪峰),二是 Serverless 架構的按量付費,極大節約了成本。
這個部分在之前是若干個大模塊,現在統一整理到一個模塊中進行項目重構,所以這里繼續復用之前的數據庫:
在這個數據庫中,四個模塊分別是:新聞文章、開發文檔、基礎教程以及圖書資源。其中開發文檔包括大分類,子列表以及正文等內容,這里表關聯并沒有使用外鍵,而是直接用的 ID 進行表之間的關聯。
說實話,這個數據庫設計的并不是很好,原因是因為初次構建這個數據部分,絕大部分數據都是在其他站點采集而來,當時由于模塊快速上線,便直接按照原有格式存儲,所以可以認為這個數據庫中有很多表的字段其實是無效的,或者針對這個項目是未被使用的。
后端將會整體部署到一個函數上,功能整體結構:
整體功能就是云函數 SCF 綁定 API 網關觸發器,用戶訪問 API 網關指定的地址,觸發云函數,然后函數在入口處進行功能拆分,請求不同的方法獲得對應的數據。
這里要額外說明一下,后端整體接口部署在一個函數的原因,是因為我這個模塊的使用量并不是非常頻繁,所以部署到一個函數上也不會出現超過最大實例的限制,如果超出限制是可以申請擴容的;
其次,所有的接口都是對數據庫增刪改查,放入到一個函數中,在一定程度上可以保證容器的活性,降低部分冷啟動帶來的問題,同時容器的復用,也可以在一定程度上降低后臺數據庫鏈接池的壓力;除此之外,所有的接口功能,都是只需要最少的內存(64M)即可完整運行,不會因為個別接口的預估內存較大,進而影響影響整體的成本。
所以這里評估之后,是可以將多個接口,放入到一個函數中,對外提供對應的服務。
前端設計,預計在學習資源部分需要有 8 個頁面,主要就是科技類新聞、教程、文檔、圖書等相關功能,通過墨刀繪制的原型圖如下:
前端項目開發將會采用 Vue.js,并且將其部署到對象存儲中,通過騰訊云對象存儲的靜態網站功能對外提供服務。
后端函數開發主要包括三部分
部分資源的初始化,部分資源初始化,需要在函數外進行,這樣可以保證復用實例的時候不會再次建立鏈接,防止數據庫連接池出現問題:
def getConnection(dbName): conn = pymysql.connect(host="", user="root", password="", port=3306, db=dbName, charset='utf8', cursorclass=pymysql.cursors.DictCursor, ) conn.autocommit(1) return conn connectionArticle = getConnection("anycodes_article")
數據庫查詢操作
這一部分主要就是針對不同接口查詢數據庫,例如獲取文章分類:
def getArticleCategory(): connectionArticle.ping(reconnect=True) cursor = connectionArticle.cursor() search_stmt = ('SELECT * FROM `category` ORDER BY `sort`') cursor.execute(search_stmt, ()) data = cursor.fetchall() cursor.close() result = {} for eve_data in data: if eve_data['pre_name'] not in result: result[eve_data['pre_name']] = [] result[eve_data['pre_name']].append({ "id": eve_data["sort"], "name": eve_data["name"] }) return result
例如獲取文章列表:
def getArticleList(cid): connectionArticle.ping(reconnect=True) cursor = connectionArticle.cursor() search_stmt = ('SELECT * FROM `article` WHERE `category` = %s ORDER BY `sort`') cursor.execute(search_stmt, (cid,)) data = cursor.fetchall() cursor.close() result = [{ "id": eve_data["aid"], "title": eve_data["title"] } for eve_data in data] return result
最后一部分就是函數的入口,函數入口部分就是做功能分發和接口識別:
def main_handler(event, context): try: result_data = { "error": False } req_type = event["pathParameters"]["type"] if req_type == "get_book_list": result_data["data"] = getBookList() elif req_type == "get_book_info": result_data["data"] = getBookContent(event["queryString"]["id"]) elif req_type == "get_daily_content": result_data["data"] = getDailyContent(event["queryString"]["id"]) elif req_type == "get_daily_list": result_data["data"] = getDailyList(event["queryString"]["category"]) elif req_type == "get_dictionary_result": result_data["data"] = getDictionaryResult(event["queryString"]["word"]) elif req_type == "get_dev_content": result_data["data"] = getDevContent(event["queryString"]["id"]) elif req_type == "get_dev_section": result_data["data"] = getDevSection(event["queryString"]["id"]) elif req_type == "get_dev_chapter": result_data["data"] = getDevChapter(event["queryString"]["id"]) elif req_type == "get_dev_list": result_data["data"] = getDevList() elif req_type == "get_article_content": result_data["data"] = getArticle(event["queryString"]["id"]) elif req_type == "get_article_list": result_data["data"] = getArticleList(event["queryString"]["id"]) elif req_type == "get_article_category": result_data["data"] = getArticleCategory() return result_data except Exception as e: print(e) return {"error": True}
函數部分完成之后,可以配置 API 網關部分:
在整個后端接口開發過程中,其實并沒有遇到什么太大的問題,因為這個學習功能的模塊基本上就是對數據庫進行查詢的操作,所以相對來說非常順利。
整體預覽結果:一共包括十幾個頁面,這里取其中8個主要的頁面進行效果展示:
整個頁面基本上是還原了設計稿的樣子,并且和原有項目進行了部分的整合,無論是列表頁面還是圖書頁面等,數據加載速度表現良好。
通過 PostMan 進行基本測試:
對接口進行 1000 次訪問測試:
可以看到,接口表現良好,并未出現失敗的情況,對該測試結果進行耗時的可視化:
其中最大的時間消耗是 219 毫秒,最小是 27 毫秒,平均值 35 毫秒,可以看到整體的效果還是非常不錯。
這樣一個項目開發完成,上線之后,前端部分被放到對象存儲 COS 中,后端業務被放到云函數 SCF 中,觸發器使用的是 API 網關,在監控層面,函數計算有著比較不錯的監控緯度:
同時函數并發,彈性伸縮等問題都由云廠商來解決,可以這樣說,自從這個組件部署到了 Serverless 架構上,我所做的操作就是如果業務代碼有問題,進行簡單修復和簡單維護。講真,整個效果還是不錯的。
通過按量付費,可以看到我后端服務產生的費用:
由于云函數沒辦法看到單個資源的費用,所以整個函數我有幾十個,一共花費的費用也遠遠比服務器的一個月便宜很多。
當然雖然說在計算服務這里整體費用只有幾元錢相對來說非常便宜,但是其還有 API 網關的費用和對象存儲的費用,例如 API 網關費用:
同樣,我這里的 API 網關也是有很多服務的,不僅僅是 Anycodes 這樣一個服務產生的,但是整體加一起 2 月份只有 1 元錢,相對來說也是蠻低的。
通過個人項目中的一個子模塊重構過程,將該項目部署到 Serverless 架構上:
在開發過程中,我覺得是蠻方便的,一方面自己不需要在服務器中安裝各類軟件,也不需要搭建 web 服務,不需要對 web 服務進行優化,做的只是讀取數據庫,按照一定的格式進行 return,至于 web 服務等相關模塊交給 API 網關來實現,整個一個后端開發大概耗時大約是一個多小時;前端開發是比較耗時的,因為我個人不是專業做前端的,所以無論是布局還是邏輯開發,都是有點障礙的,但是也只用了 2 天時間;所以這個模塊從開發到上線只用了 2 天時間;
項目在部署的時候非常流暢,基于 Serverless Framework 的開發者工具一鍵部署,后期更新維護,只需要重新部署即可,線上也是無縫切換,不會出現更新服務造成的服務中斷,也不用為更新服務可能造成服務中斷而做額外的操作,整體后期更新過程快速且簡單易用;
資源消耗部分就是使用按量付費,通過一個月的觀察,整個資源消耗是蠻低的,整體性能保證的同時,成本也逐漸的被壓低,對于個人開發者來說,確實是一個福音。
通過這樣一個簡單上 Serverless 架構的過程,也讓我對 Serverless 架構有了更深入的了解和認識,作為一種新技術或者說新的架構,Serverless 的成長還需要一段時間。但是我相信,他的成長,會很快速。
上述內容就是Serverless架構的編程學習小工具有哪些,你們學到知識或技能了嗎?如果還想學到更多技能或者豐富自己的知識儲備,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。