以云計算目前的創新速度，業內流行語和噱頭可能會從字面上給用戶造成誤導或混淆。可能你已經聽說過使用無服務器計算平臺構建應用程序，或設計運行在微服務架構上的軟件等類似例子。即使這些想法聽起來像噱頭，但現實是，他們正在改變企業構建、部署和運行應用程序的方式。
無服務器計算是開發人員構建應用程序而不必考慮服務器的一種方式。它只是個抽象層，使開發人員能夠專注于編寫代碼，同時忽略服務器和傳統基礎設施概念。
2014年，亞馬遜發布AWS Lambda，這項服務使開發人員能夠創建在現有托管實例上運行基于云的函數。 AWS稍后發布了其API網關服務，可用于配置公共節點以通過HTTP調用Lambda函數。綜合來看，AWS Lambda和API網關能夠幫助組織建立Web、移動和互聯網后端，這些后端完全可擴展，而且不需要服務器。
AWS技術被認為是無服務器計算架構類的領導者，但該公司不是唯一提供商。 Microsoft、Google、IBM等也發布了類似產品，被視為函數服務(FaaS)。開發人員可以與任何提供者創建和運行函數，以實現無服務器應用程序體系結構。
更高的可擴展性效率
無論FaaS平臺如何，無服務器計算架構受到很多關注。以下是FaaS平臺的一些主要功能，使其成為一種極具顛覆性的技術。
· 降低復雜性。 在公有云平臺如AWS和Azure的支持下，構建高可用性的應用程序架構變得更為容易。在負載平衡器后啟動自動縮放的虛擬機非常簡單。你甚至可以跨多個地區擴展應用程序架構，以實現地理冗余。
通過無服務器計算，基礎架構將消失。開發人員可以完全專注于編寫支持應用程序功能的代碼。云平臺負責管理調用這些功能的服務器，因此其可用性非常之高。
· 內置可擴展性。 在云中構建Web應用程序的最棘手的部分之一是調整虛擬服務器規模的自動縮放。必須找到正確的平衡點，以確保可以根據流量峰值進行擴展，并在高峰消失時收縮。聽起來很簡單，但每個應用程序都有自己的行為，并且必須調整設置以優化成本并提供最佳性能。使用無服務器計算，就是將這項任務轉移到供應商，客戶可以更自由地關注應用程序。例如，AWS Lambda服務運行在完全管理下的Elastic Compute Cloud實例上。該服務將根據正在執行的代碼對應用程序進行擴展，開發人員或運維工程師不再需要管理虛擬機或自動縮放組。
· 消除空閑資源。 無服務器計算的另一大優點是，只需要在實例運行代碼時才付費。對于傳統服務器，即使使用自動縮放應用程序，也會占用一些資源。但是無服務器，只有有人實際使用應用程序時，才需要付費。不必支付小時費用來運行可能執行或未進行任何工作的虛擬機。AWS通過其Lambda服務提供次秒計量，因此只需按每100毫秒執行代碼的次數來計費。其他FaaS提供商提供類似的定價。
深入無服務器架構
要了解無服務器應用程序的構建方式，讓我們看看使用AWS無服務器架構的常見Web應用程序。
· 前端層。
為Web應用程序前端提供支持的靜態資源托管在Amazon Simple Storage Service(S3)(即AWS對象存儲服務)中。你可以使用S3將某個bucket，理解為某個文件夾，轉換成靜態網站。可以在此位置存儲HTML、Javascript、CSS文件和圖像靜態內容。
Amazon CloudFront(內容傳送網絡(CDN))分發這些資源。CDN是可選的，但可以減少最終用戶訪問靜態內容的延遲。總的來說，這個想法是，通過客戶端Javascript框架與靜態無服務器網站驅動應用前端。該框架可以調用Lambda為應用程序執行后端工作。
· API層。
在這種情況下，AWS Lambda和API網關為網絡應用程序的后端支持。開發人員可以編寫離散的無狀態Lambda函數來處理支持應用程序的各種資源的創建、讀取、更新和刪除操作。前端代碼通過API網關調用Lambda函數來為應用程序做大量工作。
· 數據庫層。
持久性數據可以存儲在其他托管服務中，例如Amazon DynamoDB，即NoSQL數據庫服務，或Amazon Relational Database Service。 AWS Lambda功能可以直接與這些服務進行通信，以保留數據。
請記住，這只是無服務器架構的一個例子。移動和互聯網的后端，以及實時流處理，是無服務器計算的其他用例。
亞馬遜和Netflix多年來一直使用微服務架構風格。微服務的想法是將一個大型應用程序分解成面向任務的服務集合。
商業應用程序通常構建為單個唯一單元。這些通常包括為最終用戶提供HTML的應用程序前端，用于處理繁重的業務的后端服務器端代碼以及用于存儲和保留數據的數據庫層。單片應用架構多年來運作良好。但隨著應用程序的發展，為支持大量的用戶，更新變得更加困難。因為單片應用程序的組件是緊密耦合的，即使對代碼庫的輕微更改也可能需要一個全新版本的應用程序。
作為替代，許多較小的微服務器可以集中地為整個應用程序提供支撐。因為微服務通常沒有連帶責任，他們專注于實現單一工作或執行支持整個應用程序的某個任務。
微服務的好處
那么為什么企業需要分解單一應用程序來組建微服務架構呢?有一些堅實的理由。
微服務組成部分：輕量級應用程序;耦合低，甚至沒有;更改代碼庫可能需要完整的APP新版本。
·故障隔離。 當應用程序的每個組件作為單獨的服務運行時，可能會失敗，而不會破壞整個系統。負責微服務的不同小團隊可以快速迭代，并對代碼庫進行更改，而不會在整個應用程序中造成錯誤。這樣可以減少應用程序的總體停機時間，并提高小型團隊構建和支持特定微服務器的生產率。
·松耦合。每個微服務都是完全獨立的，可以運行自己的技術棧。只要應用程序內的其他服務可以使用非專用HTTP API與微服務器進行通信，則微服務器的基礎實現可隨時更改。這使得團隊能夠實現最有意義的技術，并且它防止了使用單個技術堆棧來滿足整個單應用程序的要求。
·減少進入障礙。較小的微服務不太復雜，因此更容易理解。這使得新加入的開發人員更容易與現有團隊進行合作。
與目前利用公共云的FaaS不同，微服務架構可以在內部機房或云端運行。
雖然使用容器構建微服務是常見的，但新興的實踐是構建微服務器架構與無服務器功能。你可以在Amazon S3中部署靜態網站，并使用前端代碼在整個體系結構中調用一個或多個微服務API。
在嘗試之前的考慮
毫無疑問，這里討論的模式和做法有很大的優勢。然而，在深入無服務器的微服務之前，有一些重要的事情要考慮。
·供應商鎖定。 每個無服務器的計算平臺都具有自己的功能和特性。一般來說，通用語言，包括Javascript、Python和C#將可從AWS，Microsoft和其他主要提供商獲得。
即使如此，決定拿起并移動到另一個平臺也許需要大量的工作。
·開發工具。 在這個階段最大的困難之一是開發者工具。致力于大規模無服務器應用程序開發的IT團隊需要通過一些工具管理依賴關系。預計未來幾年該領域將會大幅進步。
·服務限制 每個提供商將有自己的函數可以執行多長時間，以及可用于應用程序代碼和依賴關系的容量限制。
這是在檢查無服務器應用程序時應該注意的事項。
·業務成熟度。部署和支持微服務架構并不是為了微弱的心臟。當然，亞馬遜、微軟和Netflix都已經非常成功地采用了這些模式。但并不是每個團隊都有類似的技術技能。如果您正在考慮使用無服務器的微服務方法，請準備聘請有才華的員工，并提供培訓，以便現有員工能夠獲得成效。
京公網安備 11010502049343號