【51CTO.com快譯】Serverless架構的風格挑戰(zhàn)了軟件設計的現(xiàn)狀，并且實現(xiàn)了最優(yōu)開發(fā)、操作和管理開銷的部署基礎。隨著它繼承了來自微服務架構(Microservices Architecture，MSA)的基本概念，它已經(jīng)被賦予了相當前衛(wèi)的模式，以達到了最低級別的硬件空置架構。

　　盡管它帶來了顯著的進展，但是采用它則需要一個深思熟慮的過程，從而將企業(yè)對于解決方案的需求映射到Serverless計算之上。

　　最初的軟件系統(tǒng)的實現(xiàn)是部署在物理服務器上的，因為在給定的時間內操作系統(tǒng)只能有一個實例在運行，因此底層硬件的計算能力是無法被最優(yōu)地利用到的。隨著技術的發(fā)展，在分時功能的計算資源被確立之后，通過同時在多個虛擬機之間進行切換CPU和I/O的操作，它們得以運行在相同的硬件之上。

　　這種科技性的發(fā)展引領了許多行業(yè)的創(chuàng)新，而也對于云技術的起步是非常重要的。此時的虛擬機孤立于軟件部署的計算環(huán)境，是一些最為可控的、可伸縮的、和可編程的單元。2006年前后，當Google結合Linux內核的特性實現(xiàn)了控制組的時候，Linux容器技術也就隨即出現(xiàn)了。

　　從那以后，Linux容器其實都一直止步不前，因為，只有像Google這樣大規(guī)模的且技術卓越的企業(yè)才能夠成規(guī)模使用它。到了2012年，微服務架構的概念被一組軟件架構師介紹到了歐洲。而在2013年的晚些時候，Docker眨眼之間填補了容器生態(tài)系統(tǒng)中的可訪問性、可用性、以及支持服務的空缺。因此，容器也就開始變得流行起來了。

　　Linux容器打開了新視野，它將大型整體的系統(tǒng)分解為單個的、自包含的服務，并能以細粒度的資源利用率來執(zhí)行之。伴隨著這些進步的推進，像Kubernetes(Google開源的Docker容器集群管理系統(tǒng))和Mesosphere這樣的容器集群管理系統(tǒng)，開始提供端到端容器即服務(Container as a Service，CaaS)的功能，并同時進入了上升周期。

　　到了2015年的晚些時候，AWS通過引入AWS Lambda又向前跨了一大步。它可以通過按需運行微服務，并在無負載時停止之，從而進一步節(jié)省了軟件部署的成本。這個概念類似于節(jié)能汽車上的啟停功能，通過自動關閉內燃發(fā)動機以減少燃料的消耗。

　　它是如何工作的?

　　盡管“Serverless”一詞乍一看來看有些荒謬，但是它的實際意義是：在沒有任何基礎設施干預下的軟件部署的能力。Serverless平臺自動化了整個過程中的建立、部署和按需啟動服務。用戶只需注冊各種所需要的業(yè)務功能和其資源的需求。

　　很明顯，這樣的功能可以被分為兩種主要類型：由客戶請求所觸發(fā)的功能和那些需要在后臺執(zhí)行的時間或事件所觸發(fā)的功能。一般來說，這樣的Serverless系統(tǒng)可以使用一個容器集群管理器(container cluster manager，CCM)來實現(xiàn)，它具有一個動態(tài)的能按需延展容器的路由器。然而，這也將需要考慮到路由器的延遲性、容器的創(chuàng)建時間、語言的支持、協(xié)議的支持、函數(shù)的接口、函數(shù)的初始化時間、配置參數(shù)的傳遞、以及提供證明文件等方面。

　　盡管這種部署風格需要在沒有負載的時候容器能夠被停止，但在現(xiàn)實環(huán)境中，在服務請求之后這么快速地終止容器是需要高昂代價的。因為在較短時間的間隔內很可能會有更多的請求的產(chǎn)生，所以更為通常出現(xiàn)的情況是：Serverless計算容器會在預配置好的一段時間內被保存，以便被更多請求服務所重用到。這類似于PaaS平臺的自動擴展行為。一旦服務被擴展，它的一些實例將會被保留一段時間，以便處理更多的請求，而非立即終止它們。

　　選擇一個Serverless平臺

　　Serverless平臺一般分為如下三類：

　　1. 公有云上的功能即服務(Functions as a Service，F(xiàn)aaS)解決方案：

　　A. AWS Lambda、B. Microsoft Azure Functions、C. Google Cloud Functions、D. Webtask、E. Syncano

　　2. 運行在共有和私有數(shù)據(jù)中心的severless框架：

　　A. Fission - 運行在Kubernetes上、B. Funktion -運行在Kubernetes上、C. Kubeless -運行在Kubernetes上、D. Galactic Fog Gestalt – 運行在DC/OS上、E. IBM OpenWhisk – 運行在Docker上、F. IronFunctions – 運行在Docker，Docker Swarm， Kubernetes上

　　3.提供agnostic應用接口或/和現(xiàn)有Serverless框架增值服務的包裝框架：

　　A. Serverless.com – 支持AWS Lambda， IBM OpenWhisk、B. Apex – 支持AWS Lambda

　　如果你要決定選擇哪一個Serverless平臺的話，首先取決于數(shù)據(jù)中心將要運行何種方案。其次是它的特殊性、成熟度，以及對供應商的依賴程度，這也可能是需要被評估的方面。除了公共FaaS所能提供的，AWS Lambda和Azure也能夠提供完全成熟的Serverless產(chǎn)品。Google的云服務功能仍處于alpha階段，且只能通過邀請來獲取。Fission和Funktion這兩個對Kubernetes的Serverless框架的適用比較流行。由Iron.io所開發(fā)的IronFunctions是一種獨立于Serverless框架的相對新的平臺。IBM的OpenWhisk平臺已經(jīng)捐贈給了Apache軟件基金會，現(xiàn)處于孵化階段。另外，上述第三個類型也提供了實現(xiàn)多重云的Serverless部署選項，也是現(xiàn)有的公共FaaS的一種增值提供。

　　設計Serverless功能的最佳實踐

　　我們在設計Serverless功能時，應考慮如下的設計原則：

　　· 在定義功能的范圍時應遵循單一責任的原則。

　　· 通過優(yōu)化功能來實現(xiàn)以毫秒為單位的執(zhí)行效率。

　　· 堅持無狀態(tài)的協(xié)議，以能夠在功能上無縫地擴展。

　　· 使用外部的服務來實現(xiàn)服務的發(fā)現(xiàn)、狀態(tài)和緩存管理。

　　· 使用環(huán)境變量來讀取配置而非不依賴于文件。

　　· 鑒于容器被設計為是短暫的，我們應該避免使用文件系統(tǒng)去保持數(shù)據(jù)的持久性。

　　結論

　　Serverless架構的技術和設計模式還處在起步階段。當前，只要沒有對可支持的編程模型在實現(xiàn)該功能上的限制，各種新的應用程序和現(xiàn)有系統(tǒng)的擴展都可以毫不費力地遷移到該架構之上。同時，由于各種RPC協(xié)議，例如WebSocket、協(xié)議緩沖區(qū)、AMQP、MQTT、Apache Thrift都需要一個一直處于激活狀態(tài)的偵聽器，因此為信息接收通道選擇無狀態(tài)協(xié)議也是非常重要的。而且，實現(xiàn)協(xié)調邏輯的業(yè)務需求，為業(yè)務流程實現(xiàn)功能分組，管理分布式的事務、狀態(tài)等方面都可能需要第三方服務和工具。使用容器池的Serverless平臺，因為對于容器的重用方式的不同，也可能會帶來一些安全漏洞。它們也可能會不允許根據(jù)功能來進行資源配置。所以，在考慮為生產(chǎn)系統(tǒng)采用Serverless架構的時候，理解所有這些方面都是相當重要的。不過，鑒于許多框架已經(jīng)被建立和完善，這仍然可能是對于搭建一個POC(云平臺)和為即將上馬的項目評估其優(yōu)勢的大好時機。

　　【原標題】Adapting Serverless Architecture (作者: Imesh Gunaratne)

　　原文鏈接：https://dzone.com/articles/adapting-Serverless-architecture
 

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】