對于開發(fā)者而言，基礎設施相關(guān)工作是個令人頭痛但又擺脫不了的包袱。然而，無服務器計算機制能夠減輕這一負擔。
首先必須承認，無服務器的說法并不確切——當然，服務器總要存在。所謂無服務器計算，只是立足于云基礎設施之上建立新的抽象層，從而保證開發(fā)者無需再為服務器乃至云中的各類虛擬資源分神。
為了明確相關(guān)定義，微服務負載管理廠商Iron.io公司CEO Chad Arimura為我們做出了解釋。Arimura表示，無服務器計算可被看作現(xiàn)代開發(fā)者不斷發(fā)展的一種參照系：
時至今日，規(guī)?；h(huán)境下的原子單位已經(jīng)由虛擬機轉(zhuǎn)向容器。如果更進一步進行思考，甚至可以將單一功能或者說單一用途代碼塊作為最小單位。更直白地講，相當于處理一張圖片、轉(zhuǎn)換一段數(shù)據(jù)以及編碼一段視頻。
對我來說，這就是微服務架構(gòu)的主旨所在。相較于構(gòu)建整體式應用，大家可以將單一應用拆分成多個擁有單一功能的服務。那么，微服務與功能之間的區(qū)別又在哪里?
每項服務都提供一個通用API，供人們對其進行訪問。我們并不了解其內(nèi)部到底如何運作。服務可能由功能作為支撐。因此，功能就成了更為基本的代碼塊，而服務則更像是開發(fā)者能夠進行交互的接口。
隨著開發(fā)者利用微服務組裝應用并面向功能進行服務調(diào)用，他們亦可從庫中選取功能以構(gòu)建服務本身——而無需在創(chuàng)建應用時考慮服務器基礎設施。
AWS Lambda無疑是目前最具知名度的無服務器計算實例。正如Amazon的一段教學視頻中所言，“一旦將代碼上傳至Lambda，該服務會處理基礎設施的 全部容量、規(guī)模伸縮、補丁安裝以及管理工作，從而為代碼運行提供必要環(huán)境。”AWS Lambda與Iron.io都提供功能庫，旨在進一步加快開發(fā)速度。
需要注意的是，這一切都立足于服務編排層級之上——這部分任務由Mesos、Kubernetes或者Docker Swarm負責提供。盡管Iron.io也提供自己的編排層，“但我們在開發(fā)者/API領域還屬于晚輩”Arimura指出。
事實上，Iron.io的核心功能與AWS Lambda基本相當，只是其能夠部署在全部主流公有及私有云平臺之上。Arimura認為Iron.io的最大優(yōu)勢在于能夠?qū)崿F(xiàn)內(nèi)部部署，畢竟目前大多 數(shù)企業(yè)仍然傾向于利用混合云機制實現(xiàn)云計算。這意味著同樣的無服務器計算環(huán)境能夠在不同公有及私有云之間保持一致性與應用可移植性。
Arimura甚至提到了頗具爭議的“無操作”機制，其最早由Netflix公司前任云架構(gòu)師Adrain Cockcroft提出。當然，由于服務器始終存在，所以運行于其上的操作也不可能真正消失。只不過從開發(fā)者的角度來看，他們已經(jīng)無需在創(chuàng)建軟件時考慮操作需求。
無服務器計算的主旨在于提升開發(fā)者效率，其不僅降低了基礎設施管理工作量，同時亦憑借服務與功能庫壓縮了開發(fā)者構(gòu)建應用時需要編寫的代碼總量。
企業(yè)開發(fā)團隊正在逐步接納敏捷、持續(xù)集成/交付以及DevOps等新鮮理念。但憑借著無服務器計算帶來的抽象層，現(xiàn)代開發(fā)方法將擁有更出色的實際效率以及更具吸引力的實施收益。
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。