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

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

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

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

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

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

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

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

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

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

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

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

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