1.6　無服務時代

人們研究分布式架構，最初是因為單臺機器的性能無法滿足系統的運行需求，盡管在后來架構演進過程中，容錯能力、技術異構、職責劃分等各方面因素都成為架構需要考慮的問題，但獲得更好的性能在架構設計需求中依然占很大的比重。對軟件研發而言，不去做分布式無疑是最簡單的，如果單臺服務器的性能可以是無限的，那架構演進的結果肯定會與今天有很大差別，分布式也好，容器化也好，微服務也好，恐怕都未必會如期出現，最起碼一定不是今天這個樣子。

絕對意義上的無限性能必然是不存在的，但在云計算落地已有十余年的今天，相對意義的無限性能已經成為現實。

在工業界，2012年Iron.io公司率先提出了“無服務”（Serverless，應該翻譯為“無服務器”才合適，但現在稱“無服務”已形成習慣了）的概念；2014年，亞馬遜發布了名為Lambda的商業化無服務計算平臺，并在后續的幾年里逐步得到開發者認可，發展為目前世界上最大的無服務運行平臺；到了2018年，中國的阿里云、騰訊云等廠商也開始跟進，發布了旗下的無服務產品，“無服務”成為近期技術圈里的“新網紅”之一。

在學術界，2009年，云計算概念剛提出的早期，在加州大學伯克利分校曾發表的論文“Above the Clouds:A Berkeley View of Cloud Computing”[1]中預言的云計算的價值、演進和普及在接下來的十年里一一得到驗證。2019年，加州大學伯克利分校發表的第二篇有著相同命名風格的論文“Cloud Programming Simplified:A Berkeley View on Serverless Computing”[2]再次預言“無服務將會發展成為未來云計算的主要形式”。由此來看，“無服務”也同樣是被主流學術界所認可的發展方向之一。

額外知識

我們預測無服務將會發展成為未來云計算的主要形式。

——Cloud Programming Simplified:A Berkeley View on Serverless Computing,2019

無服務現在還沒有一個特別權威的“官方”定義，但它的概念并沒有前面提到的各種架構那么復雜，本來無服務也是以“簡單”為主要賣點的，它只涉及兩塊內容：后端設施（Backend）和函數（Function）。

·后端設施是指數據庫、消息隊列、日志、存儲等這類用于支撐業務邏輯運行，但本身無業務含義的技術組件，這些后端設施都運行在云中，在無服務中將它們稱為“后端即服務”（Backend as a Service，BaaS）。

·函數是指業務邏輯代碼，這里函數的概念與粒度都已經很接近于程序編碼角度的函數了，其區別是無服務中的函數運行在云端，不必考慮算力問題，也不必考慮容量規劃（從技術角度可以不考慮，從計費的角度還是要掂量一下的），在無服務中將其稱為“函數即服務”（Function as a Service，FaaS）。

無服務的愿景是讓開發者只需要純粹地關注業務：不需要考慮技術組件，后端的技術組件是現成的，可以直接取用，沒有采購、版權和選型的煩惱；不需要考慮如何部署，部署過程完全托管到云端，由云端自動完成；不需要考慮算力，有整個數據中心支撐，算力可以認為是無限的；不需要操心運維，維護系統持續平穩運行是云計算服務商的責任而不再是開發者的責任。在UC Berkeley的論文中，把無服務架構下開發者不再關心這些技術層面的細節，類比成當年軟件開發從匯編語言踏進高級語言的發展過程，開發者可以不去關注寄存器、信號、中斷等與機器底層相關的細節，從而令生產力得到極大解放。

無服務架構的遠期前景看起來是很美好的，但筆者自己對無服務架構短期內的發展并沒有那么樂觀。與單體架構、微服務架構不同，無服務架構有一些天生的特點決定了它現在不是，以后如果沒有重大變革的話，估計也很難成為一種普適性的架構模式。無服務架構確實能夠降低一些應用的開發和運維環節的成本，譬如不需要交互的離線大規模計算，又譬如多數Web資訊類網站、小程序、公共API服務、移動應用服務端等都契合于無服務架構所擅長的短鏈接、無狀態、適合事件驅動的交互形式。但另一方面，對于那些信息管理系統、網絡游戲等應用，或者說對于具有業務邏輯復雜、依賴服務端狀態、響應速度要求較高、需要長鏈接等特征的應用，至少目前是相對不那么適合的。這是因為無服務天生“無限算力”的假設決定了它必須要按使用量（函數運算的時間和占用的內存）計費以控制消耗的算力的規模，因而函數不會一直以活動狀態常駐服務器，請求到了才會開始運行，這就導致了函數不便依賴服務端狀態，也導致了函數會有冷啟動時間，響應的性能可能不太好。目前無服務的冷啟動過程大概是在數十到百毫秒級別，對于Java這類啟動性能差的應用，甚至是接近秒的級別。

無論如何，云計算畢竟是大勢所趨，今天信息系統建設的概念和觀點，在（較長尺度的）明天都是會轉變成適應云端的，筆者并不懷疑Serverless+API的設計方式會成為以后其中一種主流的軟件形式，屆時無服務還會有更廣闊的應用空間。

如果說微服務架構是分布式系統這條路當前所能做到的極致，那無服務架構，也許就是“不分布式”的云端系統這條路的起點。雖然在順序上筆者將“無服務”安排到了“微服務”和“云原生”時代之后，但它們并沒有繼承替代關系，強調這點是為了避免有讀者從兩者的名稱與安排的順序中產生“無服務就會比微服務更加先進”的錯誤想法。筆者相信軟件開發的未來不會只存在某一種“最先進的”架構風格，多種具有針對性的架構風格并存，是軟件產業更有生命力的形態。筆者同樣相信在軟件開發的未來，多種架構風格將會融合互補，“分布式”與“不分布式”的邊界將逐漸模糊，兩條路線將在云端的數據中心中交匯。今天已經能初步看見一些使用無服務的云函數去實現微服務架構的苗頭了，將無服務作為技術層面的架構，將微服務視為應用層面的架構，把它們組合起來使用是完全合理可行的。以后，無論是物理機、虛擬機、容器，抑或是無服務云函數，都會是微服務實現方案的候選項之一。

本節是架構演進歷史的最后一節，如本章引言所說，我們談歷史，重點不在考古，而是借歷史之名，理解每種架構出現的意義與淘汰的原因，為的是更好地解決今天的現實問題，尋找出未來架構演進的發展道路。

對于架構演進的未來發展，2014年，Martin Fowler與James Lewis在“Microservices”的結束語中曾寫到，他們對于微服務日后能否被大范圍推廣，最多只持有謹慎樂觀的態度。在無服務方興未艾的今天，與那時微服務的情況十分相近，筆者對無服務日后的推廣同樣持謹慎樂觀的態度。軟件開發的最大挑戰就在于只能在不完備的信息下決定當前要處理的問題。時至今日，依然很難預想在架構演進之路的前方，微服務和無服務之后還會出現何種形式的架構風格，但這也契合了圖靈的那句名言：盡管目光所及之處，只是不遠的前方，即使如此，依然可以看到那里有許多值得去完成的工作在等待我們。

額外知識

盡管目光所及之處，只是不遠的前方，即使如此，依然可以看到那里有許多值得去完成的工作在等待我們。

——Alan Turing，Computing Machinery and Intelligence，1950

[1] 論文地址：https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf。

[2] 論文地址：https://arxiv.org/abs/1902.03383。