無(wú)服務(wù)器計(jì)算，或者功能即服務(wù)（Functions-as-a-Service，以下簡(jiǎn)稱(chēng)FaaS），未來(lái)將會(huì)改變我們的產(chǎn)業(yè)鏈，凡是基于它的企業(yè)或者組織，最終會(huì)受益于它在價(jià)格、人力，以及上市時(shí)間等方面帶來(lái)的競(jìng)爭(zhēng)優(yōu)勢(shì)。

許多無(wú)服務(wù)器應(yīng)用程序，未來(lái)將會(huì)對(duì)FaaS和其他第三方提供的服務(wù)進(jìn)行組合，以便提供功能預(yù)管理和狀態(tài)管理。

工具會(huì)有極大地提升，特別是在部署和配置方面。

較好的無(wú)服務(wù)器架構(gòu)模式稍后就會(huì)出現(xiàn)，現(xiàn)在了解細(xì)節(jié)為時(shí)過(guò)早。

未來(lái)需要基于真正的DevOps概念，無(wú)服務(wù)器可以提供的所有市場(chǎng)效益，最終將會(huì)被擁有自己管理能力、自給自足的產(chǎn)品團(tuán)隊(duì)所收獲。

現(xiàn)在是2017年，距離兩年前無(wú)服務(wù)器計(jì)算革新只取得了少許進(jìn)展（你聽(tīng)見(jiàn)人們?cè)诔鑶幔浚＿@次變革并不是像Docker那樣突飛猛進(jìn)地前進(jìn)，而是采用了相對(duì)平穩(wěn)的發(fā)展節(jié)奏。Amazon新發(fā)布了Web Services的Lambda特性，產(chǎn)品保持了一個(gè)有規(guī)律的發(fā)布節(jié)奏，另一個(gè)重要的第三方（微軟）正在一個(gè)接一個(gè)地發(fā)布生產(chǎn)環(huán)境版本，也有一些新的開(kāi)源項(xiàng)目頻繁地加入這場(chǎng)盛宴。

當(dāng)我們接近早期階段的末尾時(shí)，來(lái)做一個(gè)有趣的游戲，讓我們戴上預(yù)測(cè)護(hù)目鏡（開(kāi)個(gè)玩笑），深入思考下一步會(huì)走向哪里，如何走到那一步，以及我們的組織需要去做什么來(lái)支持這一步的到來(lái)。所以，加入我們，讓我們看看無(wú)服務(wù)器計(jì)算未來(lái)可能發(fā)生什么。

讓讀者了解真實(shí)的未來(lái)！你可以通過(guò)閱讀這篇文章開(kāi)始了解細(xì)節(jié)。我們離無(wú)服務(wù)器還有多遠(yuǎn)？2020年怎么樣？請(qǐng)寄一張明信片給我！

無(wú)服務(wù)器能力展望計(jì)算

過(guò)去十年我們目睹了云計(jì)算的出現(xiàn)，然后它迅速地異軍突起。9年以前，虛擬公有云服務(wù)器還只是手上的玩具而已，但是在相當(dāng)短的時(shí)間里，當(dāng)我們考慮任何新的部署架構(gòu)方案時(shí)，它變成了大多數(shù)行業(yè)的首選平臺(tái)。

無(wú)服務(wù)器計(jì)算，或者Functions-as-a-Service（Faas），當(dāng)我們考慮“IT”如何變化時(shí)，它會(huì)是這次重大變化的最新出現(xiàn)部分。這次變革是一次我們一直以來(lái)所期待的自然過(guò)程，從我們?nèi)绾谓桓稇?yīng)用程序給客戶(hù)開(kāi)始，到希望能夠刪除所有的部件和基礎(chǔ)設(shè)施。

我們開(kāi)發(fā)的相當(dāng)一部分應(yīng)用程序，是由許多小的組件所組成的。每個(gè)這樣的組件包含了一個(gè)小的輸入集和上下文信息，需要消耗10毫秒或100毫秒完成組件的一些內(nèi)部工作，最終可能反饋一個(gè)結(jié)果，也可能更新相關(guān)內(nèi)容。這類(lèi)場(chǎng)景最適合無(wú)服務(wù)器計(jì)算。

我們預(yù)測(cè)未來(lái)由于FaaS在部署上的方便、快速、廉價(jià)，會(huì)有越來(lái)越多的團(tuán)隊(duì)基于FaaS開(kāi)發(fā)，這樣便于管理和擴(kuò)展基礎(chǔ)設(shè)施。我們對(duì)FaaS可以有很多種使用方式，包括：

由大量的順序消息處理器所組成的完整的后端數(shù)據(jù)管道通過(guò)HTTP API調(diào)用的同步服務(wù)通過(guò)獨(dú)立的膠水代碼提供針對(duì)部署、監(jiān)控的自定義操作邏輯對(duì)于計(jì)算密集任務(wù)，由實(shí)體服務(wù)器直接調(diào)用平臺(tái)縮放功能組成的混合動(dòng)力系統(tǒng)

使用FaaS的企業(yè)相較沒(méi)有使用的企業(yè)具有競(jìng)爭(zhēng)優(yōu)勢(shì)，包括價(jià)格、投向市場(chǎng)時(shí)間等。

管理應(yīng)用程序狀態(tài)

廣泛采用FaaS的一個(gè)先決條件是針對(duì)快速而簡(jiǎn)單的狀態(tài)管理方法的解決方案，或者一系列解決方案。無(wú)服務(wù)器計(jì)算是一種無(wú)狀態(tài)模式。我們不能假定任何有用的狀態(tài)存在，即不存在即時(shí)執(zhí)行環(huán)境內(nèi)不同的運(yùn)行時(shí)調(diào)用之間的有用狀態(tài)。一些應(yīng)用程序在這種限制下依然適用。例如，單純進(jìn)行數(shù)據(jù)轉(zhuǎn)換的消息驅(qū)動(dòng)組件不需要訪問(wèn)外部狀態(tài)，擁有無(wú)限制響應(yīng)時(shí)間需求的Web Service組件，其每一次調(diào)用時(shí)需要連接到一臺(tái)遠(yuǎn)程數(shù)據(jù)庫(kù)，這種做法也是可以接受的。但是對(duì)于其他應(yīng)用程序來(lái)說(shuō)，這種限制就顯得有些不足了。

解決這類(lèi)不足的一種方案是混合動(dòng)力系統(tǒng)，即在不同類(lèi)型的組件里管理狀態(tài)，而不是執(zhí)行我們的FaaS代碼。比較流行的混合動(dòng)力方案是通過(guò)云端基礎(chǔ)設(shè)施提供其他服務(wù)的前端FaaS功能。我們已經(jīng)見(jiàn)到了這種類(lèi)似于API網(wǎng)管的特定上下文邏輯的組件，它們提供了HTTP路由、授權(quán)，以及我們經(jīng)常在典型的Web Service里看到的節(jié)流邏輯，采用定義替換配置方式實(shí)現(xiàn)。Amazon最近也在管理狀態(tài)的通用方式上露了一手，使用他們的Step Functions服務(wù)，允許團(tuán)隊(duì)基于可配置的狀態(tài)機(jī)器定義應(yīng)用程序。Step Funcations服務(wù)本身可能沒(méi)什么過(guò)人之處，但是通常情況下這種無(wú)碼解決方案是很受歡迎的。

當(dāng)供應(yīng)商服務(wù)不充足時(shí)，對(duì)于混合動(dòng)力系統(tǒng)來(lái)說(shuō)，一種改變方式是團(tuán)隊(duì)堅(jiān)持開(kāi)發(fā)追蹤狀態(tài)的長(zhǎng)生命周期組件。這些組件可能被部署在CaaS（容器即組件，Containers-as-a-Service）或者PaaS（平臺(tái)即組件，Platform-as-a-Service）環(huán)境，和FaaS功能協(xié)同工作。

這種混合動(dòng)力系統(tǒng)組合了長(zhǎng)期運(yùn)行的組件邏輯和每一次FaaS功能請(qǐng)求邏輯。另一類(lèi)做法是完全地聚焦于FaaS功能，讓這些FaaS功能超越它們當(dāng)前執(zhí)行的環(huán)境，極其快速地獲取和持久化狀態(tài)。一種可能的實(shí)施方式是確保一個(gè)特定的FaaS功能，或者一系列FaaS功能，確保它們擁有類(lèi)似于Redis這樣的外部緩存機(jī)制，起到低延時(shí)訪問(wèn)作用。通過(guò)啟動(dòng)類(lèi)似于Amazon的same-zone plancement groups（置放組群）這樣的特性可以做到這一點(diǎn)。雖然這種解決方案較內(nèi)存/本地磁盤(pán)狀態(tài)方案來(lái)說(shuō)有些延遲，但是很多應(yīng)用程序會(huì)認(rèn)同這種解決方案。

混合方法的好處是經(jīng)常被訪問(wèn)的狀態(tài)可以和邏輯一起保存在環(huán)境當(dāng)中，那樣并不復(fù)雜，但是可能有點(diǎn)貴，必須要有邏輯網(wǎng)絡(luò)選址和外部狀態(tài)。另一方面，一個(gè)單純的FaaS方式的有點(diǎn)是更加一致性的編程模型，外加無(wú)服務(wù)器帶來(lái)的更為寬廣的伸縮使用和可操作性?xún)?yōu)勢(shì)。當(dāng)前的發(fā)展勢(shì)頭顯示最終混合方式會(huì)勝出，但是我們也應(yīng)該對(duì)其他方式開(kāi)放，比如類(lèi)似于啟用置放群組Lambdas。

無(wú)服務(wù)器協(xié)作服務(wù)

超越業(yè)務(wù)管理和狀態(tài)管理，我們可以預(yù)見(jiàn)到其他組件的服務(wù)化和商業(yè)化，即使在云端環(huán)境，傳統(tǒng)意義上我們希望開(kāi)發(fā)，或者至少自己管理這些服務(wù)。例如我們可以停止運(yùn)行在EC2機(jī)器上面的Mysql數(shù)據(jù)庫(kù)服務(wù)器，轉(zhuǎn)而使用Amazon的RDS服務(wù)器，我們可以使用Kinesis替換我們自管理的Kafka消息總線(xiàn)安裝程序。其他的基礎(chǔ)設(shè)施服務(wù)包括文件系統(tǒng)和數(shù)據(jù)倉(cāng)庫(kù)，而更多的面向應(yīng)用示例包括認(rèn)證和語(yǔ)音分析。

這種趨勢(shì)還會(huì)繼續(xù)，我們需要進(jìn)一步地減少創(chuàng)建或者維護(hù)產(chǎn)品所帶來(lái)的工作量。我們可以設(shè)想更多的預(yù)安裝的消息邏輯（把Apache Camel想象成服務(wù)，構(gòu)建到Amazon Kinesis或者SQS里面），并且進(jìn)一步開(kāi)發(fā)通用機(jī)器學(xué)習(xí)服務(wù)。

這里比較有意思的一個(gè)想法是FaaS功能，由于它們輕量級(jí)的應(yīng)用模式，可以將自己緊緊地綁定一個(gè)服務(wù)，使得FaaS調(diào)用服務(wù)功能的生態(tài)環(huán)境時(shí)可以調(diào)用其他的FaaS功能，諸如此類(lèi)等等。這會(huì)導(dǎo)致“有趣的”級(jí)聯(lián)錯(cuò)誤問(wèn)題，對(duì)于這種錯(cuò)誤我們需要更強(qiáng)大的監(jiān)控工具，會(huì)在本文稍后介紹。

站在數(shù)據(jù)中心后面

目前來(lái)看，絕大多數(shù)的無(wú)服務(wù)器計(jì)算是運(yùn)行在供應(yīng)商數(shù)據(jù)中心平臺(tái)上的。這就給出了一個(gè)替代方案，即如何運(yùn)行你的代碼，而不是在哪里運(yùn)行代碼。Amazon發(fā)布了一個(gè)有趣的新特性，即是允許它們的客戶(hù)在不同的地點(diǎn)運(yùn)行Lambda函數(shù)，例如，和Lamdba@Edge一起運(yùn)行在CDN內(nèi)，甚至在無(wú)服務(wù)器地點(diǎn)，例如，和Greengrass一起運(yùn)行的物聯(lián)網(wǎng)（IoT）設(shè)備。這樣做的原因是，Lamdba是一個(gè)極端輕量級(jí)的編程模型，本質(zhì)上的事件驅(qū)動(dòng)的，并且非常容易適配相同的知識(shí)理念、新地點(diǎn)的代碼風(fēng)格。Lambda@Edge是一個(gè)特別有趣的例子，因?yàn)樗峁┝嗽谝粋€(gè)地點(diǎn)進(jìn)行程序定制的可選項(xiàng)，這在以前是沒(méi)有出現(xiàn)過(guò)的情況。

當(dāng)然，這種做法的缺點(diǎn)是和供應(yīng)商深度綁定！對(duì)于那些不想使用第三方平臺(tái)，但是又想利用無(wú)服務(wù)器計(jì)算優(yōu)勢(shì)的廠商來(lái)說(shuō)，有一種可以接受的解決方案，類(lèi)似于Cloud Foundry已經(jīng)推出的PaaS。來(lái)自Kubernetes的Galactic Fog、IronFunctions以及Fission，是這種方案的早期作品。

我們將來(lái)需要的工具和技術(shù)

正如我之前描述的，這里有一個(gè)明顯的減速，使用無(wú)服務(wù)器方式時(shí)存在條件限制、性?xún)r(jià)比權(quán)衡。天下沒(méi)有免費(fèi)的午餐。對(duì)于已經(jīng)過(guò)了早期適應(yīng)階段的無(wú)服務(wù)器用戶(hù)來(lái)說(shuō)，我們需要解決或者緩解這些問(wèn)題。所幸，這方面目前發(fā)展勢(shì)頭良好。

部署工具

使用AWS的標(biāo)準(zhǔn)工具向Lambda部署函數(shù)挺復(fù)雜的，也比較容易出錯(cuò)。向API網(wǎng)關(guān)中添加Lambda函數(shù)，以響應(yīng)HTTP請(qǐng)求，你更多要做的工作是安裝和配置。無(wú)服務(wù)器和ClaudiaJS開(kāi)源項(xiàng)目項(xiàng)目已經(jīng)推動(dòng)部署改進(jìn)措施達(dá)一年之久，AWSSAM（AWS無(wú)服務(wù)器應(yīng)用模型）也在2016年加入到了這一行動(dòng)。所有這些項(xiàng)目通過(guò)在AWS標(biāo)準(zhǔn)工具的頂層增加大量自動(dòng)化程序，簡(jiǎn)單化了無(wú)服務(wù)器應(yīng)用程序的創(chuàng)建、配置和部署。但是我們還有很多工作要做。未來(lái)將會(huì)有兩個(gè)關(guān)鍵動(dòng)作實(shí)現(xiàn)完全自動(dòng)化：

初始化一個(gè)應(yīng)用程序或者環(huán)境的創(chuàng)建（例如，初始化生產(chǎn)環(huán)境，以及初始化臨時(shí)測(cè)試環(huán)境）持續(xù)多部件應(yīng)用程序的交付/部署

第一條很重要，我們也已經(jīng)開(kāi)始認(rèn)識(shí)到，以便更廣泛地推廣“生產(chǎn)提前期概念”。部署一個(gè)全新的無(wú)服務(wù)器應(yīng)用程序應(yīng)該是像創(chuàng)建一個(gè)新的Github倉(cāng)庫(kù)一樣容易，填充少量字段，然后按下按鈕，通過(guò)這種一鍵部署方式讓系統(tǒng)自動(dòng)創(chuàng)建你所需要的所有東西。

然而，光有簡(jiǎn)便的初始化部署方式是不夠的。我們也需要有比較好的工具，支撐前面提到的混合動(dòng)力系統(tǒng)的持續(xù)交付和持續(xù)部署。這意味著我們應(yīng)該可以部署一系列的計(jì)算函數(shù)以及CaaS/PaaS組件，連同所有應(yīng)用程序封裝服務(wù)的變化（例如，在一個(gè)API網(wǎng)關(guān)配置http路由，或者一個(gè)被單一應(yīng)用程序使用的Dynamo表），一鍵生效和回滾能力。此外，這些動(dòng)作都不應(yīng)該是很費(fèi)腦力去理解的，也不會(huì)需要幾天時(shí)間去完成安裝和維護(hù)任務(wù)。

這是一個(gè)很艱難的抉擇，但是我前面提到的工具（類(lèi)似于Terraform這樣的混合動(dòng)力工具）正在指引解決這些問(wèn)題的方式，我完全相信他們?cè)谖磥?lái)的幾個(gè)月或者幾年時(shí)間里可以在很大程度上解決問(wèn)題。

本文不僅僅討論部署代碼和配置服務(wù)。其他一些操作上關(guān)心的問(wèn)題也會(huì)被討論。安全問(wèn)題是一大問(wèn)題。當(dāng)前，獲取AWS憑證、角色，以及設(shè)置和維護(hù)都可能是一大麻煩事。AWS擁有一套完善的安全模型，但是我們需要一個(gè)工具，這個(gè)工具可以讓這套安全模型對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)更加友好。

總之，我們需要開(kāi)發(fā)人員在開(kāi)發(fā)他們的Webtask產(chǎn)品時(shí)，做到UX和Auth0都很好，就像AWS一樣的寬廣而有價(jià)值的生態(tài)系統(tǒng)。

監(jiān)控、日志和調(diào)試

一旦我們的應(yīng)用程序被部署完畢，我們就會(huì)需要針對(duì)監(jiān)控和日志的良好的解決方案，這類(lèi)工具目前有幾個(gè)組織正在嘗試積極地發(fā)展著。除了評(píng)估其中一個(gè)組件的功能，我們也需要號(hào)的工具追蹤請(qǐng)求，這些請(qǐng)求穿越了一個(gè)完整的多個(gè)無(wú)服務(wù)器計(jì)算功能和配套服務(wù)體系的分布式系統(tǒng)。Amazon正在將X-Ray推向該領(lǐng)域，目前說(shuō)這個(gè)還有點(diǎn)為時(shí)尚早。

調(diào)試也是挺重要的。程序員很少在第一次代碼運(yùn)行通過(guò)之前不犯錯(cuò)誤，我們也別寄希望于這種情況會(huì)有所改變。我們依賴(lài)于監(jiān)控，在FaaS功能的開(kāi)發(fā)階段評(píng)估問(wèn)題，但是這種調(diào)試方式是石器時(shí)代的工具。

當(dāng)我們調(diào)試傳統(tǒng)的應(yīng)用程序時(shí)，我們從IDE工具那里可以得到很大的支持，通過(guò)設(shè)置斷點(diǎn)、單步調(diào)試代碼，等等。使用現(xiàn)代化的基于Java的IDE工具，你可以綁定一個(gè)正在運(yùn)行的遠(yuǎn)程進(jìn)程，并且遠(yuǎn)程執(zhí)行調(diào)試工作。因?yàn)槲覀兏觾A向于使用云端部署的FaaS功能完成大量的部署工作，希望未來(lái)你的IDE工具也可以具有類(lèi)似的功能，可以連接到一臺(tái)正在運(yùn)行的無(wú)服務(wù)器平臺(tái)，查詢(xún)每個(gè)功能的執(zhí)行情況。這需要工具和平臺(tái)開(kāi)發(fā)商之間的協(xié)作，如果想要讓無(wú)服務(wù)器被廣泛采用，這些措施都是必要的。這些想法對(duì)于云計(jì)算來(lái)說(shuō)有一定開(kāi)發(fā)工作量，也有大量的測(cè)試工作量。

測(cè)試

我到目前為止所討論的所有關(guān)于無(wú)服務(wù)器工具的話(huà)題，我認(rèn)為最落后的是測(cè)試工具。值得關(guān)注的是，無(wú)服務(wù)器方案較傳統(tǒng)解決方案來(lái)說(shuō)有著相當(dāng)大的測(cè)試優(yōu)勢(shì)，主要是兩點(diǎn)，（a）.無(wú)服務(wù)器計(jì)算的各個(gè)功能的單元測(cè)試很成熟，（b）.無(wú)服務(wù)器服務(wù)寫(xiě)的代碼更少，并且至少在單元測(cè)試層面，只需要做簡(jiǎn)單的測(cè)試。

但是這并沒(méi)有解決跨組件功能/集成/驗(yàn)收/業(yè)務(wù)流程等測(cè)試問(wèn)題。無(wú)服務(wù)器計(jì)算時(shí)我們的邏輯是分散在幾個(gè)函數(shù)和服務(wù)內(nèi)的，因此，更高級(jí)別的測(cè)試甚至比使用接近單一方法的組件更重要。當(dāng)我們?nèi)绱艘蕾?lài)于在云端基礎(chǔ)設(shè)施上運(yùn)行時(shí)，我們應(yīng)該怎么做呢？

對(duì)于我們來(lái)說(shuō)，測(cè)試可能是最沒(méi)有看清楚的。我猜測(cè)未來(lái)基于云端的測(cè)試會(huì)變得很普遍。這一部分會(huì)變得更加容易部署、監(jiān)控，以及調(diào)試我們的無(wú)服務(wù)器apps，甚至于比我現(xiàn)在描述的這些原因更加豐富。

換句話(huà)說(shuō)，為了運(yùn)行更高級(jí)別的測(cè)試，我們將會(huì)部署整個(gè)生態(tài)系統(tǒng)的一部分到云端，并且對(duì)部署在那里的組件執(zhí)行測(cè)試用例，而不是針對(duì)部署在我們自己開(kāi)發(fā)機(jī)器上的系統(tǒng)運(yùn)行測(cè)試用例。這種做法有一定的優(yōu)勢(shì)：

執(zhí)行部署在云端的組件的真實(shí)度較本地模擬來(lái)說(shuō)更高。我們較過(guò)去，更有可能可以運(yùn)行高負(fù)載/高豐富度數(shù)據(jù)測(cè)試。生產(chǎn)環(huán)境數(shù)據(jù)源的測(cè)試組件（例如，一個(gè)發(fā)布訂閱模式的消息總線(xiàn)，或者一個(gè)數(shù)據(jù)庫(kù)）會(huì)更加容易，雖然顯而易見(jiàn)我們需要關(guān)注能力/安全問(wèn)題。

但是這種解決方案也有弱點(diǎn)。首先，執(zhí)行測(cè)試的周期時(shí)間很有可能由于部署和網(wǎng)絡(luò)延遲而相應(yīng)增加。其次，當(dāng)網(wǎng)絡(luò)連接中斷以后，我們就不可以繼續(xù)運(yùn)行測(cè)試用例了（例如，在飛機(jī)上）。最后，因?yàn)樯a(chǎn)環(huán)境和測(cè)試環(huán)境最終部署方案很相近，我們也需要格外小心，當(dāng)我們打算改變測(cè)試用例時(shí)，不要發(fā)生不小心改變了生產(chǎn)環(huán)境的事故。如果我們使用AWS，我們可能需要通過(guò)類(lèi)似于IAM角色這樣的工具安全地部署，或者對(duì)于不同類(lèi)型的環(huán)境使用完全不同的賬號(hào)進(jìn)行部署。

測(cè)試并不僅僅是一個(gè)二進(jìn)制程序運(yùn)行成功或者失敗，我們也想要去弄清楚測(cè)試是如何失敗的。我們應(yīng)該可以調(diào)試本地運(yùn)行測(cè)試和正在運(yùn)行的遠(yuǎn)端組件，包括可以單步調(diào)試一個(gè)運(yùn)行在AWS上的Lambda函數(shù)，因?yàn)樗梢韵鄳?yīng)測(cè)試。所以所有的遠(yuǎn)端調(diào)試，例如，我前面章節(jié)提到的工具也需要測(cè)試，而不是僅僅交互式開(kāi)發(fā)。

請(qǐng)注意，我并不是基于這些暗示我們的開(kāi)發(fā)工具需要運(yùn)行在云端，也不是測(cè)試本身需要運(yùn)行在云端，雖然兩者將來(lái)都會(huì)或多或少地走到這一步。我只是表示正在測(cè)試的系統(tǒng)僅運(yùn)行在云端，而不是一個(gè)非云端環(huán)境。

使用無(wú)服務(wù)器作為測(cè)試驅(qū)動(dòng)環(huán)境可以收獲有用的結(jié)果。一個(gè)例子被稱(chēng)為“無(wú)服務(wù)器火炮”，這是一種負(fù)載測(cè)試工具，由運(yùn)行著的許多并行的AWS Lamdbas組成，執(zhí)行即時(shí)、廉價(jià)、易于擴(kuò)展性能測(cè)試規(guī)模的負(fù)載測(cè)試用例。

值得指出的是，在某種程度上，我們避免了一些失誤。由于技術(shù)進(jìn)步，傳統(tǒng)的高層及測(cè)試實(shí)際上正在變得不那么重要，例如（a）生產(chǎn)環(huán)境測(cè)試/使用監(jiān)控驅(qū)動(dòng)開(kāi)發(fā)，（b）平均解決時(shí)間（MTTR）的顯著降低，（c）基于持續(xù)部署。對(duì)于許多的無(wú)服務(wù)器apps應(yīng)用廣泛的單元測(cè)試，度量業(yè)務(wù)水平的生產(chǎn)環(huán)境監(jiān)控&預(yù)警，以及一個(gè)專(zhuān)用于減少M(fèi)TTR和基于持續(xù)開(kāi)發(fā)的方法，都將會(huì)是有效的代碼驗(yàn)證策略。

架構(gòu)：有很多問(wèn)題需要回答

系統(tǒng)架構(gòu)較好的無(wú)服務(wù)器應(yīng)用程序是怎樣的？是如何演變的？

我們正在逐漸看到一些無(wú)服務(wù)器被有效地應(yīng)用的案例，即系統(tǒng)架構(gòu)的學(xué)習(xí)案例正在逐漸增多，但是我們還沒(méi)有看到針對(duì)無(wú)服務(wù)器Apps的“模式組”。在2000年早些時(shí)候，我們看到了一些這方面的書(shū)，比如Fowler的《Patterns Of Enterprise Application Architecture》，以及Hohpe / Woolf的《Enterprise Integration Patterns》。這些書(shū)著眼于很多項(xiàng)目，派生出橫貫不同領(lǐng)域的通用系統(tǒng)架構(gòu)知識(shí)。

重要的是，在做出統(tǒng)一意見(jiàn)之前，這些書(shū)著眼于基礎(chǔ)工具幾年的使用經(jīng)驗(yàn)。無(wú)服務(wù)器技術(shù)存在時(shí)間太短，還不足以需要編寫(xiě)一本書(shū)進(jìn)行描述，但是這一時(shí)刻正在逼近，一年內(nèi)我們會(huì)看到一些有用的實(shí)踐案例出現(xiàn)（當(dāng)無(wú)服務(wù)器架構(gòu)需要出一本高調(diào)的書(shū)時(shí)，大家一般會(huì)選用“最佳實(shí)踐”這樣的術(shù)語(yǔ)描述）。

系統(tǒng)架構(gòu)之后（即無(wú)服務(wù)器應(yīng)用程序是如何被構(gòu)建的），我們需要思考部署系統(tǒng)架構(gòu)（無(wú)服務(wù)器應(yīng)用程序如何部署）。我已經(jīng)談了一些部署工具，但是我們可以如何使用這些工具呢？例如：

環(huán)境這樣的術(shù)語(yǔ)在世界上意味著什么？“生產(chǎn)”看上去較過(guò)去有點(diǎn)不明確。什么是一個(gè)軟件棧的side-by-side部署？看上去像是從一組功能/服務(wù)版本緩慢地移動(dòng)業(yè)務(wù)到另一組功能/服務(wù)版本（滾動(dòng)部署）？世界上有么有類(lèi)似于“藍(lán)-綠”這樣的部署方式？現(xiàn)在的回滾方式是怎樣的？我們?nèi)绾喂芾頂?shù)據(jù)庫(kù)的升級(jí)/回滾，當(dāng)我們可能有多個(gè)不同的代碼生產(chǎn)版本，并且這些版本在同一個(gè)功能內(nèi)運(yùn)行，這類(lèi)有狀態(tài)組件應(yīng)該如何管理？當(dāng)使用第三方服務(wù)時(shí)，如果你不能夠完全下線(xiàn)服務(wù)或者重新完整地部署，那么一臺(tái)phoenix-server看起來(lái)更像什么？

最后，當(dāng)我們從一種系統(tǒng)架構(gòu)樣式遷移到其他架構(gòu)，什么遷移模式是比較有效的？或者是否包括無(wú)服務(wù)器組件？我們的架構(gòu)以怎樣的方式進(jìn)化？

許多這些尚未定義的模式（反模式）都不是很明顯的，通過(guò)我們幼稚的想法明顯表現(xiàn)出來(lái)的是，如何最好地管理無(wú)服務(wù)器系統(tǒng)內(nèi)的狀態(tài)。毫無(wú)疑問(wèn)，有一些神奇的模式出現(xiàn)了。

我們的組織將會(huì)如何變化

成本效益是無(wú)服務(wù)器前進(jìn)的一項(xiàng)驅(qū)動(dòng)，最有意思的優(yōu)勢(shì)是“生產(chǎn)提前期概念”的降低。通過(guò)提供“超級(jí)能力”方式，無(wú)服務(wù)器為大多數(shù)既不是系統(tǒng)管理專(zhuān)家，也不是分布式系統(tǒng)開(kāi)發(fā)專(zhuān)家的美國(guó)工程師提供了進(jìn)入無(wú)服務(wù)器領(lǐng)域的可行性。這些只有一點(diǎn)點(diǎn)技術(shù)的應(yīng)用程序開(kāi)發(fā)工程師，不再需要編寫(xiě)一行Shell腳本，即可完成整套MVP（即Minimum Viable Product，最小可行性產(chǎn)品）的部署，擴(kuò)展平臺(tái)能力，或者配置一個(gè)nginx服務(wù)器。前文中我提到了配置工具還在開(kāi)發(fā)當(dāng)中，我們現(xiàn)在還沒(méi)有這類(lèi)“簡(jiǎn)單的MVP”解決方案，能夠解決所有類(lèi)型的應(yīng)用程序問(wèn)題。但是，我們確實(shí)看到了相對(duì)于簡(jiǎn)單的Web Services服務(wù)，甚至為其他類(lèi)型的應(yīng)用程序部署一些Lambda函數(shù)，也比管理操作系統(tǒng)進(jìn)程或者容器來(lái)得更容易。

除了MVP以外，我們也看到了重新部署應(yīng)用程序的周期時(shí)間正在縮短，不再需要關(guān)心腳本維護(hù)、系統(tǒng)補(bǔ)丁級(jí)別，等等。

無(wú)服務(wù)器為我們提供了技術(shù)手段去實(shí)現(xiàn)這些需求，但是還不足以真正實(shí)現(xiàn)對(duì)于一個(gè)組織的改進(jìn)。為了實(shí)現(xiàn)這些目標(biāo)，公司需要去克服、適應(yīng)以下這些變化。

真正的DevOps

DevOps已經(jīng)在很多領(lǐng)域都變得很重要了。在開(kāi)發(fā)工作上，額外技術(shù)的技術(shù)操作越來(lái)越常見(jiàn)。我所看見(jiàn)的是系統(tǒng)管理內(nèi)部的自動(dòng)化增加和自動(dòng)化測(cè)試，這只是Patrick Debois在創(chuàng)造DevOps概念時(shí)所想到的很小一部分。

真正的DevOps是我們思維方式上的變化，以及文化上的變化。讓我們假設(shè)有這么一個(gè)團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)需要緊密合作、開(kāi)發(fā)和維護(hù)一個(gè)產(chǎn)品。這就意味著寫(xiě)作，而不是基
于協(xié)商的工作序列方式。也意味著開(kāi)發(fā)人員需要提供技術(shù)支持。而意味著開(kāi)發(fā)工程師需要參與應(yīng)用系統(tǒng)架構(gòu)。換句話(huà)說(shuō)，意味著技能與責(zé)任的融合。

如果一個(gè)公司分離了開(kāi)發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)，即將“DevOps”團(tuán)隊(duì)分離，那么他們不會(huì)在無(wú)服務(wù)器領(lǐng)域有任何收獲。如果一個(gè)開(kāi)發(fā)人員僅僅只是對(duì)應(yīng)用程序進(jìn)行編碼，而部署工作又交給另一個(gè)外部團(tuán)隊(duì)負(fù)責(zé)，那就會(huì)沒(méi)有真正意義上的系統(tǒng)部署情況反饋。如果一個(gè)業(yè)務(wù)工程師不會(huì)到應(yīng)用程序的部署環(huán)節(jié)，那么他們也不可能適應(yīng)生產(chǎn)環(huán)境的部署模型。

換句話(huà)說(shuō)，未來(lái)會(huì)從無(wú)服務(wù)器領(lǐng)域收獲實(shí)際收益的公司，必然是真正使用DevOps的公司。

政策/訪問(wèn)控制的變化

即便一個(gè)組一個(gè)組地嘗試改變文化，也是做得不夠的。很多時(shí)候，一個(gè)大公司里的一個(gè)很有工作熱情的團(tuán)隊(duì)，往往面對(duì)的是冷冰冰的公司政策。這可能意味著在缺乏外部批準(zhǔn)的情況下，缺少部署新系統(tǒng)的能力。很有可能是由于對(duì)于所有現(xiàn)有應(yīng)用程序的數(shù)據(jù)訪問(wèn)限制。也可能是因?yàn)槌?jí)嚴(yán)格的支出控制。

雖然我不提倡公司把所有與安全和成本相關(guān)的問(wèn)題拋到外部解決，但是為了盡可能做到無(wú)服務(wù)器化，需要調(diào)整他們的政策，允許團(tuán)隊(duì)對(duì)操作請(qǐng)求作出改變，而不是每一次小的更新操作都需要一個(gè)團(tuán)隊(duì)外部人員的批準(zhǔn)。訪問(wèn)控制政策目前還不是很有必要構(gòu)建。團(tuán)隊(duì)需要被給予一定范圍內(nèi)的預(yù)算自由。所有的實(shí)驗(yàn)應(yīng)該被盡可能多地提供免費(fèi)的沙盒，同事還可以保護(hù)公司內(nèi)部真正敏感的數(shù)據(jù)或其他需求。

通過(guò)我之前提到過(guò)的IAM規(guī)則和多個(gè)AWS賬戶(hù)的使用，訪問(wèn)控制工具正在逐漸完善。然而，不是那么簡(jiǎn)單的，針對(duì)更好的自動(dòng)化方式正在成熟。同樣，無(wú)服務(wù)器還存在通過(guò)幾個(gè)賬戶(hù)實(shí)現(xiàn)基本預(yù)算控制，我們需要更容易控制每個(gè)團(tuán)隊(duì)執(zhí)行能力限制，對(duì)于不同的環(huán)境有不同的執(zhí)行限制范圍。

好消息是通過(guò)加強(qiáng)權(quán)限控制工具，所有這些問(wèn)題都有可能解決，我們會(huì)看到y(tǒng)預(yù)算分配模式上的進(jìn)步，等等，因?yàn)闊o(wú)服務(wù)器工具在持續(xù)改進(jìn)。事實(shí)上，我認(rèn)為訪問(wèn)自動(dòng)化和成本控制將會(huì)變成新的shell腳本，換句話(huà)說(shuō)，當(dāng)團(tuán)隊(duì)思考suanfa軟件的操作問(wèn)題時(shí)，他們不會(huì)想要去開(kāi)始/停止腳本、升級(jí)補(bǔ)丁以及磁盤(pán)使用率，反而他們會(huì)嚴(yán)謹(jǐn)?shù)厮伎妓麄冃枰鯓拥臄?shù)據(jù)訪問(wèn)方式，以及需要怎樣的預(yù)算。因?yàn)閳F(tuán)隊(duì)將會(huì)經(jīng)常需要思考這個(gè)問(wèn)題，工程師們會(huì)用自動(dòng)化取代這些問(wèn)題，僅僅像我們之前做部署那樣。

鑒于這種能力和嚴(yán)謹(jǐn)性，未來(lái)即便是數(shù)據(jù)最敏感的企業(yè)，也會(huì)有富有熱情的團(tuán)隊(duì)會(huì)使用無(wú)服務(wù)器技術(shù)，使用它們?nèi)L試自己的想法，這種做法是之前在白板上從未做過(guò)的，最終他們會(huì)認(rèn)識(shí)到這種做法真正意義上保護(hù)了他們的知識(shí)或者避免財(cái)務(wù)損失。

產(chǎn)品所有權(quán)

過(guò)去幾年時(shí)間里我們看到的另一個(gè)轉(zhuǎn)變是許多高效的工程團(tuán)隊(duì)的聚焦正在從項(xiàng)目專(zhuān)項(xiàng)產(chǎn)品。這一轉(zhuǎn)變的感覺(jué)是對(duì)于項(xiàng)目規(guī)劃、迭代和燃盡圖等的關(guān)注在降低，轉(zhuǎn)而更加關(guān)注看板方式的進(jìn)展、輕量級(jí)預(yù)估以及持續(xù)交付。比這一結(jié)構(gòu)性改變更重要的是雖然角色和心態(tài)在轉(zhuǎn)變，轉(zhuǎn)變?yōu)楦嗟穆氊?zé)較差，同樣我們看到真正的DevOps。

舉個(gè)例子，現(xiàn)在很有可能產(chǎn)品經(jīng)理和開(kāi)發(fā)人員將會(huì)密切地充實(shí)新思路，開(kāi)發(fā)人員會(huì)做一些原型，產(chǎn)品經(jīng)理在最終產(chǎn)品設(shè)計(jì)方案明確之前，會(huì)深入進(jìn)行一些技術(shù)上的數(shù)據(jù)分析。相似地，創(chuàng)新的火花，即新的想法或者概念也會(huì)進(jìn)入某人的大腦，可能屬于團(tuán)隊(duì)中的任何一個(gè)人。這個(gè)團(tuán)隊(duì)的許多成員，不僅僅是一個(gè)，現(xiàn)在正在接觸到客戶(hù)喜歡的想法。

無(wú)服務(wù)器方法為這些團(tuán)隊(duì)提供了一個(gè)關(guān)鍵好處，即接受整個(gè)團(tuán)隊(duì)產(chǎn)品思維。當(dāng)團(tuán)隊(duì)中的任何一個(gè)人都可以想出一個(gè)點(diǎn)子，并且迅速地針對(duì)一種盡可能新的創(chuàng)新模式實(shí)現(xiàn)一個(gè)原型。現(xiàn)在精益啟動(dòng)式試驗(yàn)變成默認(rèn)的思維方式，而不是由“黑客時(shí)代”保留的那樣，因?yàn)檫@樣做的成本和時(shí)間正在大幅縮減。

另一種看待這一問(wèn)題的方法是，不接受整個(gè)團(tuán)隊(duì)產(chǎn)品思維的團(tuán)隊(duì)很有可能錯(cuò)誤這一關(guān)鍵利益。如果團(tuán)隊(duì)不鼓勵(lì)超越項(xiàng)目結(jié)構(gòu)的思考方式，他們就很難盡可能多地使用無(wú)服務(wù)器所帶來(lái)的加速交付可能性。

結(jié)論

無(wú)服務(wù)器在軟件架構(gòu)領(lǐng)域相對(duì)來(lái)說(shuō)是一個(gè)新的概念，但是它也是一個(gè)可能和其他云計(jì)算創(chuàng)新一樣，具有巨大影響力的技術(shù)創(chuàng)新。隨著技術(shù)的發(fā)展、工具提升以及無(wú)服務(wù)器應(yīng)用架構(gòu)方面的心得交流，越來(lái)越多的工程團(tuán)隊(duì)將會(huì)擁有提升開(kāi)發(fā)速度的工具，甚至于可能轉(zhuǎn)變他們產(chǎn)品開(kāi)發(fā)方式。適應(yīng)無(wú)服務(wù)器，并且適應(yīng)支撐該技術(shù)的文化，這類(lèi)公司將會(huì)在未來(lái)領(lǐng)導(dǎo)我們前進(jìn)。

致謝

感謝為此文貢獻(xiàn)知識(shí)的朋友們：John Chapin、Chris Stevenson、Badri Janakiraman、Ben Rady、Ben Kehoe, 以及Nat Pryce。

關(guān)于作者

Mike Roberts是Symphonia公司的合伙人，同時(shí)也負(fù)責(zé)公司的工程團(tuán)隊(duì)，該公司提供關(guān)于無(wú)服務(wù)器和云計(jì)算技術(shù)的咨詢(xún)。Mike是敏捷開(kāi)發(fā)和DevOps價(jià)值的長(zhǎng)期支持者，并且認(rèn)為云計(jì)算技術(shù)已經(jīng)讓許多高級(jí)軟件開(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)了這兩個(gè)技術(shù)的價(jià)值。他認(rèn)為無(wú)服務(wù)器將會(huì)是云系統(tǒng)之后的一次技術(shù)革命點(diǎn)，對(duì)于無(wú)服務(wù)器是否有能力極大地幫助開(kāi)發(fā)團(tuán)隊(duì)，他持樂(lè)觀態(tài)度。可以通過(guò)郵箱地址和Twitter地址與Mike聯(lián)系。

英文原文：The Future of Serverless Compute