2009年，業(yè)界提出DevOps理念。維基百科上解釋為“DevOps是軟件開(kāi)發(fā)、運維和質(zhì)量保證三個(gè)部門(mén)之間的溝通、協(xié)作和集成所采用的流程、方法和體系的一個(gè)集合?！?/p>
2011年，Forrester發(fā)布報告“擴大DevOps至NoOps”，預測在不久的將來(lái)，一些企業(yè)將越來(lái)與多地依賴(lài)于云，開(kāi)發(fā)者將能更加自動(dòng)地進(jìn)行程序構建（building）、測試與部署等運維操作，最終達到NoOps。雖然該術(shù)語(yǔ)表示這些公司將不再需要運維人員，但是報告的本意談?wù)摰膮s是開(kāi)發(fā)者將使用更加自動(dòng)化的工具，而這些工具需要更少的人工干預。隨后PaaS被視為是實(shí)現NoOps的最佳方式。
2014年，云廠(chǎng)商AWS推出了“無(wú)服務(wù)器”的范式服務(wù)。
技術(shù)的世界變化太快，理念總是跑在太前面。DevOps現在依然沒(méi)有踏踏實(shí)實(shí)地完全落地，現在就又出現了無(wú)服務(wù)器架構體系。這究竟是怎么一回事？隨之而來(lái)的影響，尤其對于運維內容的影響，會(huì )是什么呢？
無(wú)服務(wù)器體系的問(wèn)世
最初，“無(wú)服務(wù)器”意在幫助開(kāi)發(fā)者擺脫運行后端應用程序所需的服務(wù)器設備的設置和管理工作。這項技術(shù)的目標并不是為了實(shí)現真正意義上的“無(wú)服務(wù)器”，而是指由第三方供應商負責后端基礎結構的維護，以服務(wù)的方式為開(kāi)發(fā)者提供所需功能，例如數據庫、消息，以及身份驗證等。這種服務(wù)基礎結構通?？梢越凶龊蠖思捶?wù)（Backend-as-a-Service，BaaS），或移動(dòng)后端即服務(wù)（MobileBackend-as-a-service，MBaaS）。
但Amazon在2014年發(fā)布的AWSLambda讓“無(wú)服務(wù)器”這一范式提高到一個(gè)全新的層面，為云中運行的應用程序提供了一種全新的系統體系結構。至此再也不需要在服務(wù)器上持續運行進(jìn)程以等待HTTP請求或API調用，而是可以通過(guò)某種事件機制觸發(fā)代碼的執行，通常這只需要在A(yíng)WS的某臺服務(wù)器上運行一個(gè)簡(jiǎn)單的功能。
使用這一范式的開(kāi)發(fā)者無(wú)需考慮服務(wù)器細節，只需要負責編寫(xiě)發(fā)生某些事件后所需執行的代碼。云供應商將負責提供用于運行這些代碼的服務(wù)器，并在必要時(shí)對服務(wù)器進(jìn)行縮放。執行完畢后，承擔這些功能的容器會(huì )立刻停用，并且執行過(guò)程以100毫秒為單位進(jìn)行度量，用戶(hù)只需為運行代碼過(guò)程中所消耗的資源付費。一些人將這種模式叫做功能即服務(wù)（Function-as-a-Service，FaaS），另一種“即服務(wù)”（Yet-Another-as-a-Service，YassS），自從云計算技術(shù)登場(chǎng)后這樣的稱(chēng)呼越來(lái)越多了。
Amazon并不是唯一的FaaS供應商。其他廠(chǎng)商，例如Google Cloud Functions、MicrosoftAzure Functions、IBM OpenWhisk，以及Iron.io和Webtask等各種開(kāi)源實(shí)現都提供了類(lèi)似的服務(wù)。
什么是無(wú)服務(wù)器架構？
Mike Robers在Martin Fowler的博客網(wǎng)站上發(fā)布了一篇題為“無(wú)服務(wù)器架構”的文章，在該文章中，他認為無(wú)服務(wù)器是后端即服務(wù)(BaaS)和函數即服務(wù)(FaaS)的結合，并以AWSLambda產(chǎn)品為例探討了FaaS的特點(diǎn)、什么不是無(wú)服務(wù)器及需要考慮的其他相關(guān)問(wèn)題。他指出：
就像很多軟件發(fā)展趨勢一樣，業(yè)界并沒(méi)有對“無(wú)服務(wù)器”有一個(gè)明確的說(shuō)法，即使它真的表示以下兩個(gè)不同而又重疊的領(lǐng)域也不會(huì )對此有所幫助：
1. 無(wú)服務(wù)器先用來(lái)描述那些顯著(zhù)或完全依賴(lài)于第三方應用或服務(wù)（“在云端”）的應用程序。這些應用程序依賴(lài)于第三方來(lái)管理服務(wù)器端邏輯和狀態(tài)，它們都是典型“富客戶(hù)端”的應用程序（你可以想象為單一頁(yè)面的Web應用程序或移動(dòng)應用），并采用云平臺提供的生態(tài)系統，包括可訪(fǎng)問(wèn)的數據庫（如Parse、Firebase）、認證服務(wù)（Auth0、AWSCognito）等。這些類(lèi)型的服務(wù)以前被描述為“（移動(dòng)）后端即服務(wù)”。我在文中會(huì )用“BaaS”縮寫(xiě)來(lái)代替這樣的服務(wù)。
2. 無(wú)服務(wù)器還表示那些有服務(wù)器端邏輯的應用仍然需要由開(kāi)發(fā)者來(lái)編寫(xiě)。不同于傳統的架構，它運行在無(wú)狀態(tài)計算的容器中，這些容器由事件觸發(fā)的、是短暫的（也許僅僅只是一次調用）、并且完全由第三方管理。（感謝ThoughtWorks在他們最近的技術(shù)雷達的定義。）理解這個(gè)觀(guān)點(diǎn)的另一種方式是“函數即服務(wù)（FaaS）”，其中AWSLambda是目前最流行的FaaS實(shí)現之一。
無(wú)服務(wù)器≠沒(méi)有運維
不僅廠(chǎng)商積極跟進(jìn)，業(yè)界還在倫敦、東京、紐約舉辦了Serverlessconf，足見(jiàn)此概念的受關(guān)注度。
今年的Serverlessconf London 2016活動(dòng)第一天起，人們就開(kāi)始關(guān)注一個(gè)新興的話(huà)題：“NoOps”無(wú)服務(wù)器平臺為運維工作造成的前所未有的挑戰。Patrick Debois在開(kāi)幕式主題演講中提到了這一問(wèn)題，并問(wèn)及一系列有關(guān)無(wú)服務(wù)器技術(shù)是否會(huì )變得更好、更快速、更便宜（以及更安全）等問(wèn)題。Debois認為，諸如AWS Lambda、Azure Functions，以及Google Cloud Functions等無(wú)服務(wù)器平臺依然面臨不小的挑戰，尤其是在日志和監視等運維領(lǐng)域。
物理服務(wù)器和虛擬機可以進(jìn)行抽象，但這并不意味著(zhù)可以徹底省略基礎架構配置工作，開(kāi)發(fā)者往往會(huì )忽略底層持久機制所蘊含的巨大風(fēng)險。
Honeycomb的創(chuàng )始人CharityMajors當天所做的名為“無(wú)服務(wù)器，NoOps和牙仙”的演講。他對無(wú)服務(wù)器平臺狀態(tài)管理方面的問(wèn)題尤為關(guān)注，并且強調到并不是說(shuō)交由別人負責管理數據庫，就意味著(zhù)你沒(méi)有責任且萬(wàn)事大吉。他對于運維有著(zhù)極為寬廣的定義：
運維是組織內部一系列圍繞系統設計、構建和維護，軟件發(fā)布，以及通過(guò)技術(shù)方式解決問(wèn)題所需的技術(shù)能力、實(shí)踐、文化價(jià)值的總稱(chēng)。
總體來(lái)說(shuō)，雖然無(wú)服務(wù)器平臺也許可以輕松滿(mǎn)足初始部署和縮放等需求，但依然無(wú)法完全省略基礎架構運維。
無(wú)服務(wù)器運維的內容是？
需要考慮的兩個(gè)重要事情：
首先，“運維”不僅僅意味著(zhù)服務(wù)器管理。它也意味著(zhù)監控、部署、安全、網(wǎng)絡(luò )、備份和還原，也意味著(zhù)一定的產(chǎn)品問(wèn)題診斷和系統規模擴展。這些問(wèn)題在無(wú)服務(wù)器應用中仍然存在，你依舊需要應對的策略。
其次，即使仍然發(fā)生系統管理的工作，你也僅僅是將它們外包給無(wú)服務(wù)器平臺而已。雖然服務(wù)供應商的Web用戶(hù)界面可以一種一次性的方式對這些內容進(jìn)行配置（哪怕直接使用默認值），但是生產(chǎn)應用可能需要通過(guò)更成熟的方法進(jìn)行配置管理，并需要能與應用程序代碼基中其他方面的管理任務(wù)相互集成。
Rafal Gancarz在Serverlessconf London 2016有關(guān)“企業(yè)領(lǐng)域的無(wú)服務(wù)器技術(shù)”講話(huà)中不僅用實(shí)例介紹了如何使用HashiCorp的Terraform提供諸如最小特權安全策略等配置管理，以及如何將Terraform內部的基礎架構配置作為函數代碼共享給相同的持續集成（CI）流程。他還分享了他以前曾使用一臺運行Kibana的服務(wù)器作為Elasticsearch、Logstash以及Kibana（ELK）棧的一部分。這也意味著(zhù)整個(gè)架構并非完全無(wú)服務(wù)器的。
與微服務(wù)更配
無(wú)服務(wù)器體系結構很適合搭配N(xiāo)anoService使用。如果說(shuō)微服務(wù)（MicroService）是為了提供相對小規模的業(yè)務(wù)能力，那么可以認為NanoService提供的是這種能力的碎片。例如，可以通過(guò)微服務(wù)代表為某個(gè)客戶(hù)執行所有CRUD操作所需的代碼，而NanoService可以代表客戶(hù)所要執行的每個(gè)操作：創(chuàng )建、讀取、更新，以及刪除。當觸發(fā)“創(chuàng )建帳戶(hù)”事件后，將通過(guò)AWSLambda函數的方式執行相應的NanoService。但這種時(shí)候很少使用NanoService這樣的稱(chēng)呼，大部分人更愿意將其稱(chēng)為微服務(wù)，或者就叫做“服務(wù)”。
在題為“什么比微服務(wù)更好？無(wú)服務(wù)器微服務(wù)”的網(wǎng)絡(luò )直播中，Alan Williams（Autodesk）、AshaChakrabarty（Amazon）和Alan Ho（Apigee）討論了一個(gè)無(wú)服務(wù)器微服務(wù)的架構。其中，該微服務(wù)的構建使用了AWSlambda 函數和運行在A(yíng)WS上的Apigee端點(diǎn)。
據Chakrabarty介紹，無(wú)服務(wù)器是一種相對比較新的架構風(fēng)格，其中的計算單元不是虛擬機，而是一個(gè)封裝了待執行代碼（事件觸發(fā)）的函數。Williams指出，無(wú)狀態(tài)計算模型的主要特點(diǎn)是：“代碼為主（codefocused）”、沒(méi)有需要管理的服務(wù)器、沒(méi)有需要配置和管理的EC2實(shí)例、無(wú)需人工擴展、沒(méi)有空閑資源、沒(méi)有SSH或RDP。
下圖簡(jiǎn)單地描述了一個(gè)由Autodesk實(shí)現的無(wú)服務(wù)器微服務(wù)的架構（點(diǎn)擊查看大圖）：
該微服務(wù)有多個(gè)入口點(diǎn)作為HTTP端點(diǎn)（由Apigee管理）暴露。用戶(hù)發(fā)起一個(gè)HTTP調用，并不知道其請求會(huì )由一個(gè)無(wú)服務(wù)器微服務(wù)提供服務(wù)。該服務(wù)由多個(gè)Python編寫(xiě)的lambda函數組成，這些函數之間通過(guò)AWSSNS異步通知進(jìn)行通信。Lambda函數是相互獨立的，可以使用不同的語(yǔ)言開(kāi)發(fā)，可以由不同的團隊維護。
由于lambda不是短期的，所以它們需要將狀態(tài)在某個(gè)地方持久化，其中一個(gè)選擇是使用DynamoDB表。這些表的訪(fǎng)問(wèn)通過(guò)IAM角色控制，并且僅限于那些需要對它們進(jìn)行讀/寫(xiě)訪(fǎng)問(wèn)的函數。這可以避免將不需要的數據暴露給某個(gè)lambda函數，如果存在安全漏洞的話(huà)，這還可以縮小微服務(wù)的攻擊面。Autodesk之所以選擇使用DynamoDB存儲狀態(tài)，是因為它簡(jiǎn)單，可以將數據作為JSON傳遞，不需要管理一個(gè)服務(wù)器實(shí)例，并且支持自動(dòng)向上擴展。
上圖底部的DynamoDB表（talr-taskstatus）將來(lái)自多個(gè)lambda函數的狀態(tài)持久化，并在表被修改時(shí)產(chǎn)生流式事件。這些事件由另一個(gè)lambda函數監控（talr-validator），它會(huì )在必要時(shí)采取行動(dòng)。
對于在A(yíng)WS上實(shí)現一個(gè)無(wú)服務(wù)器架構，Williams列舉了如下好處。
敏捷性：只需數周就可以實(shí)現。
不需要管理基礎設施，無(wú)需EC2或ELB實(shí)例，不需要打安全補丁。
開(kāi)發(fā)人員只需專(zhuān)注于他們編寫(xiě)的代碼。
通過(guò)無(wú)服務(wù)器框架管理代碼的能力。
成本。根據他們的經(jīng)驗，運行lambda解決方案的成本只是傳統云解決方案的一小部分（約1%）。由于不需要雇傭運維人員配置和監控EC2和ELB實(shí)例，所以成本還會(huì )進(jìn)一步降低。
Williams還提到，無(wú)服務(wù)器架構不適合運行長(cháng)期工作負載或者第三方應用程序。在那些情況下，他認為容器更合適。
和PaaS的“愛(ài)恨情仇”
一些人認為FaaS就是另一種形式的PaaS，但IntentMedia的工程副總裁MikeRoberts有自己的不同看法：
大部分PaaS應用無(wú)法針對每個(gè)請求啟動(dòng)和停止整個(gè)應用程序，而FaaS平臺生來(lái)就是為了實(shí)現這樣的目的?！璅aaS和PaaS在運維方面最大的差異在于縮放能力。對于大部分PaaS平臺，用戶(hù)依然需要考慮縮放，例如在使用Heroku時(shí)需要考慮到底需要運行幾個(gè)Dyno。但是對于FaaS應用，這種問(wèn)題完全是透明的。就算將PaaS應用設置為自動(dòng)縮放，依然無(wú)法在具體請求的層面上進(jìn)行縮放（除非提供非常具體的流量塑形配置文件），而FaaS應用在成本方面效益就高多了。
同樣，AWS的VP Adrian Cockcroft曾經(jīng)回答過(guò)“如果您的PaaS能夠高效地在20分鐘內啟動(dòng)運行半秒的實(shí)例，那么你可以稱(chēng)它為無(wú)服務(wù)器?！?/p>
Roberts并不認為大家都需要拋棄PaaS轉為擁抱FaaS，他列舉了幾個(gè)原因有：“工具以及API網(wǎng)關(guān)的完善程度可能是最大的問(wèn)題。此外PaaS中實(shí)施的12-FactorApps可能會(huì )使用應用內只讀緩存以?xún)?yōu)化性能，這種情況就不適合使用FaaS功能?！?/p>
聯(lián)系客服
