Serverless 不意味著沒有服務器，而是從應用可以在一個抽象層上忽略它的存在，而只關注在功能實現上和自身的請求處理上;每一個功能實現在不是單純的業務邏輯處理的代碼，相反每個功能調用具有了 Server 的特質，進化成為了一個具有自省、自知和自治的工作負載單元;他們更像是能夠衍生出其它新功能單元的生物體。這樣整個 Serverless 應用架構之內，每個生命可以衍生下去，子子孫孫無窮匱也。
處在這技術日新月異的時代里，新的技術浪潮經常對當前的技術產生著威脅和顛覆。在編寫應用的時候我們目前經常談論到“Serverless”技術。它的核心思想是把應用作為一系列的功能/function來部署，這些功能在需要的時候被按需部署。服務器管理應該是不需要去操心的事情，所有功能被按需調用，被運行在群集之上。
但是 Serverless 里不意味著沒有 Docker，事實上 ”Docker 就是 Serverless”。你可以用 Docker 來容器化這些功能，然后按需地運行在 Swarm 群集上。Serverless 是一種構建分布式計算的應用的方法，而 Docker 是完美的構建和運行他們的平臺。
從 Server 到 Serverless
那么我們如何來編寫 Serverless 的應用?讓我們先看下這個例子：“一個有5個子服務組成的投票應用”：
它的結構如下：
1. 兩個 Web 前端
2. 一個后臺的處理投票的 Worker 服務
3. 一個處理投票的消息隊列
4. 一個數據庫
那個后臺處理投票的進程是非常容易成為轉換為 Serverless 架構的目標。在投票應用內，我們可以運行一點類似于下面的代碼，來執行后臺任務：
Worker 和消息隊列能用按需在 Swarm 上運行的容器來替換，并自動地按需擴容。
我們甚至可以消除掉 Web 前端。我們可以這么做：用 Docker 容器來相應每一個HTTP 請求，每個 HTTP 請求都用一個自生長的跑著輕量 HTTP 服務器的容器來處理。之前使用的是長時間持續運行的 HTTP 服務器，現在變成了具有 HTTP 相應和處理能力的按需跑起來的容器，而且他們能自動地擴容來支持所有訪問請求。
我們新的架構大概如下圖所示：
其中紅色的方塊是需持續長期運行的服務，而綠色方塊成了按需被調用的 Docker容器。這樣這個應用變成了只有少數幾個需要被管理的 long-running 服務，在相應請求的時候使用原生的 Swarm 擴容能力，處理能力的上限是 Swarm 群集的上限。
具體如何實現
這里有三個有用的技巧，可以在你的程序中使用：
1. 把你代碼中的 function 作為按需拉起的 Docker 容器
2. 使用 Swarm 在群集上運行這些容器
3. 從容器里面運行這些功能容器，繞過了一個 Docker API socket
使用以上技術的組合，程序執行負載發生的可能性將和您如何架構你的應用相關。運行后臺任務就是一個非常適合的例子，但是整個應用中的其它工作負載也是有可能的，例如：
1.考慮到延遲，用啟動一個容器來服務所有用戶的 HTTP 請求可能是不現實的。可是你可以寫一個內置的負載均衡邏輯，讓它知道何時需要主動地自動擴容 Web 前端自身，通過在 Swarm 群集上運行更多 web 處理容器。
2.一個 MongoDB 容器可以在 Swarm 上成為一個具有自省能力的架構，它能自動地運行出正確數量的 shard 和 replica 容器。
接下來
我們已經得到了這些激進的新工具，用做構建應用的抽象層，我們隱約看到了如何深入下去的可能性。我們依然像長時間以來在一堆服務器上構建應用一樣，而以后可以來利用 Swarm 能按需地在基礎架構里的任何地方執行功能代碼的能力。
希望這些能夠給您一些如何構建應用的新思路，但是我們還需要你們的幫助。我們已經有的是一些構建 Serverless 應用的基礎功能，然而他們依然不是很完備，我們需要更好的工具、庫、樣例程序，文檔等等。
京公網安備 11010502049343號