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