對(duì)于開發(fā)者而言，基礎(chǔ)設(shè)施相關(guān)工作是個(gè)令人頭痛但又?jǐn)[脫不了的包袱。然而，無服務(wù)器計(jì)算機(jī)制能夠減輕這一負(fù)擔(dān)。

首先必須承認(rèn)，無服務(wù)器的說法并不確切——當(dāng)然，服務(wù)器總要存在。所謂無服務(wù)器計(jì)算，只是立足于云基礎(chǔ)設(shè)施之上建立新的抽象層，從而保證開發(fā)者無需再為服務(wù)器乃至云中的各類虛擬資源分神。

為了明確相關(guān)定義，微服務(wù)負(fù)載管理廠商Iron.io公司CEO Chad Arimura為我們做出了解釋。Arimura表示，無服務(wù)器計(jì)算可被看作現(xiàn)代開發(fā)者不斷發(fā)展的一種參照系：

時(shí)至今日，規(guī)模化環(huán)境下的原子單位已經(jīng)由虛擬機(jī)轉(zhuǎn)向容器。如果更進(jìn)一步進(jìn)行思考，甚至可以將單一功能或者說單一用途代碼塊作為最小單位。更直白地講，相當(dāng)于處理一張圖片、轉(zhuǎn)換一段數(shù)據(jù)以及編碼一段視頻。

對(duì)我來說，這就是微服務(wù)架構(gòu)的主旨所在。相較于構(gòu)建整體式應(yīng)用，大家可以將單一應(yīng)用拆分成多個(gè)擁有單一功能的服務(wù)。那么，微服務(wù)與功能之間的區(qū)別又在哪里？

每項(xiàng)服務(wù)都提供一個(gè)通用API，供人們對(duì)其進(jìn)行訪問。我們并不了解其內(nèi)部到底如何運(yùn)作。服務(wù)可能由功能作為支撐。因此，功能就成了更為基本的代碼塊，而服務(wù)則更像是開發(fā)者能夠進(jìn)行交互的接口。

隨著開發(fā)者利用微服務(wù)組裝應(yīng)用并面向功能進(jìn)行服務(wù)調(diào)用，他們亦可從庫(kù)中選取功能以構(gòu)建服務(wù)本身——而無需在創(chuàng)建應(yīng)用時(shí)考慮服務(wù)器基礎(chǔ)設(shè)施。

AWS Lambda無疑是目前最具知名度的無服務(wù)器計(jì)算實(shí)例。正如Amazon的一段教學(xué)視頻中所言，“一旦將代碼上傳至Lambda，該服務(wù)會(huì)處理基礎(chǔ)設(shè)施的全部容量、規(guī)模伸縮、補(bǔ)丁安裝以及管理工作，從而為代碼運(yùn)行提供必要環(huán)境。”AWS Lambda與Iron.io都提供功能庫(kù)，旨在進(jìn)一步加快開發(fā)速度。

需要注意的是，這一切都立足于服務(wù)編排層級(jí)之上——這部分任務(wù)由Mesos、Kubernetes或者Docker Swarm負(fù)責(zé)提供。盡管Iron.io也提供自己的編排層，“但我們?cè)陂_發(fā)者/API領(lǐng)域還屬于晚輩”Arimura指出。

事實(shí)上，Iron.io的核心功能與AWS Lambda基本相當(dāng)，只是其能夠部署在全部主流公有及私有云平臺(tái)之上。Arimura認(rèn)為Iron.io的最大優(yōu)勢(shì)在于能夠?qū)崿F(xiàn)內(nèi)部部署，畢竟目前大多數(shù)企業(yè)仍然傾向于利用混合云機(jī)制實(shí)現(xiàn)云計(jì)算。這意味著同樣的無服務(wù)器計(jì)算環(huán)境能夠在不同公有及私有云之間保持一致性與應(yīng)用可移植性。

Arimura甚至提到了頗具爭(zhēng)議的“無操作”機(jī)制，其最早由Netflix公司前任云架構(gòu)師Adrain Cockcroft提出。當(dāng)然，由于服務(wù)器始終存在，所以運(yùn)行于其上的操作也不可能真正消失。只不過從開發(fā)者的角度來看，他們已經(jīng)無需在創(chuàng)建軟件時(shí)考慮操作需求。

無服務(wù)器計(jì)算的主旨在于提升開發(fā)者效率，其不僅降低了基礎(chǔ)設(shè)施管理工作量，同時(shí)亦憑借服務(wù)與功能庫(kù)壓縮了開發(fā)者構(gòu)建應(yīng)用時(shí)需要編寫的代碼總量。

企業(yè)開發(fā)團(tuán)隊(duì)正在逐步接納敏捷、持續(xù)集成/交付以及DevOps等新鮮理念。但憑借著無服務(wù)器計(jì)算帶來的抽象層，現(xiàn)代開發(fā)方法將擁有更出色的實(shí)際效率以及更具吸引力的實(shí)施收益。