在過去的十年里，我們領略了云的靈活性和可管理性。云帶來了隨時能獲得新服務器的體驗。接下來應該獲得更高級的平臺服務：隊列、API網(wǎng)關、鑒別等。下一步是不是就要完全告別服務器了？
很多觀點將無服務器化（serverless）和現(xiàn)在的功能即服務( functions-as-a-service )產(chǎn)品聯(lián)系起來，這很令人失望，他們完全曲解了無服務器化。這個觀點很狹隘。
本文將會通過實例來揭示無服務器平臺如何在未來改變我們的觀點。我會把通用的無服務器化分為三個類，然后觀察這三類如何共同作用，提供比功能即服務產(chǎn)品更為寬廣的平臺功能。
定義無服務器化
硬件依然是那些，所以無服務器化是一種服務層抽象，一個給你帶來益處的感覺。如此，它有兩個明確的特點：配置虛擬機鏡像中不可見基礎設施，以及基于調(diào)用的計費方式而不是傳統(tǒng)的按時收費。
并非如你開始所認為那樣的模糊不清——云在一定程度上已經(jīng)是無服務器化。當使用諸如AWS S3或者Azure存儲等基礎服務時，你要按每GB付賬（使用磁盤的成本），按每次I/O操作付賬（數(shù)據(jù)訪問所需計算機資源的成本）和按次所傳輸?shù)淖止?jié)數(shù)付賬（網(wǎng)絡管道的成本）。服務器就在那里，其資源為成百上千的客戶所共享，只是你沒有察覺而已。
讓很多開發(fā)者不安的是無服務器運行自己代碼的理念-換言之，通用無服務器化計算。
我怎么知道自己的代碼如何運行？我如何調(diào)試并且監(jiān)視環(huán)境？我如何加固服務器？
這些都是本能的反應和疑問——這些重要的非功能觀點在我們開始探究一個良好的無服務器架構前都必須得到解決。現(xiàn)在開始討論我們的選擇。
事件驅動類
第一種具備廣泛用途的無服務器化計算機是功能即服務業(yè)務：AWS Lambda和Azure Functions。這兩種服務都為按需執(zhí)行的代碼提供運行環(huán)境。你不必開發(fā)很多應用，你只要寫應用片段和事件規(guī)則，這些規(guī)則在需要的時候觸發(fā)你的代碼。“當我在/foo 收到一個HTTP request時，運行X ”，“當隊列中有消息時開始Y”諸如此類。
功能可能很簡單：只是輸入一個或者幾個方法來完成一個簡單工作。
你不知道或者不關心服務器，你的代碼只是執(zhí)行而已。現(xiàn)在你處于功能園中，根據(jù)內(nèi)存和CPU的使用，按照零點幾秒的時間進行計費。無論一天中進行了一次’或者一百萬次調(diào)用，這沒關系-這種差別你是看不見的。
所以，現(xiàn)在無服務器化是明確的方向。但是功能集并不能單獨占據(jù)主導地位。為什么？
- 不是所有的任務都適合于基于事件的單操作觸發(fā)模型。
- 不是所有的代碼都能清晰地解耦，有些依賴需要大量的安裝和配置工作。
- FaaS 產(chǎn)品可能不支持你的開發(fā)語言的與/或范式。
- 將現(xiàn)有的應用轉換到功能即服務模型太過復雜以至于在經(jīng)濟上是不可接受的。
所有這些都是有效的架構層考量。
此外，還要大量的工具問題使得FaaS產(chǎn)品對于一些場景難以使用。我對這些卻并不擔心——所有這些產(chǎn)品都在以飛快的速度進行改進，如果現(xiàn)在工具問題阻礙了你，這些問題應該很快就會得到解決。問題是“什么時候”？
流程圖驅動類
如果你與功能集類無緣，因為你的工作流只是不適合事件驅動模型，這典型地觸及了兩個問題中的一個：或者是你的流程圖需要更為復雜的編排，或者你需要連續(xù)不斷的運行-或者是在大量時間內(nèi)連續(xù)運行，這兩個情況類似。
復雜的編排問題首先可以由諸如 Azure Logic Apps 和AWS Step Functions解決，允許你繪制長運行工作流的流程圖。工作流可以調(diào)用你自己的功能集代碼，允許在直接調(diào)度框架內(nèi)客戶功能的注入。
工作流編排產(chǎn)品使得很多復雜的事情變得容易。在一個購物反饋過程中插入24小時的延遲？只要增加一個延遲任務，然后你的應用會在一天后神奇的恢復。有人在twitter上提及你的產(chǎn)品時要有所回應？簡單的雙擊，你也不必考慮使用twitter API。這種開箱即用活動不但能減輕編排的痛苦，而且對于大多普通服務可以消除編寫客戶代碼的需要。
盡管工作流很適合業(yè)務過程建模，但是卻不是適用于所有無服務器工作負載的靈丹妙藥。例如，復雜的決策樹用于表示工作流仍顯得相當笨拙。原始的代碼依然保留其獨特的表達潛能。此外，工作流的單步計數(shù)計費模型造成頻繁的輪詢和昂貴的過細粒度的人力劃分。
功能集和工作流都不能解決帶有大量移動部件的連續(xù)運行任務的問題。這聽起來 似乎是相當有限的問題，但是有一個額外原因讓其成為大問題：過去幾十年中幾乎所有的應用，至少部分上是設計作為連續(xù)運行的任務。
因此，在我們的無服務器化百寶囊中還需要更多的工具。
容器驅動類
容器技術是幾年前隨著Docker的出現(xiàn)而降臨的，并且它的出現(xiàn)引起了不小的震動。容器定義了下一代的虛擬機。盡管最初提供的都是Linux空間，現(xiàn)在也有了對于Windows的支持，容器調(diào)度技術（Mesosphere， Kubernetes等）現(xiàn)在逐漸成為主流。
容器不只是用輕量化抽象代替了虛擬機。它也是一種通用的應用包裝機制。如果你的節(jié)點app需要一個特定的Nginx 配置，把它建立在你的容器中。如果你的ASP.NET Web 站點使用后臺的Windows 服務，你可以通過分層把它納入容器鏡像中。
“OK，Jouni，你明顯是把容器作為一個軟件包裝媒介，但是無服務器呢？容器在本質上只是運行在一臺容器主機上的打包的迷你服務器，本質上仍然是另外一臺服務器！實際上，它們幾乎是無服務器的死對頭！”
我很高興你這么問。我相信容器在轉化為無服務器平臺前需要解決兩個問題：無服務器主機和容器維護。
托管沒有服務器的容器
對于許多用戶來說，容器群集是一種有效主機平臺，相比于虛擬機，容器可以真正提升負載密度。
但是，為了轉向無服務器化，我們需要忘記等待工作的虛擬機。我們需要在詳細耗費度量上基于調(diào)用的計費。
第一個這樣做的主流產(chǎn)品是 2017年7月發(fā)布預覽的Azure Container Instances。ACL為我們提供了按需定制容器，而不必考慮運行在何種基礎設施之上。需要來個配備一個虛擬CPU和2G內(nèi)存的容器實例么？
az container create --name JouniDemo --image myregistry/nginx-based-demo：v2 --cpu 1 --memory 2 --registry
使用該容器的賬單如下：調(diào)用該容器 $0.0025，外加每秒每GB內(nèi)存 $0.0000125， 每個內(nèi)核 $0.0000125。 所以上述配置的容器使用10秒的花費是$0.002875。如果你每個月只使用一個小時，你的花費是 $2.07。
上述就是運行中的微賬單，事實上它會十分有效。你不必使用一臺虛擬機來處理你的批處理任務，如果你需要處理高突發(fā)能力，秒級或者更短延遲的無服務器容器就可以滿足需要，而不是啟動時間更長的虛擬機群集。
但是雖然現(xiàn)在有無服務器容器可供選擇，我們?nèi)匀灰媾R包含服務器容器的困境——也就是所謂的“如何獲得你修補過的base images”問題。
通過自動化進行容器維護
無服務器化的信條之一是開發(fā)者只需關注業(yè)務邏輯，而非其他細節(jié)。容器是一種奇妙的工具，但是按照定義，其與生俱來的還有維護其環(huán)境的技術負擔。
你通過創(chuàng)建一個OS base image來構造自己的應用，在其頂端對所需的服務進行分層，最后注入你的應用。當你發(fā)布一個新版本，你重建你的容器鏡像然后就可以工作了。情況是，一旦base image和依賴都組合到你的鏡像中，它們?nèi)绾胃拢拷鼇淼膚indows補丁和新的Linux 內(nèi)核安全補丁如何更新到你的應用中？
考慮這樣的問題和無服務器化的本質有點對立。日常的依賴維護不是無服務器化開發(fā)者要關注的，所以這些應該自動化。
但是日常維護和關鍵決策之間的界線是模糊的。例如，一個典型的web網(wǎng)站很樂意更新其操作系統(tǒng)，并不會在意其副作用。但是你如何劃分這界線？你的web服務器應該在你未察覺的情況下進行更新么？一個新Node.js版本呢？
這是一個微妙的問題，但是需要認真研究。對于這點，我推薦花費幾分鐘聽一聽在 .NET Rocks #1459上對微軟的 Steve Lasker的采訪，大約在37分鐘處。
這種想法可能性的深度和細節(jié)超越了本文的范圍，但是想象一下你處于這樣的未來：
- 你的容器配有自動化測試包，可以驗證你工作載荷的關鍵功能。
- 你身邊的平臺熟悉base OS image 更新語義（例如，Alpine Linux 14.1.5有一個關鍵的安全補丁）
- 這個平臺可以為你測試新的補丁。當一個base image 更新時，平臺可以嘗試在其上面重建應用鏡像，運行測試包然后主動報告測試結果。
- 你可能甚至通過基于策略的控制進行自動更新——“當一個關鍵操作系統(tǒng)更新時，只要測試未發(fā)現(xiàn)致命錯誤，就可以自動更新運行中的應用鏡像”
并且，包含服務器的容器看起來似乎更為serverless。容器能夠比簡單的代碼片段功能框架完成更為復雜的工作任務，并且通過減小運行階段所包含依賴的副作用，它們也更關注業(yè)務本身。
現(xiàn)在萬事具備？
題目的“即將完全轉向無服務器化”咒語，后面跟著一個何時實現(xiàn)的問題。現(xiàn)在答案已經(jīng)顯而易見，就是“現(xiàn)在！”這個平臺現(xiàn)在仍然還要很多問題要解決。
例如，在Azure Container Instances 上運行一個24X7容器任務，花費太昂貴；你就想使用一臺虛擬機了。實現(xiàn)虛擬機完全自動更新補丁則是另外一個挑戰(zhàn)。現(xiàn)在容器的維護自動化還沒有實現(xiàn)。FaaS的日志和監(jiān)控部分以及工作流產(chǎn)品對于AWS和Azure開發(fā)者來說，依然是持續(xù)的痛苦根源。對于Windows容器的支持呢？還處于開發(fā)階段。
但是工具一直以飛快的速度進行改進。基于功能的無服務器化和工作流產(chǎn)品在去年跨越了一大步。容器仍然處于準備過程中，容器中的所有部分都背負很高的期待。
此外，把工作任務劃分為更小的片段，微服務，在無服務器化的理念中根深蒂固。為了極大影響無服務器框架的編排能力，必須要精心安排。這是另外一個需要開發(fā)工作的領域。類似 Azure Event Grid的服務，提供了上述幾類元素以及平臺之間的連接機制：你可以輕易的將AWS Lambda 和 Azure Logic Apps粘合在一起。所有的這些都趨向一致：小的、基于反應的、聚焦業(yè)務的工作任務匯集到一起來解決一個大問題。
一旦這些都實現(xiàn)了，就可以將現(xiàn)有事件應用的很大一部分，遷移到具備更少服務器層級依賴的平臺上。對于新的原生云應用架構師來說，無服務器微服務平臺將會要求完全嶄新的設計思想。我期待接下來的12個月里能發(fā)生翻天覆地的變化。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://www.zudvwvb.cn/
本文標題：是時候完全轉向無服務器化了嗎？
本文網(wǎng)址：http://www.zudvwvb.cn/html/solutions/14019320848.html
相關文章
