溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
原文地址：https://martinfowler.com/articles/serverless.html
作者：Martin Fowler, Mike Roberts
??到目前為止，我們一直試圖只定義和解釋無服務器架構的含義。現在我將討論這種設計和部署應用程序方法的一些優點和缺點。你絕對不應該在沒有充分考慮并權衡利弊的情況下使用無服務器架構。
??讓我們從彩虹和獨角獸的國度開始，看看無服務器架構的好處。
??在最簡單的情況下，無服務器架構是一個外包解決方案。它允許你花錢請人來管理服務器、數據庫，甚至你自己管理的應用程序邏輯。由于你使用了許多其他人也將使用的預定義服務，因此我們看到了規模效應的經濟性:因為一個供應商正在運行數千個非常類似的數據庫，所以你為托管數據庫支付的費用較低，。
??降低的成本給你帶來的收益來自兩個方面：第一個是基礎設施成本收益，它純粹來自于與他人共享基礎設施(如硬件、網絡)；第二個是人工成本收益，你可以花更少的時間在外包的無服務器系統上，而不是花在自己開發和托管的同等系統上。
??但是，這種好處與你從基礎設施服務(IaaS)或平臺服務(PaaS)中獲得的好處并沒有太大的不同。但是可以通過無服務器架構的BaaS和FaaS來擴展這一優勢。
??IaaS和PaaS的前提是服務器和操作系統管理可以商品化，而BaaS則是整個應用程序組件商品化的結果。
??身份驗證就是一個很好的例子。許多應用程序編寫自己的身份驗證功能，這些功能通常包括注冊、登錄、密碼管理和與其他身份驗證提供者的集成等功能。總的來說，這種邏輯在大多數應用程序中都非常相似，像Auth0這樣的服務已經被創建，它允許我們將已經構建好的身份驗證功能集成到應用程序中，而無需我們自己開發它。
??BaaS數據庫也是同樣道理，比如Firebase的數據庫服務。一些移動應用程序團隊發現，讓客戶端直接與服務器端數據庫通信是有意義的。BaaS數據庫刪除了大量的數據庫管理開銷，并且提供了對不同類型的用戶執行適當授權的機制，這與無服務器應用程序的模式相同。
??根據你的實際情況，這些想法可能會讓你感到不安(我們將在缺陷一節中討論)，但不可否認的是，許多成功的公司幾乎不用自己的服務器端代碼就能生產出令人信服的產品。
??無服務器FaaS的樂趣之一是——正如我在本文前面提到的——“水平縮放是完全自動的、有彈性的，并且由服務商管理。”最大的好處是，只需要為你需要的計算付錢。如在AWS Lambda中，取決于應用形態，可能只需要支付100毫秒的邊，界對你而言這很劃算。
??假設你正在運行一個服務器應用程序，該應用程序每分鐘只處理一個請求，處理每個請求需要50毫秒，則你在一個小時內的平均CPU使用率是0.1%。如果這個應用程序部署到自己的專用主機上，那么這是非常低效的。上千個類似的應用程序都可以共享一臺機器。
??無服務器FaaS解決了這種低效率，以更低的成本為你提供好處。在上面的示例應用程序中，你只需要為每分鐘所花費的100毫秒計算時間付錢，這是總時間的0.15%。
??這帶來了下面的連鎖效應：
??讓我們看另一個例子。假設你的流量配置文件非常繁忙——可能你的基本流量是每秒20個請求，但是每5分鐘你就會在10秒鐘內接收到每秒200個請求(是通常數量的10倍)。如果你不想希望在流量峰值階段減少響應時間，怎么解決這個問題？
??在傳統環境中，你可能需要將硬件總數增加10倍，以處理峰值，即使峰值的總持續時間占總機器正常運行時間的不到4%。在這里，自動縮放可能不是一個好的選擇，因為在新實例啟動時，服務器的新實例需要較長的啟動時間。
??然而對于無服務器FaaS，這就不是一個問題。如果你的流量分布是均勻的，那么你就不會有什么不同，你僅需要支付高峰期產生的額外計算能力。
??顯然，我在這里特意選擇了幾個例子，其中無服務器FaaS可以節省大量的成本。但重點是想說明，從縮放的角度來看，除非你有一個非常穩定的流量形態，并且始終充分利用你的服務器主機的全部能力，否則使用FaaS可以節省成本。
??關于FaaS成本還有一個更有趣的方面:對代碼進行性能優化不僅會提高應用程序的速度，而且還會直接降低運營成本，具體降低多少取決于供應商的收費的粒度。例如，假設一個應用程序最初需要一秒鐘來處理一個事件。如果通過代碼優化，這將減少到200ms，它(在AWS Lambda上)將立即看到在不更改任何基礎設施的情況下，計算成本節省了80%。
??在無服務器BaaS方面，很容易理解為什么操作管理比其他體系結構更簡單:支持更少的組件就等于更少的工作。
??盡管上一節中我們對縮放記憶猶新，但值得注意的是，FaaS的縮放功能不僅降低了計算成本，還減少了操作管理，因為縮放是自動的。
??如果你的縮放過程是手動的(例如，需要人為地向服務器數組添加和刪除實例)，那么使用FaaS你可以很高興地忽略這一點，并讓FaaS供應商為你擴展應用程序。
??即使你已經達到在非FaaS體系結構中使用自動縮放的程度，仍然需要安裝和維護。而FaaS不再需要這項工作。
??與部署整個服務器相比，打包和部署FaaS功能很簡單。你所做的就是將所有代碼打包成一個zip文件，然后上載它。沒有Puppet/Chef，沒有啟動/停止shell腳本，沒有是否在機器上部署一個或多個容器的決定。如果你剛剛起步，那么你甚至不需要打包任何東西——甚至可以在服務提供者的控制臺上編寫代碼(顯然，這并不推薦!)。
??這個過程不需要很長時間來描述，但是對于一些團隊來說，這個好處可能是絕對巨大的:一個完全無服務器的解決方案需要零系統管理。
??PaaS解決方案具有類似的部署優勢，但正如我們前面看到的，在比較PaaS和FaaS時，FaaS在伸縮性方面具有優勢。
??更簡單的運營管理是我們工程師所理解的好處，但這對我們的業務意味著什么呢?
??顯而易見的是成本:花費在操作上的時間越少，操作所需的人員就越少，正如已經描述的那樣。但在我看來，更重要的是上線時間。隨著我們的團隊和產品越來越傾向于精益和敏捷流程，我們希望不斷嘗試新事物并快速更新現有系統。雖然在持續交付的環境中進行簡單的重新部署可以快速迭代穩定的項目，但是擁有“快速部署”的能力允許我們嘗試平滑和低成本的新實驗。
??雖然成本效益是無服務器架構最容易顯現的改進，但上線時間的提前讓我最興奮。它可以使產品開發的思維模式持續不斷地試驗，這才是對軟件交付的真正革命。
??在過去的幾十年里，世界上數據中心的數量和規模都有了巨大的增長。使用物理資源來構建這些中心,相關的能源需求是如此之大，這會造成巨大的環境影響。
??一方面，云基礎設施可能已經幫助減少了這種影響，因為公司只能在絕對需要的時候“購買”更多的服務器，而不是提前很長時間提供所有可能需要的服務器。不過，也有人可能會說，如果很多服務器沒有進行足夠的容量管理，那么供應服務器的便捷性可能會讓情況變得更糟。
??無論我們使用的是自托管服務器、IaaS、還是PaaS基礎架構解決方案，我們仍然需要手工決策應用程序的容量，這些決策通常要持續數月或數年。通常，我們對管理能力持謹慎態度，這是正確的，但這導致過度供應，導致低效。使用無服務器的方法，不再自己計算容量——讓無服務器供應商提供的計算能力剛好滿足實時需求。供應商可以綜合他的客戶的共同需求做出容量計算。
??這種差異將提升跨數據中心的資源使用效率，因此與傳統的容量管理方法相比，可以減少環境影響。
??對于任何外包策略，都是將一些系統控制權交給第三方供應商。這種缺乏控制可能表現為系統停機、意外限制、成本更改、功能丟失、強制API升級等等。
??多租戶指多個不同客戶(或租戶)的軟件實例在同一臺機器上運行，且可能在同一托管應用程序中運行的情況，這是實現規模經濟效益的策略。服務供應商盡其所能讓客戶覺得他們是唯一使用他們系統的人，而通常優秀的服務供應商在這方面做得很好。但是，沒有一個完美的多租戶解決方案，有時會在安全性(一個客戶能夠看到另一個客戶的數據)、健壯性(一個客戶的軟件中的錯誤導致另一個客戶的軟件出現故障)和性能(一個高負載的客戶導致另一個客戶的速度變慢)方面存在問題。
??這些問題并非無服務器系統獨有——它們存在于使用多租戶的許多其他服務產品中。AWS Lambda現在已經足夠成熟，我們不希望看到它出現此類問題，但是你應該注意任何不太成熟服務(無論是來自AWS還是其他供應商)的此類問題。
??你從一個供應商拿到的任何無服務器特性都很可能由另一個供應商以不同方式實現。如果你想換供應商幾乎肯定需要更新你的操作工具(部署、監控、等等),可能需要改變代碼(例如,以滿足不同的 FaaS 接口),甚至可能需要改變設計或架構。
??即使能夠輕松地遷移生態系統的一部分，你也可能會受到另一個體系結構組件的更大影響。假設你正在使用AWS Lambda來響應AWS Kinesis消息總線上的事件，盡管AWS Lambda、谷歌云功能和Microsoft Azure功能之間的差異可能相對較小，但仍然無法將后兩個供應商實現直接連接到AWS的Kinesis流。這意味著，如果不遷移基礎設施的其它部分，就不可能將代碼從一個解決方案遷移到另一個解決方案。
??很多人都被這個想法嚇到了——如果今天選擇的云供應商明天需要更改，還需要做很多工作，那么的確體驗很差。因此，一些人采用“多云”方法，開發和操作應用程序的方式與實際使用的云供應商無關，但這通常比單云方法成本更高——因此，雖然供應商綁定是一個合理的問題，但我仍然建議選擇一個你滿意的供應商，并盡可能地利用它們的功能。
??采用無服務器方法會面臨大量安全問題。這里有一些需要考慮的事情：
??使用“完整的”BaaS體系結構，服務器端不編寫自定義邏輯——全部在客戶機中編寫。這對于你的第一個客戶端平臺來說可能很好，但是一旦你需要換一個平臺，你就需要重復實現該邏輯的一個子集，但在更傳統的體系結構中你不需要這樣的重復工作。例如，如果在這種系統中使用BaaS數據庫，那么你的所有客戶機應用程序(可能是web、原生iOS和原生Android)現在都需要能夠與供應商數據庫通信，并且需要了解如何從數據庫模式映射到應用程序邏輯。
??有了完整的BaaS體系結構，就沒有機會為優化服務器設計了。“后端到前端”模式的存在是為了在服務器中抽象出整個系統的某些底層知識，在某種程度上是為了讓客戶端在移動應用程序中能夠更快地執行操作，并使用更少的電池電量。這種模式不適用于完整的BaaS。
??對于完整的BaaS體系結構，存在另一缺點：在這種體系結構中，所有定制邏輯都位于客戶機中，并且只提供供應商提供的后端服務。緩解這兩種情況的一種方法是采用FaaS或其他類型的輕量級服務器端模式，并將某些邏輯轉移到服務器。
??之前說過：“當涉及到本地時，FaaS函數有很大的限制。狀態。. .你不應該假定一個函數的一次調用的狀態對同一函數的另一次調用是可用的。”。
??這種假設的原因是：對于FaaS，我們通常無法控制函數的主機容器何時啟動和停止。
??那么，如果不能將狀態保存在內存中，FaaS的狀態會如何變化呢?在許多情況下，使用快速NoSQL數據庫、進程外緩存(例如Redis)或外部對象/文件存儲(例如S3)獲取是一些選項。但是這些都比內存或機器上的持久性慢得多。你需要考慮應用程序是否適合這種情況。
??這方面的另一個問題是內存緩存。許多從外部存儲的大數據集讀取數據的應用程序會在內存中保留部分數據集的緩存。你可能正在從數據庫中的“引用數據”表讀取數據，并使用Ehcache之類的東西。或者，也可以從指定緩存頭的HTTP服務中讀取，在這種情況下，內存中的HTTP客戶機可以提供本地緩存。
??FaaS確實允許使用一些本地緩存，如果你的函數使用得足夠頻繁，這可能是有用的。例如，對于AWS Lambda，我們通常希望一個函數實例能夠存在幾個小時，每隔幾分鐘至少使用一次。這意味著可以使用Lambda提供的(可配置的)3gb RAM，或512mb本地“/tmp”空間，對于某些緩存，可能足夠了。否則，不再需要假定進程內緩存，并且需要使用Redis或Memcached之類的低延遲外部緩存。然而，這需要額外的工作，可能會非常慢。
??前面描述的缺點可能總是存在于無服務器環境中。這些問題的解決方案在改進，但畢竟是存在的。
??剩下的缺點完全歸結為目前的技術水平。隨著供應商和/或英雄社區的意愿和投資，這些都可以被消滅。事實上，自本文的第一個版本以來，這個列表已經縮小了。
??在我編寫本文的第一個版本時，AWS很少提供Lambda函數的配置方式。這個問題現在已經得到了解決，但是如果你使用的是一個不太成熟的平臺，那么它仍然是值得檢查的。
??下面的例子，說明為什么在處理FaaS時，“購者自慎”是一個關鍵短語。AWS Lambda限制在給定時間內可以運行的Lambda函數的并發執行次數。這個極限是1000;這意味著你可以在任何時候執行一千個函數實例。如果你需要超過這個標準，可能會遇到異常、排隊和/或一般的慢下來。
??這里的問題是：這個限制是跨整個AWS帳戶的。一些組織使用相同的AWS帳戶進行生產和測試。這意味著，如果你組織中的某地某人執行了一種新的負載測試，并開始嘗試執行1000個并發Lambda函數，將意外地關閉你的生產應用程序。
??即使使用不同的AWS帳戶進行生產和開發，一個過載的產品lambda(例如，處理來自客戶的批處理上傳)也可能導致獨立的受lambda支持的實時生產API變得無響應。
??Amazon在這里通過保留并發性提供了一些保護。保留并發性允許你限制Lambda函數的并發性，這樣它就不會破壞你帳戶的其他部分，同時確保無論帳戶中的其他函數在做什么，始終有可用的容量。但是，默認情況下不會為帳戶打開預留并發，因此需要小心管理。
??在本文前面我提到，如果AWS Lambda函數運行時間超過5分鐘，則會中止它們。這兩年來一直是這樣的，AWS也沒有表現出任何想要改變的跡象。
??我之前談到了冷啟動，并提到了關于這個主題的文章。隨著時間的推移，AWS已經改進了這一領域，但是仍然存在一些重大問題，特別是對于偶爾觸發的jvm實現函數和/或需要訪問VPC資源的函數。期待這方面將繼續改進。
??好了，這已經足夠去選擇AWS了。我相信其他供應商也有一些問題。
??單元測試無服務器應用程序非常簡單，原因我在前面已經討論過:編寫的任何代碼都“只是代碼”，而且在大多數情況下，不必使用一大堆定制庫或必須實現的接口。
??而另一方面，集成測試無服務器的應用程序是困難的。在BaaS世界中，你依賴外部提供的系統，而不是(例如)自己的數據庫。那么，集成測試也應該使用外部系統嗎?如果是，那么這些系統對測試場景有多大的適應性?你能輕易的丟棄狀態嗎?你的供應商能否為負載測試提供不同的計費策略?
??如果你想為集成測試打樁那些外部系統，供應商是否提供打樁模擬?如果是，樁的保真度如何?如果供應商不提供樁，你自己將如何實現打樁?
??同樣的問題也存在于FaaS領域，盡管這一領域已經有所改善。現在可以在本地為Lambda和Microsoft Azure運行FaaS函數。然而，沒有一個本地環境可以完全模擬云環境;我不建議完全依賴本地FaaS環境。事實上，我還想更進一步，建議你運行自動化集成測試的規范環境(至少作為部署管道的一部分)應該是云，并且你應該主要將本地測試環境用于交互式開發和調試。這些本地測試環境不斷改進。
??還記得我在前幾節提到的在云中運行集成測試時的跨帳戶執行限制嗎?你可能希望至少將這些測試與你的生產云帳戶隔離。
??考慮集成測試重要原因是，我們使用無服務器FaaS與其他架構相比，每個功能都要小得多，因此我們比與其他架構風格相比，更依賴集成測試。
??依賴基于云的測試環境，而不是在筆記本電腦上本地運行所有東西，這對我來說是一個相當大的沖擊。但時代在變，我們從云計算中獲得的能力與谷歌等公司的工程師們十多年來所擁有的類似。Amazon現在甚至允許你在云中運行IDE。我還沒有完全做到這一點——但它可能會到來。
??使用FaaS進行調試是一個有趣的領域。這里已經取得了一些進展，主要與本地運行FaaS函數有關。Microsoft為本地運行但由遠程事件觸發的函數提供了出色的調試支持。Amazon也提供類似的服務，但還沒有由生產事件觸發的機制。
??調試在云生產環境中實際運行的函數是另一回事，Lambda至少還不支持這種功能，不過如果能看到這種功能就太好了。
??這是一個正在積極改進的領域。AWS在改進這方面已經取得了巨大的進步，稍后我將在“無服務器架構的未來”一節中進一步討論它。
??“發現”是微服務世界中經常討論的主題:它是一個服務如何調用另一個服務的正確版本的問題。在無服務器的世界中，很少有關于發現的討論。起初這讓我擔心，但現在我不那么擔心了。許多無服務器的使用本質上是事件驅動的，在這里事件的使用者在某種程度上通常是自注冊的。對于面向API的FaaS用法，我們通常在API網關后面使用它們。在這種情況下，我們在API網關前面使用DNS，在網關后面使用自動部署/流量轉移。甚至可以在API網關前面使用更多的層(例如，使用AWS CloudFront)來支持跨區域彈性調度。
??由于容器的短暫性，對FaaS來說，監控是一個棘手的領域。大多數云供應商都提供了一定數量的監控支持，我們也看到了許多來自傳統監控廠商的第三方工作。不過，他們和你最終能做什么取決于供應商提供給你的基本數據。在某些情況下，這可能是好的，但是對于AWS Lambda，至少，它是非常基礎的。在這個領域，我們真正需要的是開放api和第三方服務提供更多的幫助能力。
??ThoughtWorks在其技術雷達出版物的一部分中，討論了過于強勢的API網關。雖然該鏈接一般指的是API網關(例如，對于那些傳統部署的微服務前端)，但它肯定可以作為HTTP前端到FaaS函數的API網關使用。問題是API網關提供了許多特定于應用程序的邏輯。這種邏輯通常很難測試、版本控制，有時還很難定義。通常，這種邏輯最好像應用程序的其他部分一樣保留在程序代碼中。
??如果我們將API網關視為BaaS，那么考慮它提供給我們的所有選項是否有價值，以便節省我們的工作。如果為每個請求使用API網關付費，而不是按CPU利用率付費，那么最大化地使用API網關的功能不是更劃算嗎?
??我的建議是明智地使用增強的API網關功能，并且只在它確實能夠長期節省工作時才這樣做。絕對不要使用不能在源代碼可控的配置文件或部署腳本中表達的API網關特性。
??在前面提到過，無服務器并不是“無運維”——從監控、體系結構伸縮、安全性和網絡的角度來看，還有很多工作要做。然而，在開始時很容易忽略這一點。這里的危險正在被一種虛假的安全感所迷惑。也許你已經啟動并運行了你的應用程序，但它卻意外地出現在了***新聞上，突然間你需要處理的流量是原來的10倍，哎呀!你一下懵逼了。
??解決辦法是培訓。使用無服務器系統的團隊需要盡早考慮運維活動，供應商和社區應該提供教學幫助他們理解這意味著什么。
??我們即將結束對無服務器架構世界的探索。最后，我將討論我認為無服務器世界可能在未來幾個月和幾年發展的幾個領域。
??無服務器仍然是一個相當新的世界。因此，上一節關于缺點的內容非常廣泛，甚至沒有涵蓋我所能想到的所有內容。無服務器的最重要發展將是減少固有的缺陷，并消除或改進實施缺陷。
??工具仍然是無服務器的一個問題，這是因為許多技術和技術都是新的。部署/應用程序綁定和配置在過去兩年中都得到了改進，其中無服務器框架和Amazon的無服務器應用程序模型處于領先地位。盡管亞馬遜和谷歌可以向微軟和Auth0尋求更多的靈感，但“前10分鐘”的體驗并沒有想象中那么神奇。
??我很高興看到云供應商積極解決的一個領域是更高級別的發布方法。在傳統系統中，團隊通常需要編寫自己的流程來處理藍綠部署和canary發布等“流量轉移”思想。考慮到這一點，Amazon支持Lambda和API網關的自動流量轉移。在無服務器的系統中，這樣的概念更有用，因為一次100個Lambda函數的系統原子版本構成了許多單獨部署的組件。事實上，Nat Pryce向我描述了一種“混合臺”的方法，在這種方法中，我們可以在一個業務流中逐漸將一組組件引入和退出。
??分布式監控可能是最需要改進的領域。我們已經從Amazon的 X-Ray和各種第三方產品中看到了早期的工作，但是這絕對不是一個已經解決的問題。遠程調試也是我希望看到更廣泛應用的東西。Microsoft Azure函數支持這一點，但Lambda不支持。能夠在遠程運行的函數打斷點是一種非常強大的功能。
??最后,我希望看到改善的工具更有效地“元操作”——管理成百上千的FaaS功能,配置服務等。
??對于許多應用程序來說，FaaS缺乏持久的服務器狀態是可以接受的，但是對于許多其他應用程序來說，這是一個致命的問題——無論是對于大型緩存集還是對會話狀態的快速訪問。
??對于高吞吐量應用程序，一個解決方案可能是供應商在事件之間讓函數實例存活更長一點，并使用常規的進程內緩存方法。由于緩存不會對每個事件都是熱的，所以這種方法不是100%有效的。對于使用傳統部署的自動伸縮應用程序來說，也存在同樣的問題。
??更好的解決方案是非常低延遲地訪問進程外數據，比如能夠以非常低的網絡開銷查詢Redis數據庫。考慮到Amazon已經在他們的Elasticache產品中提供了一個托管的Redis解決方案，而且他們已經允許使用放置組對EC2(服務器)實例進行相對定位，這看起來并不過分。
??但是，更有可能的是，我認為我們將看到不同種類的混合(無服務器和非服務器)應用程序架構被采用，以考慮狀態外部化約束。以低延遲應用程序為例,你可能會看到一個常用方法：常駐服務器處理一個初始請求,收集所有必要的上下文來處理該請求的本地和外部狀態, 然后將一個完全上下文化的請求傳遞給FaaS函數群,而不需要去外部查找數據。
??目前無服務器FaaS的某些缺點歸結為平臺的實現方式。執行持續時間、啟動延遲和跨功能限制是三個明顯的缺陷。這些問題可能會通過新的解決方案得到解決，也可能會有增加額外成本的變通辦法。例如，我認為可以通過允許客戶總是在低延遲情況下請求一個FaaS函數的兩個實例，用來減少啟動延遲，當然客戶需要為此支付費用。Microsoft Azure的功能具有這種理念的元素，它具有持久的功能，以及應用程序服務計劃托管的功能。
??當然，我們將看到平臺的改進，而不僅僅是修復當前的缺陷，這些改進也將令人興奮。
??通過培訓，許多特定于供應商的無服務器固有缺陷正在得到緩解。讓一個或多個應用程序供應商托管這么多生態系統意味著什么？每個使用此類平臺的人都需要積極思考。我們需要考慮這樣的問題，我們是否需要考慮“設計來自不同供應商的并行解決方案，以防其中一個不可用”和“在部分停機的情況下，應用程序如何優雅地降級?”這樣的問題。
??培訓的另一個領域是技術操作。許多團隊現在的系統管理員比以前少了，而無服務器架構將加速這一變化。但是系統管理員不只是配置Unix盒和Chef腳本—他們通常是支持、網絡、安全等方面的前線人員。
??在一個無服務器的世界中，真正的DevOps文化變得更加重要，因為那些非系統管理員活動仍然需要完成，而且現在通常是開發人員對它們負責。對于許多開發人員和技術領導來說，這些活動可能并不自然，因此培訓和與操作人員的密切協作是重要的。
??最后，關于如何緩解缺陷問題:供應商必須更加明確我們對他們平臺的期望，因為我們更多地依賴他們提供托管功能。雖然遷移平臺是困難的，但這并非不可能，不值得信任的供應商將看到他們的客戶將業務轉移到別處。
??我們對如何以及何時使用無服務器架構的理解還處于初級階段。現在，團隊正在把各種各樣的想法扔到無服務器的平臺上，看看哪些是有用的。感謝拓荒者!我們開始看到推薦實踐模式的出現，而這些知識只會越來越多。
??我們看到的一些在應用程序體系結構中模式：例如，在FaaS函數變得笨拙之前，它們可以變得多大?假設我們能夠自動地部署一組FaaS函數，那么創建這些組的好方法是什么?它們是否與我們當前將邏輯聚合到微服務中的方式密切相關，或者架構上的差異是否將我們推向了一個不同的方向?
??在無服務器應用程序體系結構中，一個特別有趣的活躍討論領域是它如何與事件思維交互。AWS Lambda的產品主管Ajay Nair在2017年對此做了一次精彩的演講，這也是CNCF無服務器工作組討論的主要領域之一。
??更進一步，在FaaS和傳統的“始終在線”持久服務器組件之間創建混合架構的好方法是什么?什么是將BaaS引入現有生態系統的好方法?相反，BaaS系統需要開始接受或使用更多自定義服務端代碼的警告信號是什么?
??我們還看到討論了更多的使用模式：FaaS的一個標準示例是媒體轉換，例如，每當將大型媒體文件存儲到S3存儲桶中時，就會自動運行一個進程，在另一個存儲桶中創建較小的版本。然而，我們現在也看到無服務器在數據處理管道、高度可伸縮的web api以及在操作中作為通用“粘合劑”代碼方面的重大應用。其中一些模式可以作為通用組件實現，直接部署到組織中;我曾經寫過關于Amazon的無服務器應用程序存儲庫的文章，它是這種思想的早期形式。
??最后，隨著工具的改進，我們開始看到推薦的操作模式。我們如何合理地為FaaS、BaaS和傳統服務器的混合架構聚合日志記錄?如何最有效地調試FaaS函數?這些問題的許多答案——以及正在出現的模式——都來自云供應商本身，我預計這一領域的活動將會增長。
??在寵物店的例子中,我們看到早些時候我給一個寵物店服務器分成幾個服務器端組件和一些邏輯轉移到客戶端,。但從根本上說，這仍然是一個以客戶端為中心的架構,并且遠程服務在已知位置。
??我們現在開始在無服務器世界中看到的是模糊的責任分配。一個例子是Amazon的Lambda@Edge產品:一種在Amazon CloudFront內容交付網絡中運行Lambda函數的方法。有了Lambda@Edge, Lambda函數就可以在全球范圍內分布——一個工程師的一次上傳活動就意味著該函數將被部署到全球100多個數據中心。
??此外，Lambda函數可以在設備上運行，機器學習模型可以在移動客戶端上運行，在你了解它之前，“客戶端”和“服務器端”的分叉似乎不再有意義。無服務器將變得無區域。
??到目前為止，我所看到的FaaS的大多數用法都是將現有的代碼和設計思想“FaaSification”(FaaS化):將它們轉換為一組無狀態函數。這非常強大，但我希望我們將開始看到更多的抽象，可能還有語言，使用FaaS作為底層實現，讓開發人員受益于FaaS，而不需要將其應用程序看作一組離散函數。
??例如，我不知道谷歌的Dataflow產品是否使用FaaS實現，但我可以想象有人創建了一個產品或開源項目，做類似的事情，并使用FaaS作為實現。這里的比較類似于Apache Spark。Spark是一個用于大規模數據處理的工具，它提供了非常高級的抽象，可以使用Amazon EMR和Hadoop作為其底層平臺。
??我認為在無服務器系統的集成和驗收測試方面還有很多工作要做，但是很多工作與以更傳統方式開發的“云原生”微服務系統相同。
??一個基本思想是在生產和監控驅動的開發中采用這樣的測試思想：一旦代碼通過了基本的單元測試驗證，就可以將其部署到一個業務子集，并與上一個版本比較。這可以與我前面提到的業務轉移工具相結合。這并不適用于所有的上下文，但是對于許多團隊來說，是一個非常有效的工具。
??團隊可以通過幾種方式使用無服務器，同時減少對特定云供應商的依賴。
??無服務器框架的存在主要是為了簡化無服務器應用程序的運維任務，但也提供了關于在何處以及如何部署此類應用程序的余地。例如，如果能夠根據每個平臺的運維能力輕松在AWS API網關+ Lambda和Auth0 webtask之間切換(即使是現在)，那將是非常棒的。
??其中一個棘手的方面是對抽象FaaS編碼接口建模，目前沒有標準化的指導，但是這正是關于CloudEvents的CNCF無服務器工作組的工作。
??但是，一旦運維的復雜性浮出水面，為多個平臺提供抽象部署有多少價值就值得懷疑了。例如，在一個云中獲得正確的安全性在另一個云中可能是不同的。
??建議我們在不使用第三方提供商的情況下使用無服務器技術，這聽起來可能有些奇怪，但請考慮以下想法:
??現在已經有了一個相當大的無服務器社區，它有多個會議、許多城市的聚會和各種在線群組。我預計這一趨勢還會繼續發展，可能會像Docker和Spring這樣的社區一樣。
??盡管名稱令人困惑，但無服務器是一種體系結構風格，在這種體系結構中，我們將自己的服務器端系統作為應用程序的一部分運行。通過兩種技術實現這一點:BaaS和FaaS，前者將第三方遠程應用程序服務緊密集成到應用程序的前端，后者將服務器端代碼從長時間運行的組件移動到短暫的函數實例。
??無服務器并不是解決每個問題的正確方法，所以要小心那些說它將取代你所有現有架構的人。如果你現在嘗試使用無服務器系統，請小心，特別是在FaaS領域。雖然有豐富的(可伸縮的和節省的部署工作)資源可以利用，但也有調試和監視的問題潛伏在角落中。
??但是，這些財富不應該很快就被拋棄，因為無服務器架構有許多積極的方面，包括降低操作和開發成本、更容易的操作管理和減少環境影響。但我認為最重要的好處是減少了創建新應用程序組件的反饋循環。我是“精益”方法的超級粉絲，主要是因為我認為將技術盡快呈現給終端用戶以獲得早期反饋是很有價值的，而無服務器產品上市時間的縮短正好符合這一理念。
??如今(2018年5月)，無服務器服務以及我們對它們的理解正處于“略顯笨拙的青春期”。在未來的幾年里，這個領域將會有很多的進步，看看無服務器如何適應我們的架構工具集將是一件很有趣的事情。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
