有關云可移植性的三個考量:三事件驅動架構(EDA)和無服務器計算?
在這一系列文章中,我們將從架構、設計等不同方面來探討,在云的可移植性方面,具體都需要考慮哪些細節問題,如何最大限度避免云時代的技術鎖定,充分發揮云的靈活性優勢。
延伸閱讀,了解 Akamai cloud-computing
出海云服務,選擇Akamai cloud-computing!
下文將簡要探討事件驅動架構以及無服務器計算。歡迎點擊這里回顧云原生和容器技術在云可移植性方面的注意事項;或點擊這里回顧微服務架構對云可移植性的重要意義。
事件驅動架構(Event-Driven Architecture,EDA)會對事件或消息做出反應并觸發特定操作,但不依賴于直接的同步通信。EDA是異步的,這樣組件即可獨立運行,從而提高系統在可變工作負載下的響應能力和性能。
我們可以考慮兩個簡單的例子:文件上傳和新用戶注冊。這兩個操作都可以通過通過同步的請求-響應流(例如REST API)發生,但需要發出新請求以更新文件上傳狀態,或在將新用戶的數據插入數據庫后通過新請求觸發需要執行的下一步操作。假設有一群任務運行程序正在不斷地輪詢消息,甚至在“無線電靜默期”或者完全與自己無關的時間段內,它們也會不知疲倦地輪詢。可想而知,如果使用了按需付費的彈性云計算資源,這種方式會造成巨大浪費。EDA通過基于推送的方法解決了這個問題。
事件驅動系統可以按需添加或移除組件從而快速擴展,并對故障獲得極高適應性,因為即便某一個組件不可用,系統依然能繼續運行。EDA也非常適合實時處理以及海量數據處理,因為組件可以對事件做出反應并在數據到達時就立即開始處理,而不需要等待收到完整的數據集。
為何要使用EDA?
- 增強系統靈活性:事件驅動架構松散耦合的特性使得我們可以輕松修改、添加或移除組件而不影響整體系統,從而讓系統能夠適應不斷變化的需求。
- 提高可擴展性:EDA支持非常方便的水平擴展,借此,企業可以根據需要添加更多組件或服務實例,從而應對增加的工作負載或流量。
- 提高系統彈性:EDA的異步通信以及解耦的組件有助于提高容錯能力,因為一個組件的故障并不一定導致整個系統中斷。
- 實時處理能力:EDA能實時處理大量數據和復雜的事件模式,因此很適合需要立即獲得洞察力或對快速變化的情況快速做出反應的業務場景。
- 優化資源使用:通過僅在事件發生時對其做出反應,EDA有助于優化資源利用率并減少對持續運行流程的需求,從而幫助企業節約成本,提高效率。
云原生無服務器計算
EDA同樣支持類似無服務器計算這樣的應用程序開發模型,這樣我們就可以編寫可移植,并且與特定供應商無關的代碼,從而根據功能、支持的語言、成本等因素靈活選擇適合自己的云供應商。函數即服務(Functions-as-a-Service,FaaS)是一種流行的產品,很多云供應商都已提供,用戶可以通過這類產品在一個位置管理函數和應用程序基礎設施。云供應商作為責任人,主要負責處理底層基礎設施,包括服務器的配置、縮放和維護,這樣開發者就可以更專注地編寫代碼。
很多流行的FaaS服務(例如AWS Lambda、Azure Functions以及Google Cloud Functions)就是我們所說的平臺原生服務。它們通常會限制用戶只能使用特定云提供商的平臺,無法輕松遷移至其他平臺。Akamai曾多次介紹過,Knative是一種開源、基于Kubernetes的無服務器運行平臺,只需幾秒鐘即可將應用程序從0個副本擴展到N個副本。擴展到0個副本這種能力非常實用,可以讓Kubernetes和Knative按需重新分配資源。
我們只需要使用一段代碼即可自動擴展資源,因為這種代碼可以并行調用多次。從本質上來看,并不建議使用上文提到的平臺原生FaaS產品,因為這類服務的費用是不可預測的。但如果通過托管的Kubernetes服務在我們的計算實例上運行Knative,用戶就只需要支付一個固定并且可預測的費用,而不必擔心某些服務的免費額度用完后開始按照執行次數計費。
為何使用無服務器?
- 成本效率:無服務器計算按用量付費的定價模型有助于節約成本,企業只需要為自己實際使用的計算時間付費,無需提前分配資源。
- 提高可擴展性:無服務器計算可以自動擴展資源以滿足需求,確保應用程序可以順利處理激增的工作負載而無需人工介入或停機。
- 降低運維開銷:對于無服務器計算,云提供商負責管理底層基礎設施,這樣IT團隊就能更專注于應用程序的開發、創新,以及其他戰略性活動。
- 更快的上市時間:無服務器計算簡化的開發和部署流程有助于企業更快速發布新功能、更新以及Bug修復,從而增強自己的競爭優勢。
- 靈活性和適應性:無服務器計算使得企業能夠使用各種編程語言和技術構建并部署應用程序,從而更易于適應需求的變化或按需融入新技術。
正如上文所說,無服務器計算基于事件驅動架構,這意味著函數可以由HTTP請求、文件上傳、數據庫更新等事件來觸發。這有助于簡化應用程序架構并改善可擴展性。
無服務器函數的世界也應該是無狀態的。函數在不同調用之間不存儲任何數據或狀態,這保證了函數可以輕松擴展,并且函數故障后可以輕松替換。函數還應當是短暫的,這保證了資源不會被浪費,并且函數能夠快速擴展。如果一個函數的任務需要長時間運行,則需評估是否更適合使用持續運行的服務來代替。
無服務器函數同樣需要監視并記錄日志,這樣才能確保函數按照預期運行,同時發現可能存在的任何問題或錯誤。為此可以使用一些日志聚合器和應用程序性能監視(APM)工具,例如Prometheus和Grafana。另外,別忘了通過身份驗證、認證授權、加密等最佳實踐措施保護函數,這樣不僅可以保護應用程序本身,也能保護敏感數據。在將函數部署到生產環境之前,請進行完善的測試,從而確保函數能夠按照預期運行并且不存在漏洞。
無服務器計算極具成本效益,但為了進一步降低成本提高效率,依然需要使用各種成本優化技術,例如函數優化、資源共享以及自動擴展。用戶有必要評估自己的工作負載、使用模式以及需求,從而決定對于自己的特定用例來說,無服務器計算是否是一種具備成本效益的方式。另外,對于選擇使用的無服務器平臺,還需要考慮預期使用模式、性能需求以及定價結構。
這篇文章的內容感覺還行吧?您還可以進一步了解Akamai的云服務方案!別忘了,現在注冊可以免費獲得價值 100 美元的使用額度,快點自己動手體驗本文介紹的功能和服務吧↓↓↓
歡迎關注Akamai ,第一時間了解高可用的MySQL/MariaDB參考架構,以及豐富的應用程序示例