數人云|使微服務、容器趨向完美——Serverless架構你應當知道的二三事

無服務架構（Serverless）和DevOps、SRE、微服務、容器等同樣，是最近兩年比較新興的概念，數人云以前給你們分享過《Serverless用這5大優點，挽救了後來7億用戶的Instagram》，今天再來探討下Serverless和容器與微服務之間的互補與碰撞。

近年來不少人在討論雲計算時都會提到容器，由於其幾乎完美得解決了DevOps所面臨的挑戰。

本文將闡述Serverless的解決方案，它與傳統和容器化的應用的不一樣之處。

一個典型的N層Web應用是由前端、公開的Web服務器組成；後端：高度隔離的數據層以及中間件層。

微服務

先來講說微服務，在微服務的模式下，能夠無需使用服務器去呈現全部的用戶界面，例如，處理全部的業務對象和邏輯，只需一個應用便可建立多個應用編程接口或API。

這是以酒店爲應用場景的一種基於微服務的現代WEB和移動應用的方法。

假設經營了一家連鎖酒店，須要面向公衆的服務，容許用戶登陸到網站預約房間，經過第三方郵件列表進行郵件促銷，以及提供WEB和移動應用頁面的通常方式。

能夠建立處理用戶數據請求的API，這裏用白色顯示，與其擁有傳統的服務器呈現的用戶界面，還能夠建立單個頁面WEB應用和使用該API的移動應用，以獲取所需的信息去適應該平臺的方式提供信息。

這使得做者的工做量去除了整個開發鏈：設計人員和前端開發人員可讓界面看起來更漂亮，而且可以高效得執行，然後端團隊只須要專一於建立一個單一的方法去爲他們提供相同的信息。

只須要將代碼和其依賴項打包到一個容器中，而後便可在任何地方運行——由於它們一般很小，能夠將大量的容器裝到一臺機器上——TechCrunch。

容器

從業務的角度講，能有什麼緣由不喜歡容器呢？答案是，沒有。

容器之因此偉大，是由於它們可讓咱們打包全部的東西——操做系統、代碼、服務、以及應用須要工做的全部東西而且運行它們。這不只顯著得簡化了DevOps模式，節約了大量的人工和時間的成本，並且它還爲咱們提供瞭如何部署解決方案的選項，其中許多如今都是免費的特定供應商。

另外，正如TechCrunch所指出的，能夠在一臺主機上運行幾個容器，這意味着浪費的資源要少的多，反過來又浪費了成本。

因此能夠用容器來提供這些微服務，也就是說，用戶接口API能夠在容器A中運行，而在容器B中預約API，以及在容器C中的電子郵件通信API，容器D中的身份驗證API。

容器使得上面所提到的具備高度可移植性，若是構建的得當，高度可伸縮，甚至能夠很好得適應Bug。

DevOps和容器

從DevOps的角度去看，仍舊是沒有理由不喜歡容器技術。其具備的優點有：

1. 可快速地進行部署。
2. 在一些基本配置中，能夠安裝所需的應用和服務，配置環境以及支持應用，並未整個流程編寫腳本。
3. 技術團隊無需花費一成天的時間去建立新的環境：腳本一次就完成了。
4. 運維的成本下降。

若是應用被適當得設計成可伸縮的需求，那麼使用容器的擴展就像啓動應用鏡像的另外一個實例同樣簡單，甚至能夠自動化這個過程，應用能夠響應時需求和規模來知足需求。

更爲重要的是，能夠自動化構建和部署過程，容器在自動化的構建過程和應用生命週期管理中很是有用。

能夠輕鬆得使用容器簡化版本和構建過程，全部的這些都很容易經過開源或低成本工具以及過程進行編排。

容器的不足之處

容器也有一些不足之處，由於容器化仍然是一項新技術，因此會有不少變化。不用擔憂Docker或Mesosphere會很快消失，但它們可能會發生重大的變化，對於在部署管道中管理容器鏡像的最佳實踐，尚未達成共識。

根據其特性，容器須要在客戶機器上具備更高的權限，若成功利用這一點，就會讓它們更加危險，例如：一臺虛擬機在客戶服務器上被破壞。

也很容易獲得比須要的容器更多的容器以及曾經執行一些工做負載的孤立容器：它們已經失效，但沒有被清理掉。

有一些研究代表，在全部基於雲計算的虛擬機中，有四分之一到三分之一都是殭屍的，而容器也遇到了一樣的問題，由於容器能夠快速且垂手可得的建立，而且在很大程度上是爲了處理一次性的工做負載而設計，因此這方面是存在着很大的隱患。

大多數容器都須要外部程序集——即「助手」應用，使用它們的主要應用可以運行，當容器從鏡像中建立時，很難確保這些程序集所在的存儲庫是聯機的，而且能夠遇到容器對這些程序集的依賴可能會被破壞的狀況。

最後，使用某些容器技術（如Docker）進行安全高效得網絡鏈接，須要熟練的人手。

Serverless

Serverless在此基礎上應用而生，能夠消除幾乎全部的問題和以及傳統基礎設施和容器上存在的大部分問題。

須要明確的一點是，無服務架構（Serverless）並不意味着沒有任何服務器去運行代碼。

Serverless是無需管理服務器，只須要關注代碼，而提供者將處理其他的部分。

像全部的流行技術同樣，Serverless有一些變化的定義，這取決於說的是誰，但在供應商的角度，核心概念是相同的：

• Serverless計算提供了以通用的匿名操做系統，代碼將會在其中運行，下文將進行詳解。
• 這些實例由雲提供應用徹底管理，會作全部的補丁、調優、服務安裝等等。只須要編寫運行在此服務上的代碼，而云提供應用將確保代碼在該環境中運行。
• 每一個匿名且通用的環境只在須要時提供，當再也不須要代碼時，該環境就會被減小。
• 最後，只須要爲代碼實際使用付費：代碼被執行的次數以及所需的計算資源的數量。

微服務和Serverless

但若是全部這些相對簡單的任務或微服務將它們組成一個解決方案繼續進行交付，就若是它們是整個服務器應用同樣，又有什麼意義呢？

固然，容器在怎麼建立和管理基於服務器的解決方案上面給予了很大的靈活性，不過它仍然像管理整個工做流同樣管理架構。

這就是Serverless技術的切入點。

Serverless是一種新的工做流方法，用擬人的描述方式是它說：會有一些事件調用個人代碼，當事件發生時，我可能會從某個東西中獲取輸入並可能建立一些輸出，這就是我須要關心的。

正因如此，Serverless的應用能夠快速擴展到需求，而由於它的設計高度可用，下面以一個例子去深刻探討這個問題：

在HTTP端點上偵聽服務器函數的典型工做流

這裏有一個典型的例子，說明了Serverless的函數是如何工做的，在Serverless的技術中，按需進行的代碼被稱爲服務的功能，它們被稱爲「服務」，由於每一個按需執行的執行都服務於特定的目的或功能。

在本例中，建立了一個處理Web請求的函數，首先，當介入到入站請求時，雲提供程序將查看是否有可用的函數實例正在運行，若不是，它就建立一個，但若是是這樣，它就將這個請求交給可用的函數。

而後，函數代碼解析WEB請求，以某種方式處理它，並返回對請求客戶機的響應。

一般，雲提供程序將會讓該實例運行幾分鐘，以加速處理下一個請求，從而消除生成另外一個實例的須要，但在大約5分鐘後，弱沒有第二個請求，雲提供商就會取消這個實例。

人人爲我，我爲人人

以前提到，在匿名且通用的操做實例上承載了服務器的功能。

這是它們工做的關鍵，雲提供程序對基本操做系統（如Linux或Windows）進行定製，其環境和服務設置與特定的編程語言（如node JS、Java、Python或Dot net core）協同工做。

雲提供程序能夠很是快得建立實例，由於它們徹底相同，沒有什麼特別之處，每一個工做與其餘實例徹底相同。

當部署代碼時，會被保存到雲提供商的存儲服務中。

當代碼須要運行時，提供者檢索代碼、啓動其中的一個實例，將代碼放到它上面，而後執行該代碼，正如前面所指出的，一旦代碼執行完畢，提供者一般會讓實例運行一點，以處理後續的請求，但一旦需求降低，就會取消該實例。

服務器成本低於大多數訂價模型，包括容器，照片經過Joshua_Willson在Pixabay公共領域。

訂價模型

這種方法致使了一個不一樣於虛擬機或容器的訂價模型。

在VMs的狀況下，一般根據VM的CPU內核和內存的容量來支付每小時的費用，也會常常把應用許可費捆綁在一塊兒，須要支付存儲數據和數據系統磁盤的費用。

一樣的狀況也適用於容器訂價：須要爲承載容器的VM付費。不一樣之處在於，在VM上的傳統代碼可能會留下許多未使用的資源，能夠將多個容器打包到一個VM上，以相同的價格處理多個工做負載。

在Serverless功能的狀況下，須要爲代碼運行的次數和每一個執行使用的計算資源數量付費。這就爲咱們帶來了很大的回報。

簡而言之，下降實際的基礎設施成本，大大簡化了部署管道以及整體成本，這只是當前成本的一小部分。

來看看函數與虛擬機的直接託管成本。

每個月執行50萬次的費用，4GB/S

在這裏，將承擔一個包括每個月50萬次執行的工做量，每秒鐘大約有兩個請求，要完成這項工做，每秒鐘大約須要4GB的內存。

所以，對於虛擬機，須要至少提供8GB的內存，在Azure中，最便宜的選擇是D3V2 VM，若是運行Linux，每個月的運行成本約爲100美圓和4美圓，對於AWS來講，最便宜的EC2實際是T2，大的，每個月約70美圓。

但若是使用的是服務器功能，那麼能夠大幅下降成本，在Azure功能的狀況下，能夠將實際的基礎設施成本削減到大約四分之一，使用Lambda，能夠將成本與EC2的比例減半。

每個月執行200萬次執行，每次執行4 GB/ s。

若是將執行的次數增長到200萬，就能獲得更好的存儲，VM成本顯著增長，以知足32GB的內存須要。

服務器成本也在增長，減小了在VM上實現的百分比節省，但實際的節省會更好。

在Azure的狀況下，經過使用函數，每個月能夠節省近100美圓，在AWS的狀況下，每月能夠節省150美圓。

每月處理2萬次執行的費用，每次執行的費用爲512 MB/ s。

若是工做負載更小的話，那麼節省下來也會很明顯，讓咱們將假設改成每月2萬次請求，或者每兩分鐘一次請求，每秒鐘能夠處理1G的RAM。

在這種狀況下，可使用一個Azure標準的A1 V2 VM，每個月大約32美圓，或一個T2小的EC2實例，每個月大約17美圓。

長尾訂價

你可能會問本身：「AWS和Azure怎麼能讓這個服務免費？」

一樣，它又回到了一個事實，即Serverless的實例都是同樣的，因爲底層圖像是徹底相同的，雲提供程序能夠輕鬆得提供它們，並且每一個實例實際上變得比之前一個更便宜，因此在遊戲中有巨大的規模。

就像Facebook同樣，每一個新用戶幾乎不用花費任何東西來創造，事實上，僅僅經過建立帳戶來實現盈利，一樣的，最終也就是Serverless的實例。

每一個工做負載幾乎不須要部署，所以給您大量的免費計算時間和實例是有理可圖的，由於即便是少數用戶超過了免費的服務閾值，也只有週期性得得到了豐厚的回報。

而Serverless技術的用戶幾乎老是須要額外的服務：數據庫做爲服務，消息隊列，內存緩存，API網關等等，這至關於贈送剃鬚刀手柄，並加價出售刀片。

這是一個長尾的效應，但利潤拋物線很是陡峭，獲得了不少只有執行和計算時間，由於它只須要稍微超過這些限制，雲提供商就能實現利潤。

所以當使用Serverles時，會獲得顯著的成本節省。

不管大小，在服務器上運行相同數量的工做比虛擬機上花費更少。

更好的是，沒有服務器，也沒有殭屍。

由於服務提供者會自動處理供應和自動設備，並且只須要支付代碼運行的次數以及它在運行時所使用的計算資源的數量，就不會爲正在使用電力的服務器實例付費。

Serverless並不意味着NoOps，但它確實意味着是更精簡的DevOps團隊。

Serverless的Ops

這裏有Serverless的實際好處：若是沒有服務器能夠管理，那麼構建和部署解決方案的工做就更少了嗎？

答案是，是的，做爲技術經理所須要領導的時間將會大大減小，每一個員工的工做時間也會被壓縮到生產當中。

什麼叫NoOps？這是一個時髦的詞，因此每一個人的定義各有不一樣，但大部分的人都會贊成如下觀點：NoOps的核心是可使用自動化、服務抽象和供應商提供的服務來減小或消除傳統上須要在DevOps中執行的任務。

例如，今天可能有一個敏捷過程，在此之中，工做被分配給Sprint，每一個星期、兩週或任什麼時候候，團隊實現其變動，而後構建和測試，若是測試完畢便可部署。

這涉及到測試工程師的工做，構建工程師，系統工程師、開發團隊等等，都會產生一些焦慮，尤爲是在構建失敗的時候。

在NoOps中，發展的速度要快得多，使用持續集成和持續部署，自動化構建和測試用於確保每一個特性或修復不被破壞解決方案，若是有，將快速調整更改，重複這個自動構建和測試過程，直到特性或修復工做，而後就能夠當即被推到登臺和生產。

這種快速的節奏之因此有效，是由於構建（經過微服務）是有意分發的。

經過處理應用和幾個小任務的組合，能夠安全得處理每個小任務，而不須要對給定的微服務任何變化都有很大的擔憂，下降了宕機時間。

另外因爲函數是自動配置和分配以知足需求的，所以基於它們的應用每每會快速擴展並具備很高的可用性。

也就是說，無需監控微服務看它的在線或知足需求高峯，若是雲提供商的底層服務器服務正常運行，即會處理需求峯值和出問題的實例。

所以，根據定義，除非雲提供商正在歷經服務中斷，不然在一個不須要任何服務的應用中，就不能有宕機時間，即便這樣也能夠經過將徹底相同的代碼庫部署到不一樣的區域，並使用基於DNS的路由來確保故障轉移保護。

Serverless的好處

所以回顧一下Serverless功能的好處：

• 實際基礎設施成本較低。
• 經過微服務架構進行工做，這是有意將業務邏輯關注點彼此分離的，這使您的應用開過過程更加簡單，由於i額能夠將解決方案的功能做爲獨立單元進行管理。
• 由於無需管理服務器，因此只須要關注代碼，減小每一個代碼更改的人員和時間。
• 而事實上，這容許咱們採用一個很是快速的開發過程，專一於自動化、抽象和持續交付以及持續集成。
• 並且因爲雲提供程序在實例被供應和分配時處理，有效的將高可用性和災難恢復構建在基於服務器的解決方案中。
• 誠然，底層服務可能會遇到問題，但可使用傳統的基於雲的業務連續性技術來管理這種狀況。

若每一個人都能專一於編程

事實上，Serverless是一個跳板，它自己就是一個讓每一個人都能成爲程序員的通道，由於一旦完成了配置和部署服務器這種神祕的工做，就能夠專一於代碼自己的自動化。

微服務體系結構自己就是將幾個小任務連接到一個工做流中的過程，能夠將這些任務以新的方式結合起來，以新的投入爲基礎，爲問題創造全新的解決方案。

咱們已經達到了一個目標：使用人工智能和智能設備，好比Sire以及Google搜索、Alexa去理解相對非結構化的請求並生成有意義的響應，爲何這些相同類型的服務不能用於建立代碼？或者至少是智能工做流呢？

爲何那些有創造力的人不能創造出新的和重要的解決方案，他們可以本身創造這些工做流程，利用現代計算的力量呢？

這些是值得去思考的問題。

微軟的三種現代解決方案特色：「智能邊緣」設備的遙測技術在「智能中心」中獲得鞏固和解釋，使用人工智能，在中心和邊緣進行Serverless的技術處理計算。

上面所說很大程度上借用了Satya Nadella在微軟（Microsoft Build）的主題演講。

Satya Nadella對計算機的將來提出了一個設想，包括兩個領域：「智能邊緣」和「智能雲」。

智能EDGE是咱們全部連接到互聯網網的設備，並且一般也自身也足夠強大，擁有獨立思考的屬性，不只是咱們的電腦，智能手機，平板電腦等，還包括電視、電器、汽車、醫療監視器、玩具，甚至是使用的工具。

從全部這些設備的輸入中，有一個統一的平臺去進行管理——智能雲。

當每一個設備都在咱們的生活中實踐時，雲利用人工智能和大數據推導出真知灼見以及行動，而後反饋到每一個設備上，指導它們如何行動，而且告訴它們這是爲何，以便於它們進行學習。

在微軟的願景當中，這種雲處理是在Serverless的平臺上進行的，這種平臺是無限可伸縮的。

Serverless的欠缺處

和上面提到的容器的欠缺之處同樣，Serverless自己也是擁有不足的，接下來就來談談它不能作什麼，以及爲何虛擬機容器不會很快消失。

顯然將大規模的應用集羣改成微服務架構並不是小事。

前期的成本很高，可能會有夥伴關係或其餘業務和要求，好比數據隱私和主權，這限制或阻止簡單得放棄一直在構建應用的方式。

即便有很好的基本的N層架構，從使用容器中獲得得益處可能遠遠超過將應用從新構建爲可移植單元的好處。

並且並非每一個工做負載都適用於微服務，若是你的任務不須要擴展——若是它有一個可預測的工做負載——那麼就有一個強有力的理由反對使用微服務。

若是解決方案嚴重依賴於其餘服務，或者須要對運行時環境進行高度專門化的控制，那麼這一點尤爲正確，不要試圖繞過服務器運行時環境的限制，或補償大量外部請求和響應；只需將解決方案構建爲一個包，並將其部署到容器中。

或者，若是應用須要大量的計算資源來完成它的工做，固然，可能會在託管方面節省一些錢，可是不斷供應的VM或容器的可靠性可能會超過服務器功能所固有的代碼限制。

這是一個討論Serverless解決方案侷限性的好辦法。

一個明顯的問題是，由於實例只在須要時才提供，因此在不多使用Serverless代碼的狀況下，可能會有一些延遲處理，能夠經過運行探測來修復這個代碼，使得代碼保持溫暖，但這是一種黑客才使用的行爲，也許最好只是簡單得將不常常訪問的代碼放到一個老是熱的容器當中去，特別是在調用代碼時，性能是很是重要的。

此外，還須要準備好解決延遲和刪除微服務之間的連接的解決方案，例如，若是有一個做爲全部解決方案的微服務運行身份驗證API，那麼在它的通訊中，即便是400微秒的延遲也會被放大成一個嚴重的、系統性的錯誤。

雖然容器仍是一個比較新興的技術，可是Serverless比它更要新，Azure的功能在通常狀況下還不到一年，Google的Serverless解決方案仍處於測試階段，IBM建立Serverless標準的努力也扔處於初級階段。

這就引出了另一個問題：不管採起什麼Serverless的方法，它在這個時候會有點拘泥於一個供應商，幾乎能夠在任何地方運行一個容器，但如何得到服務器代碼的運行將多少取決於雲提供商所支持的語言，以及它們用於建立Serverless實例和支持服務的方法。

代碼能夠運行到雲提供商所支持的運行時和版本上，這是頗有限的，所以很難引入某些庫或程序集，這會讓編程更加複雜。

最後，Serverless的編程模型——一個觸發接收輸入並建立一些輸出的事件——可能不是某個需求的正確解決方案。

總結

Serverless是雲計算的下一個浪潮，它節約了巨大的時間和成本，並且總投入甚至少於容器，只須要按需付費，沒有更多的殭屍服務佔用總體利潤。

雲供應商也經過供給本質上相同的服務器給每一個須要它們的人獲取顯著的利益，同時也保證了低成本和高性能。

因爲是自動化的，Serverless的通用方面，高可用和災難恢復是內置的，在區域性服務中斷的狀況下，您可使用傳統的基於雲的業務連續性技術來保持運行。

整個微服務概念創建在快速部署、持續集成、持續交付和分離關注的基礎上，使Serverless成爲改進服務交付和快速適應的理想方法。

但Serverless並非每一個工做負載都適用的，最好在容器中創建一個解決方案。

原文地址：http://www.tuicool.com/articl...原文做者：Doug Vanderweide