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

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

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

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

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

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

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

　　它是如何工作的?

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

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

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

　　選擇一個Serverless平臺

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

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

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

　　2. 運行在共有和私有數據中心的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應用接口或/和現有Serverless框架增值服務的包裝框架：

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

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

　　設計Serverless功能的最佳實踐

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

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

　　· 通過優化功能來實現以毫秒為單位的執行效率。

　　· 堅持無狀態的協議，以能夠在功能上無縫地擴展。

　　· 使用外部的服務來實現服務的發現、狀態和緩存管理。

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

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

　　結論

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

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

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

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