【摘要】通過迅速靈活以及容量巨大的彈性伸縮，無服務器架構能很好地解決關鍵功能的性能瓶頸，但它並不是完美的：不僅需要修改設計去適應它，對熟悉的編程模型進行調整，還要解決諸如規劃預算、安全等等問題。但總的來說，它為雲上的應用提供了另一種選擇——並且具有難以抵擋的誘惑：極大地簡化應用從開發到部署和維護的整個過程。
將編寫代碼和部署應用的整個過程簡化是每個開發人員的夢想，而無服務器架構（Serverless）正是這樣的解決方案，在採用這種架構的時候需要考慮它的侷限，費用問題以及安全問題。
信息技術在不同領域的發展不盡相同。誠然，事實一直如此，因為人們為當下的問題所找到的可行的解決方案，通常先於這些問題本身就已經存在了。與虛擬化、雲計算等技術的緩慢進步相比，編程語言幾乎是原地踏步了十年。直到新一輪的編程語言和方法諸如Python，Ruby，Node，Swift的出現才打破這一局面。這兩個領域看似毫無關聯，然而我們即將看到二者共同演變並結合在一起開花結果。
這個新的結合領域就是無服務器計算（Serverless）。易於部署的容器實例集合、無處不在的基於REST API的外部服務、易於實現REST API的新編程語言使得以 REST API提供接口成為一種簡單而可行的選擇。這些技術相互結合，創造了一種全新的計算形式。 我們已經很熟悉這種新的編程形式的諸多方面（例如如何設計和實現REST API，如何設計實現微服務），但是仍有一些方面並不為人熟知。
從Node.js中學到的
我第一個Node.js程序與大多數人的並沒有太大不同——設置好監聽端口和路徑，寫好代碼處理相應的執行和退出邏輯，然後使用瀏覽器訪問對應的URI。在實現基本功能之後，我很自然地進一步利用Node的併發執行和其他新優點來改善這個應用。
但這個應用提供的並不是REST API，它只是簡單地根據不同的請求內容響應包含不同內容的HTML頁面。結合REST之後，Node應用便成為一個計算結點。不變的是，當收到請求時，它便執行邏輯，然後退出。同時，作為基礎設施的部分，它會保持對特定端口的監聽。
基礎設施
然而，為了實現一個簡單但完整、可運行的Node應用（或者 Python / Djang / Java / Spring / RoR 等），還需要進行網絡配置，防火牆配置，操作系統配置和調整，存儲配置，並且如果你使用了網絡應用防火牆（WAF: Web Application Firewall），還需要配置WAF。儘管，DevOps能使所有這一切更容易一些，但請試想一下，如果你根本不需要做這些額外的配置，那將會怎樣？
無服務器架構
針對這個問題，越來越多的公司不斷地提出解決之道。他們思考的是能否可以做到由開發人員編寫代碼，部署應用，並在需要時就能輕易獲取這些應用，而在不需要它們時也不需要做任何額外的工作，而且還能按需擴展？ 甚至能否做到像WAF這樣的配置也被自動化，並且應用的訪問權限被限定在指定的人/機器的正確子集？ 如果部署應用真的如同上傳zip文件一樣簡單，或者就像在編輯器中編寫代碼並點擊“部署”一樣簡單，那將會怎樣？ 最後，如果預先配置了數據庫和存儲的訪問權限，那麼又該如何將這些配置包含進來呢？
這對開發者無疑有著巨大的吸引力。編寫代碼後，無需進行那些看似必須的配置（無論是物理環境，虛擬環境的還是雲端環境）就能部署，是眾多開發者的夢想。這也不禁讓人想起一些現實世界中的例子。首當其衝的就是應對高峰期的性能瓶頸。假設你有一個完美運行的在線訂單系統，在銷售高峰期（比如黑色星期五），由於驗證收貨地址的時間過長，系統經常陷入崩潰。
如果你有一個無服務器函數（serverless function），它僅返回輸入的地址是否有效，你就可以將地址驗證交給它來處理，那該多好？ 甚至，該功能還允許快速擴展到幾乎無限容量（當然，網絡帶寬還是要考慮的）！ 現在，這個瓶頸不再是問題，你只需要為這個函數實際使用的計算資源（CPU時間）付費。 這意味著調用得越多，支付的費用就越高，但是在大部分的時間裡，費用都很少。 你只需要為真實使用的計算資源付費。
如果所有這一切以可接受的價格讓你在你的站點上或者雲端完成，那該有多好！已經誕生了這樣的產品（Microsoft Functions，AWS Lambda和nanoscale.io等）都提供了上述所有功能。
並非雨後彩虹
無服務器計算也並不是完美的。在選擇供應商時，需要注意的事項包括：
工具支持。
它必須支持你的開發工具，特別是對CI / CD / ARA的支持至關重要。如果無法將無服務器計算集成到你現有的開發環境和以及整個流程中，那麼說明它還不夠好。
計費和收費方式。
永遠不要忘記這些服務提供商與你的商業一樣，目標也是賺錢。請確保你明白他們賺到的錢是從你的預算中支出的。所有按需使用的資源都有一些附加因素，因為它依賴於不可預測的客戶群和他們變幻莫測的使用情況。但要了解你將被收取哪些費用，以及供應商保留了哪些更換計費方式的權利。
安全功能。
將大量代碼從你的核心應用中分離出來，並將其放在雲端，這可能需要在安全上大量投資並需要撰寫一些額外的代碼。確保你的供應商能夠提供上述協助，抑或是允許你將你的代碼保留在防火牆和WAF之後。
你的整體架構。
雖然我們上面的例子很好地演示了“低垂的果實”（唾手可得的部分），但稍微複雜一些的案例就可能會遇到諸如數據訪問，數據安全，成本問題乃至高可用性等問題。確保你的團隊已經深入研究了怎樣實現無服務器計算架構，並能很好地掌握這種編程模型。
構建正確的應用
將來，一些應用程序將完全採用無服務器架構，特別是對於相比使用雲端實例更具成本優勢的應用。即便沒有這樣的應用，儘可能少地在基礎設施上配置資源也會變得更加划算。同時，將無服務器計算作為解決各種相對獨立的功能引起的性能瓶頸的解決方案，或者用於測試在不需要增加基礎設施預算的情況下，是否可以增加應用的容量。總的來說，在信息技術領域，對於如何正確地選擇架構來實現業務目標，無服務器架構無疑是其中一種解決之道。