關於無服務器（Serverless）架構你要搞懂的8件事

無服務器計算，雖然神祕，但必定會成爲IT行業最有力的工具之一。這種可能改變遊戲規則的技術雖然不是全新的，但就像以前的容器技術同樣，有一些神化和誤解。

1什麼是無服務器（Serverless）計算？

無服務器計算容許企業構建、運行應用和服務而不用去考慮服務器。無服務器應用不須要管理任何服務器，並且任何類型的應用或後端服務均可以構建爲無服務器應用。運行應用以及應用高可用所須要的一切，都由雲服務商來提供。

無服務器應用程序有四大優點:

1)不須要管理服務– 不須要提供或維護任何的服務器，不須要安裝任何的軟件或運行時。

2）彈性擴縮–應用程序擴縮能自動完成或是經過調整其資源使用量來調整容量，而不是經過增減服務器的數量。

3）高可用－無服務器應用程序內置高可用和容錯。無需考慮高可用，運行應用的服務默認提供高可用。

4）沒有閒置損耗－不須要對計算和存儲之類的服務預留容量。若是代碼沒有運行，就不會收費。

構建無服務器應用程序意味着開發者能夠專一在產品代碼上，而無須管理和操做雲端或本地的服務器或運行時。

2無服務器（Serverless）計算如何工做？

與使用虛擬機或一些底層的技術來部署和管理應用程序相比，無服務器計算提供了一種更高級別的抽象。由於它們有不一樣的抽象和「觸發器」的集合。

拿計算來說，這種抽象有一個特定函數和抽象的觸發器，它一般是一個事件。以數據庫爲例，這種抽象也許是一個表，而觸發器至關於表的查詢或搜索，或者經過在表中作一些事情而生成的事件。

好比一款手機遊戲，容許用戶在不一樣的平臺上爲全球頂級玩家使用高分數表。當請求此信息時，請求從應用程序到API接口。API接口或許會觸發 aws 的Lambda函數，或者無服務器函數，這些函數再從數據庫表中獲取到數據流，返回包含前五名分數的必定格式的數據。

一旦構建完成，應用程序的功能就能夠在基於移動和基於 web 的遊戲版本中重用。

這跟設置服務器不一樣，不是必需要有Amazon EC2實例或服務器，而後等待請求。環境由事件觸發，而響應事件所需的邏輯只在響應時執行。這意味着，運行函數的資源只有在函數運行時被建立，產生一種很是高效的方法來構建應用程序。

3適用於哪些場景？

無服務器計算適合於任何事件驅動的各類不一樣的用例。這包括物聯網，移動應用，基於網絡的應用程序和聊天機器人。事件是由人的動做（好比按下按鈕），傳感器或者系統中的數據流產生。

這方面的一個例子是，Thomson Reuters（人名）使用AWS Lambda來加載和處理數據流，而無需提供或管理任何服務器。Thomson Reuters創建了一個解決方案，使其可以捕捉、分析和可視化其產品所生成的分析數據，提供幫助產品團隊不斷改進用戶體驗的看法。

AWS Lambda只在經過與其餘AWS服務、Kinesis和AmazonS3集成的新數據條目觸發時運行代碼。

在事件驅動下，當代碼運行時，公司只收取計算處理的費用，這是很是節約成本的。

4不適用哪些場景？

對於已經構建的遺留應用程序來講，這不必定是一個徹底的解決方案。若是是一個單體應用或者應用須要運行在操做系統級別，這樣的應用就不適合在無服務器平臺上運行。這並不意味着這樣的應用無法實現無服務器架構，它只是意味着須要從新構建應用程序。

一個很好的例子是web應用程序，能夠在應用程序服務器(如Tomcat)中將其做爲一個大型的單體job運行。若是要將應用程序分解爲複合函數集，則可使用無服務器模型實現全部的新功能。隨着時間的推移，舊版本應用程序的使用級別愈來愈小，這些新的無服務器組件的使用率隨着使用量的增長而增長。對於這樣的客戶，都有一個過渡模型，客戶能夠遵循這種過渡模式，將傳統的基於機器的應用程序架構遷移到基於功能的架構。

5無服務器（Serverless）計算貴嗎？

並不貴。只須要支付企業所使用的部分，沒有任何與無服務器計算相關的成本。特別對於小的用例，應用程序使用隨時間變化大的企業是很是划算的。

對於但願管理工做負載和操做的客戶來講，它也很是划算，由於它可使客戶避免成本，例如容量規劃或部署工具。許多AWS的客戶，如今正在嘗試用服務器來提升敏捷度，同時也節省了成本。健康零食公司Graze有許多使用for AWS的方法，包括將分析數據實時上傳至亞馬遜RedShift、管理備份和檢查GitHub拉請求，但願在將來幾個月內將其使用量增長兩到三倍。

6無服務器（Serverless）的行業炒做

無服務器計算獲得了開發人員的積極響應。在以資源有效的方式交付應用程序時，它提供了更多的選項和可能性。

不少大型的企業，好比Netflix，已經在探索無服務器計算，但願解放開發人員的時間。Netflix使用AWS Lambda來構建基於規則的自我管理基礎設施，並替換低效的流程，減小錯誤的速率，爲開發人員節省寶貴的時間。

之前，雲開發者必須使用那些耗費大量人力和時間的機器。無服務器技術容許開發人員在幾分鐘內運行測試和產品。開發人員直接控制部署時間以及如何部署，經過建模框架控制應用架構。還容許發佈本身的產品並親自體驗。

2

容器和無服務器（Serverless）

無服務器計算和容器之間正在醞釀一場戰鬥——當塵埃落定時，誰會倒下？會是容器嗎？

如前所述，無服務器具有一些明顯的優點。好比節省成本，提升IT支出的效率，減小資源和維護需求，容許開發人員和IT人員專一於高價值的任務等等。這也是爲何人們會對這項技術充滿熱情的緣由。可是，通往無服務器的路徑並不輕鬆。

SetfiveConsulting 的合夥人 Ashish Datta 說，將基於容器的架構遷移到無服務器一般須要從新架構系統的重要部分。

「與從虛擬機到容器的轉換相比，從容器到無服務器的轉換更有戲劇性，由於容器和無服務器之間的計算環境發生了根本性的變化。」

相反，從虛擬機到容器的遷移更爲直接，由於這實際上只是部署哲學的變化。

Stackery CEO Nate Taggart說，最大的障礙是企業沒法輕易地遷移到無服務器架構上。

「(無服務器應用程序)必須是爲無服務器基礎設施設計的。這對於新的開發來講多是至關經濟的，可是遷移遺留應用程序將是很繁重的，在某些狀況下甚至是不可能的。

今天的無服務器產品有資源的限制，Taggert解釋道，包括內存、計算和時間限制;有限的語言支持;以及在請求之間管理狀態的特殊考慮。全部這些都必須「從一開始就融入到應用程序設計中」，Taggert說。

PubNub的產品營銷總監James Riseman說，遷移到無服務器架構還須要對現有基礎設施進行重大的反思。

「無服務器計算須要一個很是現代的、組件化的架構。系統和應用程序必須被分解成離散的邏輯函數，而要保證這樣的質量企業會失去控制。」 JamesRiseman 表示。

無服務器的另外一個問題是訂價。「公司是按照每筆交易或每秒鐘計費，而不是按照傳統的基礎設施條款，」Siseman說。「這使得訂價更加難以預測。」

除了地址遷移需求以外，轉向無服務器計算還會致使思惟模式的改變。

「最大的障礙之一是，須要考慮在離散的單元中計算資源，而不是始終佔用進行計算。」這與對內存使用量和運行時等框架的限制相吻合，好比Amazon Lambda這樣的框架。「Atta說道。

1對手仍是盟友？

撇開正反兩方面的因素不說，在面對面的交鋒中，容器和無服務器是相互排斥的解決方案。可是每一個人都說這樣想是錯誤的。

SwymSystems CEO兼首席顧問Todd Millecam 表示，這是一種蘋果和橘子的比較。「二者都有使用，若是觀察大多數無服務器技術的運行方式，它們只是在後臺運行容器。」

無服務器和容器是互相補充而並不是重疊的角色。Taggart說，雖然二者均可以用於計算任務，但每一個任務都有其優缺點。無服務器是一種理想的、可預測的、具備小型資源需求和短時間事務的工做負載。

容器對於長時運行的流程和可預測的工做負載具備優點。容器在應用程序設計方面也提供了更多的靈活性，但須要對底層基礎架構進行更多的管理。

「做爲一個無服務器操做控制檯產品，咱們有一個幾乎徹底沒有服務器的後端，」Taggart補充說，可是仍然使用容器來處理某些工做負載，在這些工做負載中，它們是更好的工做工具

2 Serverless是將來嗎？

看來，關於容器式微的謠言被誇大了。

Datta說，不一樣的架構和應用程序老是須要不一樣程度的抽象，一樣，不一樣的團隊也會對作出不一樣的權衡。

正如容器沒有取代虛擬機，虛擬機也沒有取代裸金屬的服務器。抽象不會成爲「更接近金屬」的解決方案的生死存亡的威脅。

無服務器，應該被看做是技術的進化。大多數觀察者警告說，無服務器仍然不成熟，尚未創建架構模型和健壯的開發工具。這意味着將企業應用程序的命運與特定的雲供應商綁定，將帶來自身的風險。

所以，儘管它有巨大的潛力，但可能須要數年才能在企業中得到普遍的應用。

同時，無服務器將會對創業公司產生重大影響。

「無服務器計算提供了一種託管代碼的方法，並以很低廉的成本在web上可用。在擁有活躍的用戶基礎以前，無服務器是構建web應用程序的一種划算的方式。」Millecam說道。

不過，數字機構POP CTO Jake Bennett 表示，隨着無服務計算技術的成熟，架構師會發現無服務器將愈來愈難以抗拒。「無服務器計算解決了太多被忽視的問題。將對可伸縮性問題的關注轉移給第三方供應商，是每一個開發人員的夢想，讓別人關心服務器維護是IT運維人員的一種幻想。」

原文連接：

一、Everything you need to know about Serverless Computing

https://www.tuicool.com/artic...

二、Serverless and containers: Is a throw down under way?

https://www.tuicool.com/artic...