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

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

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

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

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

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

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

　　它是如何工作的?

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

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

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

　　選擇一個(gè)Serverless平臺(tái)

　　Serverless平臺(tái)一般分為如下三類：

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

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

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

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

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

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

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

　　設(shè)計(jì)Serverless功能的最佳實(shí)踐

　　我們?cè)谠O(shè)計(jì)Serverless功能時(shí)，應(yīng)考慮如下的設(shè)計(jì)原則：

　　· 在定義功能的范圍時(shí)應(yīng)遵循單一責(zé)任的原則。

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

　　· 堅(jiān)持無狀態(tài)的協(xié)議，以能夠在功能上無縫地?cái)U(kuò)展。

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

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

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

　　結(jié)論

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

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

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

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】