無服務(wù)架構(gòu)（Serverless）和DevOps、SRE、微服務(wù)犬耻、容器等一樣踩晶，是最近兩年比較新興的概念，數(shù)人云之前給大家分享過《Serverless用這5大優(yōu)勢(shì)枕磁，挽救了后來7億用戶的Instagram》渡蜻，今天再來探討下Serverless和容器與微服務(wù)之間的互補(bǔ)與碰撞。

近年來很多人在討論云計(jì)算時(shí)都會(huì)提到容器计济，因?yàn)槠鋷缀跬昝赖媒鉀Q了DevOps所面臨的挑戰(zhàn)茸苇。

本文將闡述Serverless的解決方案，它與傳統(tǒng)和容器化的應(yīng)用的不同之處峭咒。

Markdown

一個(gè)典型的N層Web應(yīng)用是由前端税弃、公開的Web服務(wù)器組成；后端：高度隔離的數(shù)據(jù)層以及中間件層凑队。

微服務(wù)

先來說說微服務(wù)则果，在微服務(wù)的模式下，可以無需使用服務(wù)器去呈現(xiàn)所有的用戶界面漩氨，例如西壮，處理所有的業(yè)務(wù)對(duì)象和邏輯，只需一個(gè)應(yīng)用即可創(chuàng)建多個(gè)應(yīng)用編程接口或API叫惊。

Markdown

這是以酒店為應(yīng)用場(chǎng)景的一種基于微服務(wù)的現(xiàn)代WEB和移動(dòng)應(yīng)用的方法款青。

假設(shè)經(jīng)營(yíng)了一家連鎖酒店，需要面向公眾的服務(wù)霍狰，允許用戶登錄到網(wǎng)站預(yù)定房間抡草，通過第三方郵件列表進(jìn)行郵件促銷，以及提供WEB和移動(dòng)應(yīng)用頁(yè)面的一般方式蔗坯。

可以創(chuàng)建處理用戶數(shù)據(jù)請(qǐng)求的API康震，這里用白色顯示，與其擁有傳統(tǒng)的服務(wù)器呈現(xiàn)的用戶界面宾濒，還可以創(chuàng)建單個(gè)頁(yè)面WEB應(yīng)用和使用該API的移動(dòng)應(yīng)用腿短，以獲取所需的信息去適應(yīng)該平臺(tái)的方式提供信息。

這使得作者的工作量去除了整個(gè)開發(fā)鏈：設(shè)計(jì)人員和前端開發(fā)人員可以讓界面看起來更漂亮绘梦，并且能夠高效得執(zhí)行橘忱，而后端團(tuán)隊(duì)只需要專注于創(chuàng)建一個(gè)單一的方法去為他們提供相同的信息。

Markdown

只需要將代碼和其依賴項(xiàng)打包到一個(gè)容器中卸奉，然后即可在任何地方運(yùn)行——因?yàn)樗鼈兺ǔ：苄《鄢希梢詫⒋罅康娜萜餮b到一臺(tái)機(jī)器上——TechCrunch。

容器

從業(yè)務(wù)的角度講榄棵，能有什么原因不喜歡容器呢敲长？答案是郎嫁，沒有。

容器之所以偉大祈噪，是因?yàn)樗鼈兛梢宰屛覀兇虬械臇|西——操作系統(tǒng)、代碼尚辑、服務(wù)辑鲤、以及應(yīng)用需要工作的所有東西并且運(yùn)行它們。這不僅顯著得簡(jiǎn)化了DevOps模式杠茬，節(jié)約了大量的人工和時(shí)間的成本月褥，而且它還為我們提供了如何部署解決方案的選項(xiàng)，其中許多現(xiàn)在都是免費(fèi)的特定供應(yīng)商瓢喉。

另外宁赤，正如TechCrunch所指出的，可以在一臺(tái)主機(jī)上運(yùn)行幾個(gè)容器栓票，這意味著浪費(fèi)的資源要少的多决左，反過來又浪費(fèi)了成本。

所以可以用容器來提供這些微服務(wù)走贪，也就是說佛猛，用戶接口API可以在容器A中運(yùn)行，而在容器B中預(yù)定API坠狡，以及在容器C中的電子郵件通訊API继找，容器D中的身份驗(yàn)證API。

容器使得上面所提到的具有高度可移植性逃沿，如果構(gòu)建的得當(dāng)婴渡，高度可伸縮，甚至可以很好得適應(yīng)Bug凯亮。

DevOps和容器

從DevOps的角度去看边臼，仍舊是沒有理由不喜歡容器技術(shù)。其具有的優(yōu)勢(shì)有：

1. 可快速地進(jìn)行部署触幼。
2. 在一些基本配置中硼瓣，可以安裝所需的應(yīng)用和服務(wù)，配置環(huán)境以及支持應(yīng)用置谦，并未整個(gè)流程編寫腳本堂鲤。
3. 技術(shù)團(tuán)隊(duì)無需花費(fèi)一整天的時(shí)間去創(chuàng)建新的環(huán)境：腳本一次就完成了。
4. 運(yùn)維的成本降低媒峡。

如果應(yīng)用被適當(dāng)?shù)迷O(shè)計(jì)成可伸縮的需求瘟栖，那么使用容器的擴(kuò)展就像啟動(dòng)應(yīng)用鏡像的另一個(gè)實(shí)例一樣簡(jiǎn)單，甚至可以自動(dòng)化這個(gè)過程谅阿，應(yīng)用可以響應(yīng)時(shí)需求和規(guī)模來滿足需求半哟。

更為重要的是酬滤，可以自動(dòng)化構(gòu)建和部署過程，容器在自動(dòng)化的構(gòu)建過程和應(yīng)用生命周期管理中非常有用寓涨。

可以輕松得使用容器簡(jiǎn)化版本和構(gòu)建過程盯串，所有的這些都很容易通過開源或低成本工具以及過程進(jìn)行編排。

容器的不足之處

容器也有一些不足之處戒良，因?yàn)槿萜骰匀皇且豁?xiàng)新技術(shù)体捏，所以會(huì)有很多變化。不用擔(dān)心Docker或Mesosphere會(huì)很快消失糯崎，但它們可能會(huì)發(fā)生重大的變化几缭，對(duì)于在部署管道中管理容器鏡像的最佳實(shí)踐，還沒有達(dá)成共識(shí)沃呢。

根據(jù)其特性年栓，容器需要在客戶機(jī)器上具有更高的權(quán)限，若成功利用這一點(diǎn)薄霜，就會(huì)讓它們更加危險(xiǎn)某抓，例如：一臺(tái)虛擬機(jī)在客戶服務(wù)器上被破壞。

也很容易得到比需要的容器更多的容器以及曾經(jīng)執(zhí)行一些工作負(fù)載的孤立容器：它們已經(jīng)失效黄锤，但沒有被清理掉搪缨。

有一些研究表明，在所有基于云計(jì)算的虛擬機(jī)中鸵熟，有四分之一到三分之一都是僵尸的副编，而容器也遇到了同樣的問題，因?yàn)槿萜骺梢钥焖偾逸p而易舉的創(chuàng)建流强，并且在很大程度上是為了處理一次性的工作負(fù)載而設(shè)計(jì)痹届，所以這方面是存在著很大的隱患。

大多數(shù)容器都需要外部程序集——即“助手”應(yīng)用打月，使用它們的主要應(yīng)用能夠運(yùn)行队腐，當(dāng)容器從鏡像中創(chuàng)建時(shí)，很難確保這些程序集所在的存儲(chǔ)庫(kù)是聯(lián)機(jī)的奏篙，并且可以遇到容器對(duì)這些程序集的依賴可能會(huì)被破壞的情況柴淘。

最后，使用某些容器技術(shù)（如Docker）進(jìn)行安全高效得網(wǎng)絡(luò)連接秘通，需要熟練的人手为严。

Serverless

Serverless在此基礎(chǔ)上應(yīng)用而生，可以消除幾乎所有的問題和以及傳統(tǒng)基礎(chǔ)設(shè)施和容器上存在的大部分問題肺稀。

需要明確的一點(diǎn)是第股，無服務(wù)架構(gòu)（Serverless）并不意味著沒有任何服務(wù)器去運(yùn)行代碼。

Serverless是無需管理服務(wù)器话原，只需要關(guān)注代碼夕吻，而提供者將處理其余的部分诲锹。

像所有的流行技術(shù)一樣，Serverless有一些變化的定義涉馅，這取決于說的是誰归园，但在供應(yīng)商的角度，核心概念是相同的：

• Serverless計(jì)算提供了以通用的匿名操作系統(tǒng)稚矿，代碼將會(huì)在其中運(yùn)行蔓倍，下文將進(jìn)行詳解。
• 這些實(shí)例由云提供應(yīng)用完全管理盐捷，會(huì)做所有的補(bǔ)丁、調(diào)優(yōu)默勾、服務(wù)安裝等等碉渡。只需要編寫運(yùn)行在此服務(wù)上的代碼，而云提供應(yīng)用將確保代碼在該環(huán)境中運(yùn)行母剥。
• 每個(gè)匿名且通用的環(huán)境只在需要時(shí)提供滞诺，當(dāng)不再需要代碼時(shí)，該環(huán)境就會(huì)被減少环疼。
• 最后习霹，只需要為代碼實(shí)際使用付費(fèi)：代碼被執(zhí)行的次數(shù)以及所需的計(jì)算資源的數(shù)量。

微服務(wù)和Serverless

但如果所有這些相對(duì)簡(jiǎn)單的任務(wù)或微服務(wù)將它們組成一個(gè)解決方案繼續(xù)進(jìn)行交付炫隶，就如果它們是整個(gè)服務(wù)器應(yīng)用一樣淋叶，又有什么意義呢？

當(dāng)然伪阶，容器在怎么創(chuàng)建和管理基于服務(wù)器的解決方案上面給予了很大的靈活性煞檩，不過它仍然像管理整個(gè)工作流一樣管理架構(gòu)。

這就是Serverless技術(shù)的切入點(diǎn)栅贴。

Serverless是一種新的工作流方法斟湃，用擬人的描述方式是它說：會(huì)有一些事件調(diào)用我的代碼，當(dāng)事件發(fā)生時(shí)檐薯，我可能會(huì)從某個(gè)東西中獲取輸入并可能創(chuàng)建一些輸出凝赛，這就是我需要關(guān)心的。

正因如此坛缕，Serverless的應(yīng)用可以快速擴(kuò)展到需求墓猎，而因?yàn)樗脑O(shè)計(jì)高度可用，下面以一個(gè)例子去深入探討這個(gè)問題：

Markdown

在HTTP端點(diǎn)上偵聽服務(wù)器函數(shù)的典型工作流

這里有一個(gè)典型的例子祷膳，說明了Serverless的函數(shù)是如何工作的陶衅，在Serverless的技術(shù)中，按需進(jìn)行的代碼被稱為服務(wù)的功能直晨，它們被稱為“服務(wù)”搀军，因?yàn)槊總€(gè)按需執(zhí)行的執(zhí)行都服務(wù)于特定的目的或功能膨俐。

在本例中，創(chuàng)建了一個(gè)處理Web請(qǐng)求的函數(shù)罩句，首先焚刺，當(dāng)介入到入站請(qǐng)求時(shí)，云提供程序?qū)⒉榭词欠裼锌捎玫暮瘮?shù)實(shí)例正在運(yùn)行门烂，若不是乳愉，它就創(chuàng)建一個(gè)，但如果是這樣屯远，它就將這個(gè)請(qǐng)求交給可用的函數(shù)蔓姚。

然后，函數(shù)代碼解析WEB請(qǐng)求慨丐，以某種方式處理它坡脐，并返回對(duì)請(qǐng)求客戶機(jī)的響應(yīng)。

通常房揭，云提供程序?qū)?huì)讓該實(shí)例運(yùn)行幾分鐘备闲，以加速處理下一個(gè)請(qǐng)求，從而消除生成另一個(gè)實(shí)例的需要捅暴，但在大約5分鐘后恬砂，弱沒有第二個(gè)請(qǐng)求，云提供商就會(huì)取消這個(gè)實(shí)例蓬痒。

人人為我泻骤，我為人人

之前提到，在匿名且通用的操作實(shí)例上承載了服務(wù)器的功能乳幸。

這是它們工作的關(guān)鍵瞪讼，云提供程序?qū)静僮飨到y(tǒng)（如Linux或Windows）進(jìn)行定制，其環(huán)境和服務(wù)設(shè)置與特定的編程語言（如node JS粹断、Java符欠、Python或Dot net core）協(xié)同工作。

云提供程序可以非称柯瘢快得創(chuàng)建實(shí)例希柿，因?yàn)樗鼈兺耆嗤瑳]有什么特別之處养筒，每個(gè)工作與其他實(shí)例完全相同曾撤。

當(dāng)部署代碼時(shí)，會(huì)被保存到云提供商的存儲(chǔ)服務(wù)中晕粪。

當(dāng)代碼需要運(yùn)行時(shí)挤悉，提供者檢索代碼、啟動(dòng)其中的一個(gè)實(shí)例巫湘，將代碼放到它上面装悲，然后執(zhí)行該代碼昏鹃，正如前面所指出的，一旦代碼執(zhí)行完畢诀诊，提供者通常會(huì)讓實(shí)例運(yùn)行一點(diǎn)洞渤，以處理后續(xù)的請(qǐng)求，但一旦需求下降属瓣，就會(huì)取消該實(shí)例载迄。

Markdown

服務(wù)器成本低于大多數(shù)定價(jià)模型，包括容器抡蛙，照片通過Joshua_Willson在Pixabay公共領(lǐng)域护昧。

定價(jià)模型

這種方法導(dǎo)致了一個(gè)不同于虛擬機(jī)或容器的定價(jià)模型。

在VMs的情況下粗截，通常根據(jù)VM的CPU內(nèi)核和內(nèi)存的容量來支付每小時(shí)的費(fèi)用捏卓，也會(huì)經(jīng)常把應(yīng)用許可費(fèi)捆綁在一起，需要支付存儲(chǔ)數(shù)據(jù)和數(shù)據(jù)系統(tǒng)磁盤的費(fèi)用慈格。

同樣的情況也適用于容器定價(jià)：需要為承載容器的VM付費(fèi)。不同之處在于遥金，在VM上的傳統(tǒng)代碼可能會(huì)留下許多未使用的資源浴捆，可以將多個(gè)容器打包到一個(gè)VM上，以相同的價(jià)格處理多個(gè)工作負(fù)載稿械。

在Serverless功能的情況下选泻，需要為代碼運(yùn)行的次數(shù)和每個(gè)執(zhí)行使用的計(jì)算資源數(shù)量付費(fèi)。這就為我們帶來了很大的回報(bào)美莫。

簡(jiǎn)而言之页眯，降低實(shí)際的基礎(chǔ)設(shè)施成本，大大簡(jiǎn)化了部署管道以及總體成本厢呵，這只是當(dāng)前成本的一小部分窝撵。

來看看函數(shù)與虛擬機(jī)的直接托管成本。

Markdown

每月執(zhí)行50萬次的費(fèi)用襟铭，4GB/S

在這里碌奉，將承擔(dān)一個(gè)包括每月50萬次執(zhí)行的工作量，每秒鐘大約有兩個(gè)請(qǐng)求寒砖，要完成這項(xiàng)工作赐劣，每秒鐘大約需要4GB的內(nèi)存。

因此哩都，對(duì)于虛擬機(jī)魁兼，需要至少提供8GB的內(nèi)存，在Azure中漠嵌，最便宜的選擇是D3V2 VM咐汞，如果運(yùn)行Linux盖呼，每月的運(yùn)行成本約為100美元和4美元，對(duì)于AWS來說碉考，最便宜的EC2實(shí)際是T2塌计，大的，每月約70美元侯谁。

但如果使用的是服務(wù)器功能锌仅，那么可以大幅降低成本，在Azure功能的情況下墙贱，可以將實(shí)際的基礎(chǔ)設(shè)施成本削減到大約四分之一热芹，使用Lambda，可以將成本與EC2的比例減半惨撇。

Markdown

每月執(zhí)行200萬次執(zhí)行伊脓，每次執(zhí)行4 GB/ s。

如果將執(zhí)行的次數(shù)增加到200萬魁衙，就能得到更好的存儲(chǔ)报腔，VM成本顯著增加，以滿足32GB的內(nèi)存需要剖淀。

服務(wù)器成本也在增加纯蛾，減少了在VM上實(shí)現(xiàn)的百分比節(jié)省，但實(shí)際的節(jié)省會(huì)更好纵隔。

在Azure的情況下翻诉，通過使用函數(shù)，每月可以節(jié)省近100美元捌刮，在AWS的情況下碰煌，每個(gè)月可以節(jié)省150美元。

Markdown

每個(gè)月處理2萬次執(zhí)行的費(fèi)用绅作，每次執(zhí)行的費(fèi)用為512 MB/ s芦圾。

如果工作負(fù)載更小的話，那么節(jié)省下來也會(huì)很明顯俄认，讓我們將假設(shè)改為每個(gè)月2萬次請(qǐng)求堕扶，或者每?jī)煞昼娨淮握?qǐng)求，每秒鐘可以處理1G的RAM梭依。

在這種情況下稍算，可以使用一個(gè)Azure標(biāo)準(zhǔn)的A1 V2 VM，每月大約32美元役拴，或一個(gè)T2小的EC2實(shí)例糊探，每月大約17美元。

長(zhǎng)尾定價(jià)

你可能會(huì)問自己：“AWS和Azure怎么能讓這個(gè)服務(wù)免費(fèi)？”

同樣科平，它又回到了一個(gè)事實(shí)褥紫，即Serverless的實(shí)例都是一樣的，由于底層圖像是完全相同的瞪慧，云提供程序可以輕松得提供它們髓考，而且每個(gè)實(shí)例實(shí)際上變得比以前一個(gè)更便宜，所以在游戲中有巨大的規(guī)模弃酌。

就像Facebook一樣氨菇，每個(gè)新用戶幾乎不用花費(fèi)任何東西來創(chuàng)造，事實(shí)上妓湘，僅僅通過創(chuàng)建賬戶來實(shí)現(xiàn)盈利查蓉，同樣的，最終也就是Serverless的實(shí)例榜贴。

每個(gè)工作負(fù)載幾乎不需要部署豌研，因此給您大量的免費(fèi)計(jì)算時(shí)間和實(shí)例是有理可圖的，因?yàn)榧词故巧贁?shù)用戶超過了免費(fèi)的服務(wù)閾值唬党，也只有周期性得獲得了豐厚的回報(bào)鹃共。

而Serverless技術(shù)的用戶幾乎總是需要額外的服務(wù)：數(shù)據(jù)庫(kù)作為服務(wù)，消息隊(duì)列驶拱，內(nèi)存緩存及汉，API網(wǎng)關(guān)等等，這相當(dāng)于贈(zèng)送剃須刀手柄屯烦，并加價(jià)出售刀片。

這是一個(gè)長(zhǎng)尾的效應(yīng)房铭，但利潤(rùn)拋物線非常陡峭驻龟，得到了很多只有執(zhí)行和計(jì)算時(shí)間，因?yàn)樗恍枰晕⒊^這些限制缸匪，云提供商就能實(shí)現(xiàn)利潤(rùn)翁狐。

因此當(dāng)使用Serverles時(shí)，會(huì)得到顯著的成本節(jié)省凌蔬。

無論大小露懒，在服務(wù)器上運(yùn)行相同數(shù)量的工作比虛擬機(jī)上花費(fèi)更少。

更好的是砂心，沒有服務(wù)器懈词，也沒有僵尸。

因?yàn)榉?wù)提供者會(huì)自動(dòng)處理供應(yīng)和自動(dòng)設(shè)備辩诞，而且只需要支付代碼運(yùn)行的次數(shù)以及它在運(yùn)行時(shí)所使用的計(jì)算資源的數(shù)量坎弯，就不會(huì)為正在使用電力的服務(wù)器實(shí)例付費(fèi)。

Markdown

Serverless并不意味著NoOps，但它確實(shí)意味著是更精簡(jiǎn)的DevOps團(tuán)隊(duì)抠忘。

Serverless的Ops

這里有Serverless的實(shí)際好處：如果沒有服務(wù)器可以管理撩炊，那么構(gòu)建和部署解決方案的工作就更少了嗎？

答案是崎脉，是的拧咳，作為技術(shù)經(jīng)理所需要領(lǐng)導(dǎo)的時(shí)間將會(huì)大大減少，每個(gè)員工的工作時(shí)間也會(huì)被壓縮到生產(chǎn)當(dāng)中囚灼。

什么叫NoOps骆膝？這是一個(gè)時(shí)髦的詞，所以每個(gè)人的定義各有不同啦撮，但大部分的人都會(huì)同意以下觀點(diǎn)：NoOps的核心是可以使用自動(dòng)化谭网、服務(wù)抽象和供應(yīng)商提供的服務(wù)來減少或消除傳統(tǒng)上需要在DevOps中執(zhí)行的任務(wù)。

例如赃春，今天可能有一個(gè)敏捷過程愉择，在此之中，工作被分配給Sprint织中，每個(gè)星期锥涕、兩周或任何時(shí)候，團(tuán)隊(duì)實(shí)現(xiàn)其變更狭吼，然后構(gòu)建和測(cè)試层坠，如果測(cè)試完畢即可部署。

這涉及到測(cè)試工程師的工作刁笙，構(gòu)建工程師破花，系統(tǒng)工程師、開發(fā)團(tuán)隊(duì)等等疲吸，都會(huì)產(chǎn)生一些焦慮座每，尤其是在構(gòu)建失敗的時(shí)候。

在NoOps中摘悴，發(fā)展的速度要快得多峭梳，使用持續(xù)集成和持續(xù)部署，自動(dòng)化構(gòu)建和測(cè)試用于確保每個(gè)特性或修復(fù)不被破壞解決方案蹂喻，如果有葱椭，將快速調(diào)整更改，重復(fù)這個(gè)自動(dòng)構(gòu)建和測(cè)試過程口四，直到特性或修復(fù)工作孵运，然后就可以立即被推到登臺(tái)和生產(chǎn)。

這種快速的節(jié)奏之所以有效蔓彩，是因?yàn)闃?gòu)建（通過微服務(wù)）是有意分發(fā)的掐松。

通過處理應(yīng)用和幾個(gè)小任務(wù)的組合踱侣，可以安全得處理每一個(gè)小任務(wù)，而不需要對(duì)給定的微服務(wù)任何變化都有很大的擔(dān)心大磺，降低了宕機(jī)時(shí)間抡句。

另外由于函數(shù)是自動(dòng)配置和分配以滿足需求的，因此基于它們的應(yīng)用往往會(huì)快速擴(kuò)展并具有很高的可用性杠愧。

也就是說待榔，無需監(jiān)控微服務(wù)看它的在線或滿足需求高峰，如果云提供商的底層服務(wù)器服務(wù)正常運(yùn)行流济，即會(huì)處理需求峰值和出問題的實(shí)例锐锣。

因此，根據(jù)定義绳瘟，除非云提供商正在歷經(jīng)服務(wù)中斷雕憔，否則在一個(gè)不需要任何服務(wù)的應(yīng)用中，就不能有宕機(jī)時(shí)間糖声，即使這樣也可以通過將完全相同的代碼庫(kù)部署到不同的區(qū)域斤彼，并使用基于DNS的路由來確保故障轉(zhuǎn)移保護(hù)。

Serverless的好處

因此回顧一下Serverless功能的好處：

• 實(shí)際基礎(chǔ)設(shè)施成本較低蘸泻。
• 通過微服務(wù)架構(gòu)進(jìn)行工作琉苇，這是有意將業(yè)務(wù)邏輯關(guān)注點(diǎn)彼此分離的，這使您的應(yīng)用開過過程更加簡(jiǎn)單悦施，因?yàn)閕額可以將解決方案的功能作為獨(dú)立單元進(jìn)行管理并扇。
• 因?yàn)闊o需管理服務(wù)器，所以只需要關(guān)注代碼抡诞，減少每個(gè)代碼更改的人員和時(shí)間穷蛹。
• 而事實(shí)上，這允許我們采用一個(gè)非持绾梗快速的開發(fā)過程肴熏，專注于自動(dòng)化、抽象和持續(xù)交付以及持續(xù)集成乔遮。
• 而且由于云提供程序在實(shí)例被供應(yīng)和分配時(shí)處理，有效的將高可用性和災(zāi)難恢復(fù)構(gòu)建在基于服務(wù)器的解決方案中取刃。
• 誠(chéng)然蹋肮，底層服務(wù)可能會(huì)遇到問題，但可以使用傳統(tǒng)的基于云的業(yè)務(wù)連續(xù)性技術(shù)來管理這種情況璧疗。

若每個(gè)人都能專注于編程

事實(shí)上坯辩，Serverless是一個(gè)跳板，它本身就是一個(gè)讓每個(gè)人都能成為程序員的通道崩侠，因?yàn)橐坏┩瓿闪伺渲煤筒渴鸱?wù)器這種神秘的工作漆魔，就可以專注于代碼本身的自動(dòng)化。

微服務(wù)體系結(jié)構(gòu)本身就是將幾個(gè)小任務(wù)鏈接到一個(gè)工作流中的過程，可以將這些任務(wù)以新的方式結(jié)合起來改抡，以新的投入為基礎(chǔ)矢炼，為問題創(chuàng)造全新的解決方案。

我們已經(jīng)達(dá)到了一個(gè)目標(biāo)：使用人工智能和智能設(shè)備阿纤，比如Sire以及Google搜索句灌、Alexa去理解相對(duì)非結(jié)構(gòu)化的請(qǐng)求并生成有意義的響應(yīng)，為什么這些相同類型的服務(wù)不能用于創(chuàng)建代碼欠拾？或者至少是智能工作流呢胰锌？

為什么那些有創(chuàng)造力的人不能創(chuàng)造出新的和重要的解決方案，他們能夠自己創(chuàng)造這些工作流程藐窄，利用現(xiàn)代計(jì)算的力量呢资昧？

這些是值得去思考的問題。

Markdown

微軟的三種現(xiàn)代解決方案特點(diǎn)：“智能邊緣”設(shè)備的遙測(cè)技術(shù)在“智能中心”中得到鞏固和解釋荆忍，使用人工智能格带，在中心和邊緣進(jìn)行Serverless的技術(shù)處理計(jì)算。

上面所說很大程度上借用了Satya Nadella在微軟（Microsoft Build）的主題演講东揣。

Satya Nadella對(duì)計(jì)算機(jī)的未來提出了一個(gè)設(shè)想践惑，包括兩個(gè)領(lǐng)域：“智能邊緣”和“智能云”。

智能EDGE是我們所有鏈接到互聯(lián)網(wǎng)網(wǎng)的設(shè)備嘶卧，而且通常也自身也足夠強(qiáng)大尔觉，擁有獨(dú)立思考的屬性，不僅是我們的電腦芥吟，智能手機(jī)侦铜，平板電腦等，還包括電視钟鸵、電器钉稍、汽車、醫(yī)療監(jiān)視器棺耍、玩具贡未，甚至是使用的工具。

從所有這些設(shè)備的輸入中蒙袍，有一個(gè)統(tǒng)一的平臺(tái)去進(jìn)行管理——智能云俊卤。

當(dāng)每個(gè)設(shè)備都在我們的生活中實(shí)踐時(shí)，云利用人工智能和大數(shù)據(jù)推導(dǎo)出真知灼見以及行動(dòng)害幅，然后反饋到每個(gè)設(shè)備上消恍，指導(dǎo)它們?nèi)绾涡袆?dòng)，并且告訴它們這是為什么以现，以便于它們進(jìn)行學(xué)習(xí)狠怨。

在微軟的愿景當(dāng)中约啊，這種云處理是在Serverless的平臺(tái)上進(jìn)行的，這種平臺(tái)是無限可伸縮的佣赖。

Serverless的欠缺處

和上面提到的容器的欠缺之處一樣恰矩，Serverless本身也是擁有不足的，接下來就來談?wù)勊荒茏鍪裁匆鹛约盀槭裁刺摂M機(jī)容器不會(huì)很快消失枢里。

顯然將大規(guī)模的應(yīng)用集群改為微服務(wù)架構(gòu)并非小事。

前期的成本很高蹂午，可能會(huì)有伙伴關(guān)系或其他業(yè)務(wù)和要求栏豺，比如數(shù)據(jù)隱私和主權(quán)，這限制或阻止簡(jiǎn)單得放棄一直在構(gòu)建應(yīng)用的方式豆胸。

即使有很好的基本的N層架構(gòu)奥洼，從使用容器中得到得益處可能遠(yuǎn)遠(yuǎn)超過將應(yīng)用重新構(gòu)建為可移植單元的好處。

而且并不是每個(gè)工作負(fù)載都適用于微服務(wù)晚胡，如果你的任務(wù)不需要擴(kuò)展——如果它有一個(gè)可預(yù)測(cè)的工作負(fù)載——那么就有一個(gè)強(qiáng)有力的理由反對(duì)使用微服務(wù)灵奖。

如果解決方案嚴(yán)重依賴于其他服務(wù)，或者需要對(duì)運(yùn)行時(shí)環(huán)境進(jìn)行高度專門化的控制估盘，那么這一點(diǎn)尤其正確瓷患，不要試圖繞過服務(wù)器運(yùn)行時(shí)環(huán)境的限制，或補(bǔ)償大量外部請(qǐng)求和響應(yīng)遣妥；只需將解決方案構(gòu)建為一個(gè)包擅编，并將其部署到容器中。

或者箫踩，如果應(yīng)用需要大量的計(jì)算資源來完成它的工作爱态，當(dāng)然，可能會(huì)在托管方面節(jié)省一些錢境钟，但是不斷供應(yīng)的VM或容器的可靠性可能會(huì)超過服務(wù)器功能所固有的代碼限制锦担。

這是一個(gè)討論Serverless解決方案局限性的好辦法井辜。

一個(gè)明顯的問題是伦腐，因?yàn)閷?shí)例只在需要時(shí)才提供，所以在很少使用Serverless代碼的情況下稽寒，可能會(huì)有一些延遲處理缚态，可以通過運(yùn)行探測(cè)來修復(fù)這個(gè)代碼磁椒，使得代碼保持溫暖，但這是一種黑客才使用的行為猿规，也許最好只是簡(jiǎn)單得將不經(jīng)常訪問的代碼放到一個(gè)總是熱的容器當(dāng)中去衷快，特別是在調(diào)用代碼時(shí)宙橱，性能是非常重要的姨俩。

此外蘸拔，還需要準(zhǔn)備好解決延遲和刪除微服務(wù)之間的鏈接的解決方案，例如环葵，如果有一個(gè)作為所有解決方案的微服務(wù)運(yùn)行身份驗(yàn)證API调窍，那么在它的通信中，即使是400微秒的延遲也會(huì)被放大成一個(gè)嚴(yán)重的张遭、系統(tǒng)性的錯(cuò)誤邓萨。

雖然容器還是一個(gè)比較新興的技術(shù)，但是Serverless比它更要新菊卷，Azure的功能在一般情況下還不到一年缔恳，Google的Serverless解決方案仍處于測(cè)試階段，IBM創(chuàng)建Serverless標(biāo)準(zhǔn)的努力也扔處于初級(jí)階段洁闰。

這就引出了另外一個(gè)問題：無論采取什么Serverless的方法歉甚，它在這個(gè)時(shí)候會(huì)有點(diǎn)拘泥于一個(gè)供應(yīng)商，幾乎可以在任何地方運(yùn)行一個(gè)容器扑眉，但如何獲得服務(wù)器代碼的運(yùn)行將多少取決于云提供商所支持的語言纸泄，以及它們用于創(chuàng)建Serverless實(shí)例和支持服務(wù)的方法。

代碼可以運(yùn)行到云提供商所支持的運(yùn)行時(shí)和版本上腰素，這是很有限的聘裁，因此很難引入某些庫(kù)或程序集，這會(huì)讓編程更加復(fù)雜弓千。

最后衡便，Serverless的編程模型——一個(gè)觸發(fā)接收輸入并創(chuàng)建一些輸出的事件——可能不是某個(gè)需求的正確解決方案。

總結(jié)

Serverless是云計(jì)算的下一個(gè)浪潮计呈，它節(jié)約了巨大的時(shí)間和成本砰诵，而且總投入甚至少于容器，只需要按需付費(fèi)捌显，沒有更多的僵尸服務(wù)占用整體利潤(rùn)茁彭。

云供應(yīng)商也通過供給本質(zhì)上相同的服務(wù)器給每個(gè)需要它們的人獲取顯著的利益，同時(shí)也保證了低成本和高性能扶歪。

由于是自動(dòng)化的理肺，Serverless的通用方面，高可用和災(zāi)難恢復(fù)是內(nèi)置的善镰，在區(qū)域性服務(wù)中斷的情況下妹萨，您可以使用傳統(tǒng)的基于云的業(yè)務(wù)連續(xù)性技術(shù)來保持運(yùn)行。

整個(gè)微服務(wù)概念建立在快速部署炫欺、持續(xù)集成乎完、持續(xù)交付和分離關(guān)注的基礎(chǔ)上，使Serverless成為改進(jìn)服務(wù)交付和快速適應(yīng)的理想方法品洛。

但Serverless并不是每個(gè)工作負(fù)載都適用的树姨，最好在容器中建立一個(gè)解決方案摩桶。

原文地址：http://www.tuicool.com/articles/FnQ3UvV
原文作者：Doug Vanderweide