Serverless 和 Functions

無服務器 (Serverless) and 函數(shù)(Functions) 已經(jīng)成了眾多行業(yè)會議中的熱門以及核心話題之一。為了滿足這一市場需求，供應商們也紛紛推出新產(chǎn)品。那么，這個市場究竟是什么?如何將函數(shù)應用于您的企業(yè)?以及如何開始運用函數(shù)?本文的目的就是幫助您確定自己在這個領域中的前進方向。

[[335414]]

我們先來看一些市場數(shù)據(jù)，這些數(shù)據(jù)體現(xiàn)了人們對無服務器技術的廣泛關注。

• RightScale 2018年云服務現(xiàn)狀報告顯示，無服務器計算是增長最快的一類云服務，增長率達75%。這份報告還指出81%的企業(yè)采用了多云策略。

• Digital Ocean的Currents 2018報告調(diào)查了開發(fā)人員使用無服務器計算的情況。33%的開發(fā)人員表示他們已經(jīng)在無服務器環(huán)境中部署了應用。然而有意思的是，半數(shù)受訪者表示對無服務器不太了解。

• 在Cloud Foundry Foundation的“PaaS、容器和無服務器技術在多平臺領域的地位”報告中，46%的受訪企業(yè)表示采用了無服務器計算。39%的受訪企業(yè)使用PaaS、容器和無服務器技術。

我們能從上面這些數(shù)據(jù)中得出什么結論呢?

1. 無服務器技術確實很熱門，但真正對它很了解的人很少。
2. 在企業(yè)實現(xiàn)軟件現(xiàn)代化的過程中，無服務器計算扮演著重要角色。
3. 大部分大型企業(yè)都在使用多云服務。

到目前為止，您所了解的無服務器應用大多屬于公有云中的使用場景---這是一種試用無服務器計算的好方法，幾乎沒有風險，可以嘗試一下!但你知道為什么無服務器計算在企業(yè)數(shù)據(jù)中心也很重要嗎?

沒錯，函數(shù)在防火墻背后起著重大作用。我們將介紹一些采用本地函數(shù)帶來潛在幫助的新場景。

在數(shù)據(jù)中心，使用函數(shù)非常方便，因為許多最重要的應用都在運行在數(shù)據(jù)中心。此外，由于數(shù)據(jù)引力的緣故，您最重要的數(shù)據(jù)也存儲在這里。如果您想通過函數(shù)改進這些應用，就需要一種在本地運行函數(shù)的方法。還有一個好處就是，您可以更智能地利用IaaS占用空間。

讓我們通過一些示例場景來說明為什么函數(shù)在數(shù)據(jù)中心如此有用。

我所在的行業(yè)如何在數(shù)據(jù)中心運用函數(shù)?

電信行業(yè)

我們都聽說過“按次付費”(PPV)電視，這是指有線服務提供商的用戶購買通過私人電視廣播觀看某個節(jié)目的權限。廣播公司同時向所有訂購節(jié)目的人播放該節(jié)目。觀眾可以按照屏幕上的指南，通過Web、IVR或現(xiàn)場客服代表購買觀看節(jié)目，通常是體育賽事、音樂會或電影的權限。

平時，幾乎沒有關于PPV節(jié)目的交易。但如果有大型賽事或拳擊比賽，PPV訂購系統(tǒng)上的負載就會激增。例如，2017年跨界世紀拳王梅威瑟與麥格雷戈跨界大戰(zhàn)就是有史以來的第二大PPV節(jié)目：按次購買觀看權限的交易額高達430萬美元，總收入超過6億美元!

過去，企業(yè)是如何應對這些“一次性事件”的呢?企業(yè)需要確保龐大的基礎架構全天候運行，即使是平常交易較少時也一樣。否則，運維團隊就需要在事件前一周倉促行動，加強基礎架構。他們需要為服務PPV訂購系統(tǒng)的應用程序增加更多的實例。這種不定時負載會帶來很大的資金開銷。

對于這種彈性場景，非常適合采用無服務器計算。假設PPV訂單是一個函數(shù)，平時可以縮減為0。這樣就能減少數(shù)據(jù)中心的運維開銷。當PPV訂單很少時，分配給PPV函數(shù)的群集可以用于其他工作負載。如果訂單數(shù)量大增，這個函數(shù)就會根據(jù)需要進行擴增，以應對來自不穩(wěn)定且不可預測的客戶數(shù)量的請求。

這類不時激增的流量模式無處不在，下面我們再來看看醫(yī)療保險行業(yè)。

保險行業(yè)

很多人每年都會收到來自醫(yī)療保險公司的投保電子郵件。這種模式與PPV場景類似。醫(yī)療保險公司的系統(tǒng)在投保期會十分繁忙，尤其是在工作時間。而在投保期之前和之后，系統(tǒng)的使用量很小。

銀行

這種偶發(fā)高峰的負載模式同樣適用于金融行業(yè)。我們再舉一個例子，比如企業(yè)首次公開募股(IPO)期間的機構投資。 新產(chǎn)品上市時，銀行就如同啟動了“IPO引擎”。在購買狂熱期，函數(shù)會進行擴增，而在其他時候，函數(shù)會縮減為0?；蛘呦胂牍善苯灰灼脚_，收盤后，交易函數(shù)會縮減為0。這時，其他后端/分析應用程序就可以開始使用基礎架構。

金融服務行業(yè)有相當多的批處理作業(yè)。這些批量作業(yè)也適合采用無服務器計算。

每家銀行都會運行處理夜間賬目核對的批處理作業(yè)。這些任務實際上只在夜間運行幾小時，但往往需要相當強的計算能力。因此，運行這些進程的硬件就無法得到充分利用。企業(yè)大多使用舊式調(diào)度系統(tǒng)來安排這些任務。

在這個場景中使用函數(shù)后，可以更智能地利用硬件，甚至可以免除傳統(tǒng)軟件許可證的成本。cron調(diào)度程序每晚可以調(diào)用該函數(shù)進行擴增，并啟動賬目核對進程。處理完成后，該函數(shù)將縮減為0。

這種計劃作業(yè)的模式在許多行業(yè)都很普遍。

物聯(lián)網(wǎng)

無服務器計算提供了一種非常有效的方法，讓您可以調(diào)用函數(shù)來應對各種事件，并通過循環(huán)鏈將函數(shù)連接在一起。那么這與物聯(lián)網(wǎng)(IoT)有什么關系呢?

IoT領域有著大量的事件驅(qū)動型使用場景。例如家庭自動化設備。您可以在這些設備上創(chuàng)建各種自定義規(guī)則。當運動傳感器感知到運動時，它可以觸發(fā)某個事件。該事件又可以調(diào)用一些函數(shù)：向用戶發(fā)送通知、開燈、向?qū)崟r監(jiān)控代理發(fā)送警報，甚至啟動警報器。所有這些函數(shù)都可以通過循環(huán)鏈連接到一個工作流中!

類似的還有制造工廠中的溫度傳感器。當機器達到溫度閾值時，系統(tǒng)就會觸發(fā)相應的事件，通過調(diào)用函數(shù)向廠務經(jīng)理發(fā)送警報，并進一步調(diào)用其他函數(shù)來禁用受影響的機器。

最后，我們來了解一下Pivotal在函數(shù)領域所做的工作。

使用riff構建函數(shù)

Pivotal正在開展riff項目，并與Google合作推出了開源項目Knative。riff和Knative共同構成了即將推出的Pivotal Function Service (PFS)的基礎。

PFS適用于任何云的無服務器編程。Pivotal希望為您提供一個適用于任何云、本地和公有云環(huán)境的函數(shù)抽象。PFS是一種多語言服務，支持在您所選的框架中編寫函數(shù)。它通過向您的架構添加函數(shù)來節(jié)省時間。使用PFS處理各種操作，包括Web事件、基于事件的集成和大規(guī)模流數(shù)據(jù)。

將FaaS 的未來寄希望于Knative

一些riff組件遷移到了Knative，另外一些組件保持獨立。

本文引用了一些市場統(tǒng)計數(shù)據(jù)，這些數(shù)據(jù)顯示您的同行計劃在未來幾年更多地使用無服務器計算。我們還列舉了一些使用場景來說明函數(shù)為何如此有用。最后，我們向您展示了在生產(chǎn)中使用riff、Knative和PKS運行代碼是多么簡單。

教程：如何在數(shù)據(jù)中心內(nèi)運行函數(shù)

要使用riff和Knative構建函數(shù)，我們需要一種絕對可靠的Kubernetes便利服務。最適合的就是我們的Kubernetes產(chǎn)品Pivotal Container Service (PKS)。我們?yōu)槠脚_運維人員和群集管理員展示了如何在PKS上創(chuàng)建具有正確Knative規(guī)范的群集。

• 安裝PKS
• 創(chuàng)建Kubernetes群集
• 訪問群集
• 確認kubectl上下文指向新創(chuàng)建的群集
• kubectl config current-context
• 為vSphere上的群集創(chuàng)建存儲類規(guī)范
• 安裝riff CLI
• riff version
• brew install watch
• 在單獨的終端中監(jiān)控單元
• watch -n 1 kubectl get pod --all-namespaces
• 安裝Knative和無服務器riff系統(tǒng)
• riff system install --node-port

部署函數(shù)需要做四件事：

• 從GitHub存儲庫中提取函數(shù)的源代碼
• 根據(jù)java函數(shù)調(diào)用器構建容器鏡像
• 將生成的鏡像推送到dockerhub存儲庫
• 安排容器并通過Knative ingress-gateway提供函數(shù)

關于作者

Mayuresh是Pivotal的高級平臺架構師，擁有超過13年的工作經(jīng)驗，為電信、生命科學、制造和金融服務領域的企業(yè)構建和設計高度可擴展、恢復能力強的分布式系統(tǒng)。他在集成領域從事過大量與高性能消息傳遞、緩存、流處理和API相關的工作。工作之余，他喜歡玩Xbox游戲，和女兒一起在鄉(xiāng)間小路上騎自行車，或者烹制辛辣美食。