之前看到的一篇關(guān)于Serverless以及Kubernetes的文章完残，很受啟發(fā)。文中介紹了從單體->SOA->微服務(wù)->云原生>serverless的架構(gòu)進(jìn)化過程盗痒，并闡述了當(dāng)前serverless的現(xiàn)狀以及未來的趨勢蚂蕴。篇幅稍長，但包含了大量對技術(shù)的思考俯邓，尤其是關(guān)于各種架構(gòu)的設(shè)計(jì)取舍權(quán)衡骡楼，值得認(rèn)真閱讀。一直沒發(fā)現(xiàn)中文版看成，于是自己進(jìn)行了翻譯君编。

原文：Kubernetes Workloads in the Serverless Era: Architecture, Platforms, and Trends，作者Bilgin Ibryam川慌，Red Hat的首席架構(gòu)師吃嘿。

關(guān)鍵要點(diǎn)

• 微服務(wù)架構(gòu)已演化為云原生架構(gòu)，而其中許多基礎(chǔ)設(shè)施功能已由Kubernetes以及服務(wù)網(wǎng)格（service mesh）和無服務(wù)器（serverless）框架提供梦重。
• Kubernetes的卓越之處在于其通過Pod抽象對新的工作負(fù)載提供了擴(kuò)展能力兑燥，這也支持了新的云原生應(yīng)用程序模式的出現(xiàn)。
• Kubernetes不僅支持無狀態(tài)應(yīng)用程序琴拧，而且還支持有狀態(tài)工作負(fù)載降瞳、單例、批處理作業(yè)、cron作業(yè)挣饥，甚至通過CRD和operator提供無服務(wù)器和自定義工作負(fù)載除师。
• 當(dāng)今的serverless平臺仍具有很大的局限性，使其無法被需要強(qiáng)大互操作和可移植能力的企業(yè)公司采用扔枫。
• 通過探索標(biāo)準(zhǔn)和開放的打包汛聚、運(yùn)行時和事件格式，serverless生態(tài)系統(tǒng)正在不斷發(fā)展短荐。這些領(lǐng)域的進(jìn)步正在模糊云原生和serverless工作負(fù)載之間的差異倚舀，并且已推動serverless產(chǎn)品變成開放、可移植忍宋、可互操作的框架痕貌。

Kubernetes中的工作負(fù)載（workload）是描述pod部署規(guī)則的一組對象，通過這些對象糠排，Kubernetes可以定義應(yīng)用的調(diào)度舵稠、擴(kuò)容以及升級等操作，具體包括Deployment乳讥、StatefulSet柱查、DeamonSet、Job云石、CronJob等唉工。

在預(yù)測serverless的發(fā)展方向和適用范圍之前，我們首先分析下如何以及為什么會到當(dāng)前這樣的一個時代汹忠。

單體架構(gòu)(Monolithic Architecture)

我在開始從事大型集成項(xiàng)目時淋硝，面向服務(wù)的體系結(jié)構(gòu)（SOA）是最受歡迎的體系架構(gòu)，而企業(yè)服務(wù)總線（ESB）是其最常見的實(shí)現(xiàn)宽菜。
SOA建立在良好的原則之上谣膳，這些原則大多數(shù)如今仍然有效：契約優(yōu)先開發(fā)，松耦合铅乡，可組合和無狀態(tài)的服務(wù)继谚，這些服務(wù)同時具有自治性和可重用性。
ESB框架提供了一組很好的能力阵幸，例如協(xié)議轉(zhuǎn)換花履、技術(shù)連接器、路由和編排機(jī)制挚赊、錯誤處理和高可用性原語诡壁。

分布式架構(gòu)的演進(jìn)

從架構(gòu)和組織的角度來看，SOA和ESB的主要問題是集中化荠割。SOA的重要原則是服務(wù)和組件的重用妹卿，這導(dǎo)致了分層服務(wù)架構(gòu)的創(chuàng)建，分層架構(gòu)實(shí)現(xiàn)了重用但卻導(dǎo)致了緊密的架構(gòu)服務(wù)耦合。在組織上夺克，ESB由一個團(tuán)隊(duì)擁有箕宙，這使得中間件變成可伸縮性、快速演進(jìn)（更重要）的技術(shù)與組織瓶頸铺纽。由少數(shù)人定義的復(fù)雜行業(yè)規(guī)范發(fā)展是緩慢的扒吁。

微服務(wù)架構(gòu)1.0

盡管SOA為解決企業(yè)級復(fù)雜性提供了良好的基礎(chǔ)，但技術(shù)發(fā)展迅速室囊。開源模式推動了更快的創(chuàng)新，并成為了新的技術(shù)發(fā)行和標(biāo)準(zhǔn)化機(jī)制魁索。

同時融撞，諸如XP、Scrum和看板之類的敏捷開發(fā)實(shí)踐產(chǎn)生了迭代的軟件開發(fā)粗蔚，但是這種方法與現(xiàn)有的單體架構(gòu)相沖突尝偎，后者無法應(yīng)對快速部署的增量設(shè)計(jì)。因此鹏控，實(shí)際情況是功能是經(jīng)過兩周的迭代開發(fā)的致扯，但每年僅部署一次或兩次。

微服務(wù)架構(gòu)的適時出現(xiàn)被看作是有望解決這些挑戰(zhàn)的靈丹妙藥（panacea ）当辐。微服務(wù)架構(gòu)憑借其指導(dǎo)原則抖僵，可以應(yīng)對更快的變化。服務(wù)圍繞業(yè)務(wù)領(lǐng)域建模缘揪，比可重用的SOA服務(wù)更有效地將更改封裝在服務(wù)內(nèi)耍群。自主且可獨(dú)立部署的服務(wù)允許每個服務(wù)以自己的步調(diào)演化和擴(kuò)展。

盡管這些新原則在快速迭代和實(shí)驗(yàn)（experimentation）時代優(yōu)化了SOA找筝，但它們也通過將每個應(yīng)用程序轉(zhuǎn)變?yōu)榉植际较到y(tǒng)而帶來了挑戰(zhàn)蹈垢。結(jié)果微服務(wù)還必須是高度可自動化的、高度可觀察的袖裕、容錯的曹抬，同時還需擁有分布式系統(tǒng)組件必需的所有其它功能。這個代價并不是每個人最初都意識到并做好準(zhǔn)備買單的急鳄。

微服務(wù)架構(gòu)作為技術(shù)答案誕生于快速迭代的開發(fā)和試驗(yàn)時代谤民，但是我們在古老的工具之上構(gòu)建了第一代微服務(wù)，這導(dǎo)致它們很難管理攒岛。在ESB時代赖临，業(yè)務(wù)邏輯泄漏到平臺中，導(dǎo)致各種耦合灾锯；而在微服務(wù)時早期時代兢榨，我們觀察到的正好相反：太多的基礎(chǔ)架構(gòu)問題泄漏到每個微服務(wù)中。早期的微服務(wù)有其自身的挑戰(zhàn)；他們必須自己進(jìn)行服務(wù)發(fā)現(xiàn)吵聪、配置管理凌那，網(wǎng)絡(luò)彈性、日志分發(fā)等吟逝。一個組織具備創(chuàng)建成十上百個新服務(wù)的能力帽蝶，并不一定意味著已做好準(zhǔn)備將這些服務(wù)統(tǒng)一管理和部署到生產(chǎn)中。發(fā)布块攒、管理以及向運(yùn)營團(tuán)隊(duì)移交的流程和支持工具必須進(jìn)行改進(jìn)励稳，所有這些將我們推向了Kubernetes時代。

云原生架構(gòu)（又名微服務(wù)2.0）

微服務(wù)架構(gòu)改進(jìn)了SOA以應(yīng)對快速變化囱井，但其實(shí)是拿代碼復(fù)雜性交換成了運(yùn)維復(fù)雜性驹尼。它面臨的挑戰(zhàn)導(dǎo)致了容器的流行，容器一夜之間接管了整個行業(yè)庞呕。容器的出現(xiàn)是為了解決如何統(tǒng)一部署大量微服務(wù)并有效地踐行DevOps新翎。通過容器，我們可以一種開發(fā)和運(yùn)營團(tuán)隊(duì)都理解和使用的格式打包并運(yùn)行應(yīng)用程序住练。很早以前就很清楚地啰，管理數(shù)十或數(shù)百個容器將需要自動化，而Kubernetes彷佛如來神掌讲逛，從天而降亏吝，橫掃所有競爭對手。Kubernetes解決了技術(shù)挑戰(zhàn)盏混，DevOps實(shí)踐解決了微服務(wù)的文化方面顺呕。

這是新轉(zhuǎn)變的開始，基礎(chǔ)架構(gòu)職責(zé)從應(yīng)用層轉(zhuǎn)移到平臺層括饶。云原生平臺（最初是很多株茶，但最終主要是Kubernetes）提供的功能包括資源隔離和管理、自動放置（automated placement）图焰、聲明式部署启盛，健康檢查、自我修復(fù)技羔、配置管理僵闯、服務(wù)發(fā)現(xiàn)、自動擴(kuò)展等藤滥。這些功能使應(yīng)用開發(fā)人員可以專注于業(yè)務(wù)邏輯鳖粟，并使用開箱即用的平臺功能來統(tǒng)一解決基礎(chǔ)架構(gòu)問題。

當(dāng)時拙绊，我將流行的微服務(wù) 1.0工具（Spring Cloud和Netflix OSS）與微服務(wù)2.0工具（以Kubernetes作為事實(shí)上的標(biāo)準(zhǔn)）進(jìn)行了比較向图，并收到了讀者的不同意見泳秀。如今，它已被更廣泛理解和接受榄攀，這一點(diǎn)轉(zhuǎn)變也被最終證實(shí)：Kubernetes作為微服務(wù)管理平臺的完全統(tǒng)治地位以及對較早一代的許多Netflix OSS庫的棄用嗜傅。

但是，所有這些都是歷史檩赢，我們來探索Kubernetes的未來吕嘀。

Kubernetes的光彩（brilliance）

Kubernetes架構(gòu)有許多迷人的元素：容器提供了通用的打包機(jī)制、運(yùn)行時和資源隔離模型贞瞒；簡單的控制循環(huán)（control-loop ）機(jī)制用于監(jiān)視組件的實(shí)際狀態(tài)并將其與所需狀態(tài)保持一致（調(diào)諧reconcile）偶房、自定義資源。但是擴(kuò)展Kubernetes支持各種工作負(fù)載的真正推動力是Pod的概念军浆。

一個pod提供兩組保證：

1. 部署保證可確保將pod內(nèi)的容器始終放置在同一節(jié)點(diǎn)上蝴悉。此行為具有一些有用的屬性，例如允許容器通過localhost瘾敢、進(jìn)程間通信（IPC）或使用本地文件系統(tǒng)同步或異步通信。
2. 生命周期保證可確保將pod中的容器實(shí)際分為兩組進(jìn)行管理：初始化容器和應(yīng)用程序容器尿这。初始化容器首先運(yùn)行簇抵；它們一個接一個地運(yùn)行，并且僅在先前的容器已成功完成時才運(yùn)行射众。初始化容器啟用順序的管道行為碟摆，并用單個容器執(zhí)行每個步驟。另一方面叨橱，應(yīng)用容器并行運(yùn)行典蜕，沒有任何順序保證。這組容器使流行的邊車（sidercar）模式能夠擴(kuò)展和增強(qiáng)具有正交功能的已有容器的功能罗洗。

Pod的部署和生命周期保證

可擴(kuò)展的控制循環(huán)(control-loop)機(jī)制與通用的pod特性相結(jié)合愉舔，使Kubernetes能夠處理各種工作負(fù)載，包括serverless伙菜。讓我們看下這些不同的工作負(fù)載轩缤，看看每種工作負(fù)載都適合哪種用例。

云原生工作負(fù)載

要證明Kubernetes是一個能夠支持各種工作負(fù)載和用例的通用平臺贩绕，需要探索不同的工作負(fù)載類型及其需求火的。

有狀態(tài)的服務(wù)

讓我們從最不令人興奮的工作負(fù)載（workload）開始，但它幾乎總是存在于企業(yè)環(huán)境中：有狀態(tài)服務(wù)淑倾。通過將狀態(tài)轉(zhuǎn)移到外部數(shù)據(jù)存儲中馏鹤，可以將具有業(yè)務(wù)邏輯的狀態(tài)服務(wù)轉(zhuǎn)換為可伸縮的無狀態(tài)服務(wù)。這樣的設(shè)計(jì)將約束從業(yè)務(wù)服務(wù)移至數(shù)據(jù)源娇哆，這些數(shù)據(jù)源成為架構(gòu)中的有狀態(tài)組件湃累。這些數(shù)據(jù)存儲通常是現(xiàn)成的關(guān)系數(shù)據(jù)庫勃救、分布式緩存、鍵值存儲脱茉、搜索索引等剪芥。在動態(tài)的云基礎(chǔ)設(shè)施上管理分布式有狀態(tài)組件需要一些保證，例如：

• 持久化存儲--狀態(tài)通常位于磁盤上琴许，而分布式有狀態(tài)應(yīng)用程序需要每個實(shí)例專用的持久存儲來存儲其狀態(tài)税肪。
• 穩(wěn)定的網(wǎng)絡(luò)ID--與存儲要求類似，分布式有狀態(tài)應(yīng)用程序需要穩(wěn)定的網(wǎng)絡(luò)身份榜田。有狀態(tài)應(yīng)用程序除了在存儲空間中存放應(yīng)用特定的數(shù)據(jù)外益兄，還存放配置詳細(xì)信息，例如交互主機(jī)名和連接詳細(xì)信息箭券。這意味著每個實(shí)例都應(yīng)該通過一個可預(yù)測的净捅、不會動態(tài)更改的地址訪問，就像在ReplicaSet中的pod IP地址一樣辩块。
• 穩(wěn)定的身份標(biāo)識 --從前面的要求中可以看出蛔六，有狀態(tài)應(yīng)用程序集群在很大程度上依賴于每個實(shí)例保持其持久（long-lived）存儲和網(wǎng)絡(luò)標(biāo)識。這是因?yàn)樵谟袪顟B(tài)應(yīng)用程序中废亭，每個實(shí)例都是唯一的国章，并且知道其自己的身份標(biāo)識，該標(biāo)識的主要構(gòu)成就是持久存儲和網(wǎng)絡(luò)坐標(biāo)豆村。在此列表中液兽，我們還可以添加實(shí)例的身份/名稱（某些有狀態(tài)應(yīng)用程序也需要唯一的永久名稱），在Kubernetes中將其作為Pod名稱掌动。
• 普通性--除了唯一且長期存在的身份標(biāo)識外四啰，集群化有狀態(tài)應(yīng)用程序的每個實(shí)例也具有一個固定位置（這個位置是相對于其它重要實(shí)例的）。這種排列通常會影響實(shí)例按比例縮放的順序粗恢，但它也可以用作一致性哈希算法、數(shù)據(jù)分發(fā)和訪問以及集群內(nèi)行為歸置（in-cluster behaviors placement ）（例如鎖敦迄，單例或主服務(wù)器）的基礎(chǔ)凭迹。

Kubernetes上的分布式有狀態(tài)應(yīng)用程序

這些正是Kubernetes StatefulSet提供的保證罚屋。一個StatefulSet提供了用于管理具有狀態(tài)特征的Pod的通用原語（primitives）脾猛。除了典型的ZooKeeper、Redis和Hazelcast的部署依賴StatefulSet鱼鸠，其他用例還包括消息代理甚至事務(wù)管理器羹铅。

例如职员，Narayana事務(wù)管理器用來StatefulSet確保在縮減服務(wù)期間使用分布式事務(wù)不會丟失任何JTA日志焊切。在縮小集群消息代理時芳室，Apache Artemis消息代理依賴StatefulSet消費(fèi)完消息堪侯。StatefulSet是一個功能強(qiáng)大的通用的抽象伍宦，復(fù)雜的狀態(tài)使用的情況下非常有用次洼。

全局單例

來自“ 四人幫 ”（Gang of Four）的單例模式是一個古老且易于理解的概念滓玖。在分布式质蕉、云原生世界中模暗，對應(yīng)的是單例組件（整個服務(wù)或其中的一部分）的概念兑宇，該組件是全局單例（在所有分布式服務(wù)中），但仍具有很高的可用性瓷产。這種工作負(fù)載類型的用例通常源于我們必須與之交互的其它系統(tǒng)的技術(shù)約束濒旦，例如尔邓，一次僅允許單個客戶端訪問的API梯嗽、數(shù)據(jù)源和文件系統(tǒng)灯节。另一個用例是必須保留消息的順序性，于是將其消費(fèi)者服務(wù)限制為單例贷岸。Kubernetes有一些支持這些用例的選項(xiàng)偿警。

最簡單的選擇是依靠Kubernetes運(yùn)行服務(wù)的單個實(shí)例螟蒸。我們可以通過使用一個ReplicaSet或StatefulSet七嫌，設(shè)置replicas=1輕松實(shí)現(xiàn)這一目標(biāo)诵原。兩種選擇之間的區(qū)別在于绍赛，你是需要強(qiáng)一致性的單例（保證至多一個）吗蚌，還是弱一致性單例（保證至少一個）蚯妇。一個ReplicaSet更看重可用性并優(yōu)先保持單個實(shí)例可用（“至少一個”語義）箩言，這有時可能會導(dǎo)致多個實(shí)例同時運(yùn)行分扎，例如當(dāng)某個節(jié)點(diǎn)與集群斷開連接畏吓，但ReplicaSet不確認(rèn)此節(jié)點(diǎn)Pod已停止時又啟動另一個節(jié)點(diǎn)上Pod菲饼。一個StatefulSet優(yōu)先考慮一致性而不是可用性宏悦，并提供“至多一個”語義饼煞。如果某個節(jié)點(diǎn)與集群斷開連接砖瞧，它將無法在運(yùn)行正常的節(jié)點(diǎn)上啟動Pod块促。只有在運(yùn)維人員確認(rèn)斷開連接的節(jié)點(diǎn)或pod真正關(guān)閉后竭翠，才能重新啟動Pod斋扰。有時這可能會導(dǎo)致服務(wù)停機(jī)传货，但絕不會導(dǎo)致同時運(yùn)行多個實(shí)例损离。

還有一種選擇可以從應(yīng)用程序內(nèi)部實(shí)現(xiàn)自我管理的單例僻澎。在前面的方案中窟勃，應(yīng)用程序并不知道會被當(dāng)作一個單例來管理秉氧，而自我管理的單例則確保僅激活了一個組件汁咏，而與啟動的服務(wù)實(shí)例（pods）數(shù)量無關(guān)攘滩。這種單例機(jī)制依賴特定運(yùn)行時的實(shí)現(xiàn)來獲取鎖并充當(dāng)單例漂问，但是它具有一些優(yōu)點(diǎn)蚤假。首先磷仰，不存在意外配置錯誤的危險(xiǎn)芒划，并且增加副本數(shù)仍然能保證任何給定時間只有一個組件處于活動狀態(tài)民逼。其次拼苍，它允許擴(kuò)展服務(wù)同時能夠確保服務(wù)service的部分功能（例如端點(diǎn)）的單例行為疮鲫。當(dāng)由于特定操作或端點(diǎn)的外部技術(shù)限制俊犯，微服務(wù)的局部而不是整個必須是單例時燕侠，這很有用绢彤。此用例的示例實(shí)現(xiàn)是Apache Camel的Kubernetes連接器的單例功能械巡，該連接器可以使用Kubernetes ConfigMap作為分布式密鑰讥耗，并且僅激活Kubernetes中部署的多個Camel服務(wù)中的單個Camel使用者古程。

Kubernetes上的單例工作負(fù)載

單例是數(shù)量較少的另一種工作負(fù)載類型籍琳，但是它們也很常見趋急。單例和高可用性是兩個相互沖突的需求呜达，但是Kubernetes足夠靈活眉踱，可以在可接受的折衷方案中同時提供這兩個谈喳。

批處理作業(yè)

批處理作業(yè)適用于管理那些處理孤立原子工作單元的工作負(fù)載婿禽。在Kubernetes原語中扭倾，它是作為job抽象實(shí)現(xiàn)的膛壹，它可以在分布式環(huán)境上通過可靠地運(yùn)行臨時pod完成模聋。

Kubernetes上的批處理和周期性工作負(fù)載

從生命周期的角度來看此改，批處理工作負(fù)載具有與異步serverless工作負(fù)載相似的特征，因?yàn)樗鼈儗Ｗ⒂趩蝹€操作暂题，并且壽命很短薪者，持續(xù)到任務(wù)完成即可言津。但是悬槽，盡管基于job的工作負(fù)載本質(zhì)上是異步的，但它們不會從客戶那里直接獲取輸入信息磅叛，也不會直接響應(yīng)客戶請求弊琴。它們通常知道從何處檢索輸入數(shù)據(jù)以及在何處寫入結(jié)果访雪。如果作業(yè)具有時間維度（即已計(jì)劃）臣缀，則將定期由時間事件觸發(fā)執(zhí)行精置。

無狀態(tài)工作負(fù)載（又名12要素應(yīng)用程序）

無狀態(tài)工作負(fù)載是Kubernetes上使用最廣泛的工作負(fù)載類型。這是使用ReplicaSet在Kubernetes上管理的典型的12要素應(yīng)用程序或基于微服務(wù)的系統(tǒng)赖阻。通常火欧，一個ReplicaSet將管理此類服務(wù)的多個實(shí)例苇侵，并將使用不同的自動縮放策略來水平和垂直地縮放此類工作負(fù)載于未。

Kubernetes上的支持服務(wù)發(fā)現(xiàn)的無狀態(tài)工作負(fù)載

由ReplicaSet管理的服務(wù)的常見要求是服務(wù)發(fā)現(xiàn)和負(fù)載平衡烘浦。在這里谎倔，Kubernetes提供了多種開箱即用的選項(xiàng)。

Kubernetes的服務(wù)發(fā)現(xiàn)機(jī)制

這里的要點(diǎn)是藕咏，即使有多種服務(wù)發(fā)現(xiàn)機(jī)制可以動態(tài)檢測健康和不健康的Pod實(shí)例，但不同的服務(wù)類型本質(zhì)上都是相對靜態(tài)的盲再。 Kubernetes service原語不提供動態(tài)流量監(jiān)控和轉(zhuǎn)移的能力答朋。這是服務(wù)網(wǎng)格（service mesh）粉墨登場的原因梦碗。

服務(wù)網(wǎng)格（service mesh）

構(gòu)建基于微服務(wù)的系統(tǒng)時面臨的挑戰(zhàn)之一是創(chuàng)建不屬于業(yè)務(wù)邏輯的商品特性敷搪，例如彈性通信、跟蹤念赶、監(jiān)視等晶乔。此邏輯曾經(jīng)位于中央ESB層正罢，現(xiàn)在必須重復(fù)分散在微服務(wù)的智能客戶端之間。服務(wù)網(wǎng)格技術(shù)旨在通過提供額外增強(qiáng)的網(wǎng)絡(luò)功能來解決此問題裆泳，例如：

• 流量路由—A / B測試工禾，分階段回滾闻葵。
• 彈性—重試，斷路器厢钧，連接限制早直，運(yùn)行狀況檢查。
• 安全性—身份驗(yàn)證祥得、授權(quán)级及、加密（mTLS）怕吴。
• 可觀察性—指標(biāo)转绷，跟蹤议经。
• 測試—故障注入，流量鏡像籍救。
• 平臺獨(dú)立性—多種語言蝙昙，允許運(yùn)行時配置。
  如果我們仔細(xì)研究這些功能大刊，會注意到集成框架提供的功能存在大量重疊缺菌。

服務(wù)網(wǎng)格和集成框架職責(zé)重疊

將所有這些職責(zé)移到服務(wù)之外是否是一個好的方法，存在不同的意見焊傅。盡管網(wǎng)絡(luò)職責(zé)已從應(yīng)用層轉(zhuǎn)移到通用的云原生平臺中，但并非所有網(wǎng)絡(luò)職責(zé)都移出了應(yīng)用程序：

• 服務(wù)網(wǎng)格適用于基于連接的流量路由握巢，而服務(wù)內(nèi)部的集成框架則適用于基于內(nèi)容的路由溅话。
• 服務(wù)網(wǎng)格可以進(jìn)行協(xié)議轉(zhuǎn)換飞几，而集成框架可以進(jìn)行內(nèi)容轉(zhuǎn)換。
• 服務(wù)網(wǎng)格可以進(jìn)行灰度發(fā)布绪钥，而集成框架可以進(jìn)行監(jiān)控（wire-tapping）。
• 服務(wù)網(wǎng)格進(jìn)行基于連接的加密，而集成框架可以進(jìn)行內(nèi)容加密社痛。

某些需求可以在服務(wù)中更好地處理蒜哀，而某些需求可以使用服務(wù)網(wǎng)格從外部更好地處理。還有一些必須在兩層都進(jìn)行處理：可以從服務(wù)網(wǎng)格層配置連接超時淀歇，但是仍然必需在服務(wù)內(nèi)部設(shè)置連接超時匈织。對于其它行為浪默，例如通過重試和任何其它錯誤處理邏輯進(jìn)行恢復(fù)也是如此。服務(wù)網(wǎng)格缀匕、Kubernetes和其他云服務(wù)是當(dāng)今的工具纳决，但是對應(yīng)用程序的端到端可靠性和正確性的最終責(zé)任在于服務(wù)實(shí)現(xiàn)及其開發(fā)和設(shè)計(jì)團(tuán)隊(duì)。這不會改變乡小。

服務(wù)網(wǎng)格技術(shù)進(jìn)一步強(qiáng)調(diào)了第一代和第二代微服務(wù)之間的主要區(qū)別：將某些操作職責(zé)轉(zhuǎn)移到平臺上。Kubernetes將部署職責(zé)轉(zhuǎn)移到平臺劲件，而服務(wù)網(wǎng)格將網(wǎng)絡(luò)職責(zé)轉(zhuǎn)移到平臺掸哑。但這還不是最終狀態(tài)约急。這些變化只是為serverless世界鋪平了道路，在serverless世界中苗分，部署和基于流量的即時可伸縮性是前提厌蔽。

Serverless(無服務(wù)器)概念

一切都與視角有關(guān)

為了討論serverless的特性，我將使用 Cloud Native Computing Foundation（CNCF）的serverless工作組的定義 摔癣，因?yàn)樗窃S多不同軟件供應(yīng)商之間最廣泛認(rèn)可的定義之一：

無服務(wù)器計(jì)算(serverless computing)是指構(gòu)建和運(yùn)行不需要服務(wù)器管理的應(yīng)用程序的概念奴饮。它描述了一種更細(xì)粒度的部署模型，該模型中應(yīng)用程序被封裝為一個或多個功能择浊，然后上傳到平臺戴卜，按需進(jìn)行執(zhí)行、擴(kuò)容以及計(jì)費(fèi)琢岩。

如果從開發(fā)人員可從serverless平臺獲益這個角度理解將這種定義投剥，我們可將serverless總結(jié)為這樣一種架構(gòu)：該架構(gòu)可實(shí)現(xiàn)“按需運(yùn)行更細(xì)粒度的功能同時無需管理服務(wù)器”。通常我們都是從開發(fā)人員的角度考慮serverless担孔，但還有另一個很少討論的角度江锨。每個無服務(wù)器平臺都有提供者來管理平臺和服務(wù)器：他們必須管理粗粒度計(jì)算單元，并且無論需求如何糕篇，其平臺都會產(chǎn)生24x7的成本啄育。這些提供商是AWS Lambda，Azure Functions和Google Cloud Functions背后的團(tuán)隊(duì)拌消，或者你公司中管理Apache OpenWhisk挑豌，使用Knative的Kubernetes或其他功能的團(tuán)隊(duì)。在這些場景下墩崩，提供商可以使開發(fā)人員可以將計(jì)算和存儲作為沒有任何服務(wù)器概念的工作負(fù)載類型使用氓英。根據(jù)組織和業(yè)務(wù)因素，提供商可以是同一組織中的另一個團(tuán)隊(duì)/部門（想象一個使用AWS Lambda來滿足其需求的Amazon團(tuán)隊(duì)）泰鸡，也可以是另一個組織（當(dāng)AWS客戶使用Lambda和其他服務(wù)時）债蓝。無論提供商與消費(fèi)者之間的業(yè)務(wù)安排如何，消費(fèi)者都不會對服務(wù)器負(fù)責(zé)盛龄，需要負(fù)責(zé)的是提供者饰迹。

Serverless(無服務(wù)器)架構(gòu)

上面的定義僅指“無服務(wù)器計(jì)算”。但是余舶，應(yīng)用程序的架構(gòu)是由計(jì)算和數(shù)據(jù)組合而成的啊鸭。無服務(wù)器架構(gòu)的更完整定義是既包含無服務(wù)器計(jì)算又包含無服務(wù)器數(shù)據(jù)。典型情況是匿值，此類應(yīng)用程序?qū)⒓稍仆泄芊?wù)來管理狀態(tài)和通用服務(wù)器端邏輯赠制，例如身份驗(yàn)證、API網(wǎng)關(guān)、監(jiān)視钟些、告警烟号、日志記錄等。我們通常將這些托管服務(wù)稱為“后端即服務(wù)” （BaaS）–考慮諸如DynamoDB政恍，SQS汪拥，SNS，API網(wǎng)關(guān)篙耗，CloudWatch等服務(wù)迫筑。事后看來，用術(shù)語“服務(wù)化（而非“無服務(wù)器”）或許可以更精確地描述所這種架構(gòu)宗弯。但是并不是所有的東西都可以用第三方服務(wù)代替脯燃；如果是這種情況，并且有一個業(yè)務(wù)邏輯的服務(wù)蒙保，那么你就沒法開展生意了（也就是有些服務(wù)總歸是要自己開發(fā)的）辕棚！因此，無服務(wù)器架構(gòu)通常還具有“功能/函數(shù)即服務(wù)”（FaaS）組件追他，這些組件允許執(zhí)行由事件觸發(fā)的自定義無狀態(tài)計(jì)算坟募。當(dāng)下最受歡迎的示例是AWS Lambda岛蚤。

完整的無服務(wù)器架構(gòu)由BaaS和FaaS組成邑狸，從消費(fèi)者/開發(fā)人員的角度來看，沒有服務(wù)器的概念涤妒。沒有要管理或配置的服務(wù)器還意味著基于消耗的定價（并不是配置的容量）单雾，內(nèi)置的自動擴(kuò)展（可到一個限制），內(nèi)置的高可用和容錯能力她紫，內(nèi)置的修補(bǔ)程序和安全強(qiáng)化（帶有內(nèi)置支持策略限制）硅堆，監(jiān)視和日志記錄（作為額外的付費(fèi)服務(wù)）等。所有這些都由無服務(wù)器的開發(fā)人員使用贿讹，并由無服務(wù)器的提供程序提供渐逃。

Pure Serverless（純粹無服務(wù)器）

如果無服務(wù)器架構(gòu)聽起來不錯，為什么不擁有一個純粹的無服務(wù)器架構(gòu)---其中所有組件都100％無服務(wù)器并且沒有服務(wù)器概念民褂？這個問題可以引用艾倫·厄爾曼（Ellen Ullman）的話來解釋其原因：“我們以建立城市的方式來構(gòu)建計(jì)算機(jī)系統(tǒng)：隨著時間推移茄菊，沒有計(jì)劃，建立廢墟之上赊堪∶嬷常” 企業(yè)系統(tǒng)就像一座古老的城市，通常它已經(jīng)存在了十多年哭廉，這就是它的價值和重要性所在脊僚，這就是使其成為“企業(yè)”的原因。想象一下倫敦遵绰，這座已經(jīng)存在了2000多年的城市辽幌，擁有百年歷史的地鐵系統(tǒng)增淹，狹窄的街道、宮殿乌企、維多利亞時代的社區(qū)和供水系統(tǒng)埠通；如此復(fù)雜的系統(tǒng)永遠(yuǎn)無法被新系統(tǒng)完全取代，它總是會進(jìn)行恢復(fù)和更新（重構(gòu)逛犹，升級端辱，遷移，并在IT方面重新平臺化）虽画。在這樣的系統(tǒng)中舞蔽，變化的狀態(tài)是常態(tài)，新舊混合存在的狀態(tài)是常態(tài)码撰。這些系統(tǒng)應(yīng)該是這樣存在的渗柿。

Serverless1.0

容器技術(shù)已經(jīng)以多種形式存在了很多年，但是Docker對其進(jìn)行了普及脖岛，而Kubernetes使它成為部署的規(guī)范朵栖。同樣，無服務(wù)器技術(shù)已經(jīng)存在了很多年柴梆，但是AWS Lambda使其變得流行陨溅，我們還沒有看到誰將其帶入一個新的高度。

Serverless 1.0基本上是由AWS定義的绍在，并由FaaS組件的AWS Lambda代表门扇，以及BaaS組件的其他AWS服務(wù)（例如API Gateway，SQS偿渡，SNS等）代表臼寄。基于AWS（定義趨勢）以及Google和Azure（正努力追趕）溜宽，這里列舉了當(dāng)前這代無服務(wù)器的一些特征吉拳，這些特征不理想并且是待改進(jìn)的。

非確定性執(zhí)行模型具有：

• 不可預(yù)測的容器生命周期以及對冷啟動有影響的重用語義适揉；
• 對編程模型的約束留攒，這會影響代碼初始化邏輯，導(dǎo)致回調(diào)泄漏涡扼，產(chǎn)生附加的遞歸調(diào)用成本等稼跳；
• 不可預(yù)測的資源生命周期，例如/ tmp文件存儲吃沪；
• 內(nèi)存汤善、超時、有效負(fù)載、程序包红淡、臨時文件系統(tǒng)和環(huán)境變量的強(qiáng)行限制不狮；
• 整個行業(yè)中的總體的、非標(biāo)準(zhǔn)化執(zhí)行模型在旱，其非標(biāo)準(zhǔn)化約束會影響特定無服務(wù)器供應(yīng)商的編程模型摇零。

受限的運(yùn)行時支持意味著：

• 無服務(wù)器軟件棧包含操作系統(tǒng)、語言運(yùn)行時和庫版本桶蝎，這些都局限于OS驻仅，JDK和應(yīng)用程序庫（例如AWS開發(fā)工具包）的一個特定版本。
• 平臺支持策略通常規(guī)定在什么條件下可以棄用和更新任何無服務(wù)器堆棧組件 登渣，從而迫使所有serverless用戶按照嚴(yán)格的時間步調(diào)升級噪服。
• 編程API可能會導(dǎo)致問題。盡管我使用AWS SDK開發(fā)服務(wù)方面有一個好的體驗(yàn)胜茧，但我不喜歡所有功能都必須與com.amazonaws.services.lambda.runtime包及其編程模型緊密結(jié)合粘优。
• 我們使用非標(biāo)準(zhǔn)包裝。將.zip呻顽，uber-JAR或lib目錄與自定義AWS特定的分層和依賴關(guān)系模型一起使用雹顺，并不能使我確信該打包程序可以用于將來，以及在其它無服務(wù)器平臺上運(yùn)行廊遍。
  自定義環(huán)境變量（以AWS_開頭）在其他無服務(wù)器平臺上不起作用嬉愧。

專有數(shù)據(jù)格式

專有數(shù)據(jù)格式是一個障礙。事件是serverless體系結(jié)構(gòu)中函數(shù)（function）的主要連接機(jī)制昧碉。它們將每個function與其他function和BaaS連接起來英染。它們實(shí)際上是function的API和數(shù)據(jù)格式揽惹。在所有函數(shù)中使用com.amazonaws.services.lambda.runtime.events包中定義的事件可根本無法保證互操作性被饿。

缺少Java支持

盡管有適用于AWS Lambda的Java運(yùn)行時，但Java與Lambda之間存在如此不匹配的地方搪搏，甚至AWS都不推薦這樣做狭握。在Tim Bray的“ Inside AWS：現(xiàn)代應(yīng)用程序的技術(shù)選擇”演講中，他建議改為使用Go和Python疯溺。我希望沒有服務(wù)器的提供商能夠做得更好论颅，并改善其運(yùn)行時，而不是試圖對數(shù)百萬的Java開發(fā)人員進(jìn)行重新教育并改變數(shù)以百萬計(jì)的Java庫的生態(tài)系統(tǒng)囱嫩。Java已經(jīng)和Go一樣輕巧和快速（甚至更好）恃疯，因此使用這種語言構(gòu)建Serverless是難以避免的。

可能的影響

綜上所述墨闲，不確定性和非標(biāo)準(zhǔn)化執(zhí)行模型今妄，專有運(yùn)行時，專有數(shù)據(jù)格式，專有API以及缺少Java支持的結(jié)合意味著所有這些問題都會滲透到應(yīng)用程序代碼中盾鳞，并影響我們實(shí)現(xiàn)業(yè)務(wù)邏輯的方式犬性。這是從一個組織到另一個組織的最終控制權(quán)的下放。由于當(dāng)今serverless提供了構(gòu)建時的構(gòu)件腾仅，并提供了運(yùn)行時環(huán)境（以SDK乒裆、打包格式，事件格式和軟件堆棧的形式）推励，因此使用者會遵循支持策略和提供商所施加的專有限制鹤耍。使用者承諾堅(jiān)持并遵守提供者的語言運(yùn)行時，SDK验辞，升級和棄用惰蜜。他們通過編寫在無服務(wù)器平臺之間具有零互操作性的函數(shù)來遵守這些條款。如果我們使用BaaS進(jìn)行所有操作受神，并且我們剛剛將以function編寫的組織業(yè)務(wù)邏輯與專有執(zhí)行模型抛猖、運(yùn)行時、API和數(shù)據(jù)格式相結(jié)合鼻听，那么我們將無處可去财著。盡管我們可能不想走到其他任何地方，但對于某些人來說撑碴，擁有選擇權(quán)很重要撑教。

耦合和鎖定本身并不壞，但是遷移成本很高醉拓。使用AWS AMI伟姐，AWS RDS，流行的開源項(xiàng)目作為托管服務(wù)亿卤，甚至使用SQS都是例子愤兵，他們不介意被鎖定，因?yàn)檫w移到替代服務(wù)或提供商是可行的選擇排吴。這與將業(yè)務(wù)邏輯與不成熟的serverless技術(shù)和serverless提供商特征相結(jié)合是不同的秆乳。在這里，遷移工作需要對業(yè)務(wù)邏輯和粘合代碼的完整重寫和測試钻哩，考慮到無服務(wù)器體系結(jié)構(gòu)的高度分布式特性屹堰，這特別昂貴。

微服務(wù)是將用代碼復(fù)雜性與操作復(fù)雜性進(jìn)行了交換街氢。serverless是用控制權(quán)換來了速度扯键。選擇現(xiàn)代化架構(gòu)，但請閱讀小字體附加條款（原文：read the small print珊肃，意思是指要注意這些架構(gòu)潛在的一些附加特性）荣刑。每個架構(gòu)選擇都是一個權(quán)衡扣泊。

Serverless1.5

AWS將serverless技術(shù)帶到當(dāng)前現(xiàn)狀已做得非常出色，但是如果serverless技術(shù)的當(dāng)前狀態(tài)是其最高程度嘶摊，那將是令人遺憾的延蟹。如果只有AWS能在serverless領(lǐng)域內(nèi)進(jìn)行創(chuàng)新并定義其未來，那也將是可悲的叶堆≮迤考慮到AWS在開源生態(tài)系統(tǒng)中的資歷相對有限，期望AWS標(biāo)準(zhǔn)化serverless模式將是一個難題虱颗，進(jìn)而在整個基礎(chǔ)層面上影響整個行業(yè)沥匈。AWS業(yè)務(wù)模型和市場位置非常適合識別市場趨勢和最初的封閉式創(chuàng)新，而開源模式則更適合于泛化忘渔、標(biāo)準(zhǔn)化和被行業(yè)范圍內(nèi)的自愿接受高帖。我希望下一代serveless將使用開源模型創(chuàng)建，并在整個行業(yè)中進(jìn)行更廣泛的協(xié)作畦粮，這將有助于其被采用和提高互操作能力散址。這個過程已經(jīng)開始，并且業(yè)界正在緩慢地探索當(dāng)今專有serverless產(chǎn)品的可互操作和可移植的替代方案宣赔。

讓我們討論一些行業(yè)趨勢（不分先后順序）预麸，我相信這些趨勢將驅(qū)動并影響未來的serverless技術(shù)。

統(tǒng)一的打包和執(zhí)行模型

容器被成為應(yīng)用程序打包和運(yùn)行時的行業(yè)標(biāo)準(zhǔn)儒将。如前所述吏祸，容器化應(yīng)用程序與功能強(qiáng)大的編排引擎相結(jié)合可支持豐富的工作負(fù)載。serverless工作負(fù)載沒有理由是例外钩蚊，因?yàn)檫@會使我們回到打包格式和執(zhí)行模型的混合狀態(tài)贡翘。Knative是一個開放的、多家供應(yīng)商的共同努力的一個成果砰逻，它通過向Kubernetes上基于容器的工作負(fù)載提供無服務(wù)器特性（縮放至零鸣驱，基于HTTP請求自動縮放、訂閱诱渤、交付丐巫、綁定和事件管理）來挑戰(zhàn)現(xiàn)狀∩酌溃基于容器的打包和基于Kubernetes的執(zhí)行將允許一個開放的執(zhí)行模型，該模型可以在多個無服務(wù)器提供商之間進(jìn)行標(biāo)準(zhǔn)化碑韵。它通過對Java赡茸、自定義軟件堆棧，限制和自定義可能性更好支持來實(shí)現(xiàn)一組更豐富的運(yùn)行時祝闻。

有人可能會爭辯說占卧，按照serverless的原始定義遗菠，在函數(shù)包中包括語言運(yùn)行時和事件處理程序不是FaaS而是實(shí)現(xiàn)細(xì)節(jié)，而這是未來serverless一個急需的選擇华蜒。

行業(yè)公認(rèn)的事件格式

Serverless架構(gòu)的定義就是事件驅(qū)動的辙纬，事件扮演著中心角色。在Serverless環(huán)境中叭喜，事件類型越多贺拣，開發(fā)人員的經(jīng)驗(yàn)越豐富，可用現(xiàn)成服務(wù)替換的邏輯就越多捂蕴。但是譬涡，隨著業(yè)務(wù)邏輯與事件格式和結(jié)構(gòu)的結(jié)合，將需付出一定的代價啥辨。盡管您可以閱讀將核心業(yè)務(wù)邏輯和事件處理邏輯分離為單獨(dú)方法的AWS最佳實(shí)踐涡匀，但這遠(yuǎn)沒有解耦。業(yè)務(wù)邏輯與serverless平臺的數(shù)據(jù)格式的這種耦合阻止了互操作性溉知。 CloudEvents致力于創(chuàng)建可在所有無服務(wù)器平臺上運(yùn)行的標(biāo)準(zhǔn)化事件格式陨瘩。這是一個很棒的想法，業(yè)內(nèi)很多企業(yè)包括 AWS 都對其產(chǎn)生了濃厚的興趣 级乍，這可能是對其重要性和采用潛力的最終驗(yàn)證拾酝。

可移植性和互操作性

一旦有了標(biāo)準(zhǔn)的打包格式和標(biāo)準(zhǔn)事件，下一個程度的自由就是能在公共或私有云卡者、本地或邊緣上的serverless提供商上運(yùn)行serverless工作負(fù)載蒿囤，并按需將所有內(nèi)容搭配并匹配到一個混合環(huán)境中。function應(yīng)可在多云崇决，混合云材诽，任何云，非云或混合云上運(yùn)行恒傻，并且只需要少量配置和映射脸侥。就像我們以前編寫Java應(yīng)用程序以實(shí)現(xiàn)抽象接口并將其部署到不同的Web容器一樣，我希望能夠?yàn)榉菍Ｓ蠥PI盈厘，事件和編程模型編寫函數(shù)睁枕，并將其部署到任何無服務(wù)器的環(huán)境中平臺，并使其以可預(yù)測和確定性的方式運(yùn)行沸手。

除了可移植性之外外遇，我還希望看到互操作性，該函數(shù)能夠從任何平臺消費(fèi)事件契吉，而無論該函數(shù)在何處運(yùn)行跳仿。諸如KEDA之類的 項(xiàng)目使我們可以運(yùn)行自定義函數(shù)（如Azure Functions），以響應(yīng)AWS捐晶，Azure和其他事件觸發(fā)器菲语。TriggerMesh等項(xiàng)目 使我們能夠在Kubernetes 和OpenShift之上部署與AWS Lambda兼容的function 妄辩。這些跡象表明，未來的function將在多個級別上具有可移植性和互操作性：打包山上、執(zhí)行環(huán)境眼耀、事件格式、事件源佩憾、工具等哮伟。

將Java視為一等公民

盡管serverless工作負(fù)載適用于許多用例，但阻止使用Java（企業(yè)最流行的編程語言）是一個主要限制鸯屿。得益于Substrate VM 和Quarkus等框架 澈吨，Java已經(jīng)輕巧，快速寄摆，云原生且serverless友好谅辣。而且有跡象表明 ，這種Java運(yùn)行時很快也將可用于serverless婶恼，包括AWS Lambda桑阶，希望是這樣。

容器化工作負(fù)載具有serverless特性勾邦、function可移植性蚣录、具有標(biāo)準(zhǔn)化事件的互操作性、為云原生和serverless環(huán)境創(chuàng)建的超輕眷篇、快速Java運(yùn)行時萎河，這些都是serverless即將改變的信號。我還不想將這些特征叫做“第二代無服務(wù)器”蕉饼，但它不是第1代無服務(wù)器虐杯，感覺1.5會更合適。

我記得當(dāng)許多人以為Cloud Foundry贏得了PaaS戰(zhàn)爭時昧港，卻出現(xiàn)了Kubernetes∏嬉現(xiàn)在，許多人聲稱AWS Lambda贏得了FaaS戰(zhàn)爭创肥。我希望Kubernetes（或更好的東西）證明他們是錯誤的达舒。

Serverless工作負(fù)載

我們看到了微服務(wù)架構(gòu)如何通過圍繞業(yè)務(wù)域?qū)Ψ?wù)進(jìn)行建模，并通過將變更封裝在服務(wù)中來改善單片應(yīng)用程序的部署周期叹侄。serverless的一個簡單的描述是：更小的微服務(wù)巩搏，每個操作都是一個function。盡管從技術(shù)上講這是可能的圈膏，但這在兩種架構(gòu)中都是最糟糕的塔猾，導(dǎo)致大量function以同步方式相互調(diào)用，不能從最終架構(gòu)中獲得任何好處稽坤。

微服務(wù)的價值來自以下事實(shí)：它可以使用基于Web的API（通常為REST風(fēng)格）將復(fù)雜的業(yè)務(wù)域邏輯和持久性邏輯封裝在一系列“請求/響應(yīng)”方式的操作之后丈甸。另一方面，serverless和function專注于事件和觸發(fā)器尿褪。雖然可以將function放在API網(wǎng)關(guān)后面并以“請求/響應(yīng)”方式運(yùn)行睦擂，但該API并不是主要接口：事件和觸發(fā)器才是。當(dāng)應(yīng)用程序是異步的（單向即發(fā)即棄（fire-and-forget)）方式杖玲，而不是“請求/響應(yīng)”方式）并且通過隊(duì)列或其他數(shù)據(jù)和事件源進(jìn)行連接時顿仇，serverless應(yīng)用程序往往會運(yùn)行得更好。結(jié)果摆马，每個函數(shù)僅打算執(zhí)行一個操作臼闻，并且應(yīng)避免直接直接調(diào)用其他function，然后將結(jié)果寫入事件存儲囤采。這種執(zhí)行模型下述呐，function的生命周期很短，應(yīng)該與其他非面向連接的無服務(wù)器數(shù)據(jù)源一起使用（RDBMS是典型面向連接得）蕉毯，部署規(guī)模較小乓搬，并且啟動迅速。以下所有用例使serverless更加適合代虾，因?yàn)樗洚?dāng)連接各種事件驅(qū)動系統(tǒng)的粘合代碼：

• 按需function进肯，例如批處理，流處理和提取轉(zhuǎn)換加載（ETL）棉磨；
• 短期執(zhí)行的可分割工作的任務(wù)調(diào)度江掩，例如批處理工作；
• 事件驅(qū)動架構(gòu)乘瓤，可響應(yīng)數(shù)據(jù)源更改執(zhí)行邏輯环形；
• 處理非均勻流量，例如不經(jīng)常發(fā)生的不一致流量或負(fù)載不可預(yù)測的負(fù)載馅扣；
• 操作中的通用“膠水”代碼斟赚；
• 用于構(gòu)建作業(yè)，具有按需資源的持續(xù)集成流水線差油；
• 自動化操作任務(wù)拗军，例如觸發(fā)操作或在事件發(fā)生時通知值班人員。

我討論了serverless世界中正在發(fā)生的一些重大創(chuàng)新蓄喇，但沒有描述它們運(yùn)行在Kubernetes上是什么樣发侵。許多努力試圖將serverless帶入Kubernetes，但是擁有最廣泛的行業(yè)支持和成功機(jī)會的項(xiàng)目是Knative妆偏。Knative的主要目標(biāo)是為常見的serverless用例提供具有更高層次抽象的集中API刃鳄。它仍然是一個年輕的項(xiàng)目（撰寫本文時為0.5版），并且變化很快钱骂。讓我們探討一下Knative當(dāng)前支持的serverless工作負(fù)載叔锐。

Knative 包括3個關(guān)鍵組件：1. build（構(gòu)建）你的應(yīng)用程序挪鹏；2. 為其提供流量 serving（服務(wù)）；3. 確保應(yīng)用程序能夠輕松地生產(chǎn)和消費(fèi) event（事件）愉烙，原文中只提到了后兩種讨盒。

Request Serving

從微服務(wù)到無服務(wù)器的低摩擦（low-friction，指的是改造困難更小步责、更容易）過渡方法是使用單操作function來處理HTTP請求耕漱。我們希望serverless平臺能夠在幾秒鐘內(nèi)拉起（stand up）一個無狀態(tài)骡送、可擴(kuò)展的function--這就是 Knative Serving旨在通過為serverless工作負(fù)載提供通用工具包和API框架來實(shí)現(xiàn)的贴唇。在這種情況下丽柿，serverless工作負(fù)載是一個單一容器的無狀態(tài)Pod，主要由應(yīng)用層（L7）請求流量驅(qū)動蔗包。

Knative Serving項(xiàng)目提供了原語秉扑，可實(shí)現(xiàn)以下功能：

• 通過提供更高層次的、有思想的原語气忠，快速部署無服務(wù)器容器邻储；
• 激活，根據(jù)請求將其放大和縮小到零旧噪；
• 自動路由和配置低級原語吨娜；
• 版本的不變快照（已部署的代碼和配置）。

以上所有內(nèi)容均可在某些限制內(nèi)實(shí)現(xiàn)淘钟，例如每個pod一個容器宦赠、單個端口，無持久化以及其他一些限制米母。

Eventing

Knative Eventing項(xiàng)目提供了創(chuàng)建可靠勾扭、可擴(kuò)展、異步事件驅(qū)動型應(yīng)用程序的構(gòu)建塊（building blocks）铁瞒。它旨在使用CloudEvents標(biāo)準(zhǔn)圍繞事件的消耗和創(chuàng)建創(chuàng)建標(biāo)準(zhǔn)的體驗(yàn)妙色。Knative Eventing的高級功能包括：

• 可擴(kuò)展和可插拔的體系結(jié)構(gòu)，允許不同的導(dǎo)入程序（例如GitHub慧耍，Kafka身辨，SQS，Apache Camel等）和渠道（例如Kafka芍碧，Google Pub / Sub煌珊，NATS，內(nèi)存中等）泌豆；
• 事件注冊表定庵，用于維護(hù)事件類型的目錄；
• 通過綁定事件源，觸發(fā)器和服務(wù)來進(jìn)行事件編排的聲明性API蔬浙；
• 觸發(fā)器功能猪落，允許在將事件路由到下游Knative服務(wù)之前從特定broker訂閱事件并進(jìn)行可選的過濾。

這些功能很有趣敛滋，但是它們?nèi)绾螏椭圃_發(fā)人員在Kubernetes上提高生產(chǎn)力许布？

假設(shè)我們已經(jīng)實(shí)現(xiàn)了一個function兴革，將其構(gòu)建為容器绎晃，并對其進(jìn)行了全面測試。它基本上是一個只包含單個操作的服務(wù)杂曲，該服務(wù)通過HTTP接受CloudEvents庶艾。使用Knative ，我們可以將容器作為具有serverless特征的工作負(fù)載部署到Kubernetes擎勘。例如咱揍，使用Knative Serving原語，容器只能在接受HTTP請求時激活棚饵，并在必要時迅速擴(kuò)展煤裙。此外，還可以將同一pod進(jìn)行配置噪漾，通過訂閱渠道（channel）來接受來自代理（broker）的CloudEvent硼砰。該pod還可以充當(dāng)通過Knative Sequence定義的更復(fù)雜的事件編排流程中的步驟。僅使用聲明性Knative配置欣硼，而無需修改已構(gòu)建的容器题翰，所有這些都是可能的。Knative將確保serverless基礎(chǔ)架構(gòu)的路由诈胜、激活豹障、可伸縮性、可靠性焦匈、訂閱血公、重新交付和代理彈性。這些還沒有全部實(shí)現(xiàn)缓熟，但是正在進(jìn)行中累魔。

自定義工作負(fù)載

這還不是全部。如果您的應(yīng)用程序具有非常特殊的需求荚虚，而標(biāo)準(zhǔn)工作負(fù)載原語都無法滿足您的需求薛夜，那么Kubernetes可以提供更多選項(xiàng)。在這種情況下版述，自定義控制器（Custom Controller）可以通過主動監(jiān)視并將Kubernetes資源集保持到所需狀態(tài)梯澜，來向集群的行為添加定制功能。

從更高層次看，控制器（controller ）是一個執(zhí)行“觀察->分析->操作”步驟的主動調(diào)諧(reconciliation )過程晚伙。它監(jiān)視所需對象的所需狀態(tài)吮龄，并將其與現(xiàn)實(shí)中實(shí)際狀態(tài)進(jìn)行比較。然后咆疗，該過程發(fā)送指令嘗試將現(xiàn)實(shí)中當(dāng)前狀態(tài)修改的更接近所需狀態(tài)漓帚。

處理自定義工作負(fù)載的一種更高級的方法是利用另一個優(yōu)秀的Kubernetes擴(kuò)展機(jī)制：CustomResourceDefinitions。將Kubernetes Operator與CustomResourceDefinitions組合在一起可以將“專有算法”形式的特定應(yīng)用程序的操作知識封裝起來午磁。一個Operator就是一個了解Kubernetes和應(yīng)用領(lǐng)域的Kubernetes控制器--通過結(jié)合這兩個方面的知識尝抖，它可以自動執(zhí)行通常需要人工操作的任務(wù)。

Controller和Operator正在轉(zhuǎn)變?yōu)橛糜跀U(kuò)展平臺迅皇、在Kubernetes上實(shí)現(xiàn)復(fù)雜的應(yīng)用生命周期的標(biāo)準(zhǔn)機(jī)制昧辽。結(jié)果，形成了一個用于管理更復(fù)雜的云原生工作負(fù)載的整個生命周期的控制器生態(tài)系統(tǒng)登颓。

Operator模式允許我們擴(kuò)展Controller模式搅荞，以獲得更大的靈活性和更高的表達(dá)能力。我最近與人合著的Kubernetes模式一書涵蓋了本文討論的所有工作負(fù)載類型以及其它相關(guān)模式框咙。請查看有關(guān)這些主題的更多詳細(xì)信息咕痛。

云原生趨勢

在Kubernetes生態(tài)系統(tǒng)中，將越來越多的不屬于業(yè)務(wù)邏輯的商品功能遷移到平臺層的趨勢仍然在延續(xù)：

• 部署喇嘱、放置（placement）茉贡、健康檢查、恢復(fù)婉称、擴(kuò)展块仆，服務(wù)發(fā)現(xiàn)和配置管理已全部移至Kubernetes層。
• 服務(wù)網(wǎng)格通過將與網(wǎng)絡(luò)相關(guān)的職責(zé)（例如彈性通信王暗，跟蹤悔据，監(jiān)視，傳輸級安全性和流量管理）轉(zhuǎn)移到平臺來延續(xù)這種趨勢俗壹。
• Knative添加了專用的serverless原語科汗，并將快速擴(kuò)容、縮容绷雏、路由头滔、事件基礎(chǔ)設(shè)施抽象、事件發(fā)布涎显、訂閱機(jī)制以及工作流等責(zé)任也移到了平臺上坤检。

剩下的主要是業(yè)務(wù)邏輯問題由應(yīng)用程序開發(fā)人員實(shí)施。平臺負(fù)責(zé)其余的工作期吓。

職責(zé)轉(zhuǎn)移到平臺上早歇，更多抽象支持多種工作負(fù)載

通過向Kubernetes添加更高級別的抽象，我們將越來越多的商品職責(zé)從應(yīng)用程序?qū)愚D(zhuǎn)移到平臺上。例如箭跳，Istio在較低級Kubernetes原語的基礎(chǔ)上提供了更高級網(wǎng)絡(luò)抽象晨另。Knative添加了更高級別的serverless抽象，這些抽象依賴于Kubernetes和Istio的更低層抽象（請注意這將改變--Knative將不再依賴Istio谱姓，盡管它需要實(shí)現(xiàn)類似的功能）借尿。

這些額外的抽象使Kuberntetes能夠以相同的、開放的打包和運(yùn)行時格式統(tǒng)一支持各種工作負(fù)載屉来，包括serverless路翻。

運(yùn)行時和應(yīng)用程序設(shè)計(jì)

隨著從單體架構(gòu)到微服務(wù)和serverless的過渡，運(yùn)行時也在不斷發(fā)展奶躯。如此之多帚桩，以至于已有20年歷史的Java運(yùn)行時也逐漸擺脫了“一次編寫，到處運(yùn)行”的口號嘹黔，從而成為原生、輕量莫瞬、快速和serverless的先行者儡蔓。

Java運(yùn)行時和應(yīng)用程序設(shè)計(jì)趨勢

多年來，摩爾定律和不斷增強(qiáng)的計(jì)算能力引導(dǎo)Java使用最先進(jìn)的垃圾收集器疼邀，JIT編譯器和許多其他工具喂江，成為最先進(jìn)的運(yùn)行時之一。摩爾定律的終結(jié)導(dǎo)致Java引入了受益于多處理器和多核系統(tǒng)的非阻塞原語和庫旁振。本著同樣的精神获询，隨著諸如云原生和serverless之類的平臺趨勢，分布式系統(tǒng)組件變得輕巧拐袜、快速且針對單個任務(wù)進(jìn)行了優(yōu)化吉嚣。

Serverless

Serverless范式被認(rèn)為是下一個基礎(chǔ)架構(gòu)的進(jìn)化。但是蹬铺，當(dāng)前的serverless時代產(chǎn)生在早期采用者和顛覆者中尝哆，他們的優(yōu)先級是速度。但這不是具有復(fù)雜業(yè)務(wù)和技術(shù)約束的企業(yè)公司的優(yōu)先考慮事項(xiàng)甜攀。在這些組織中秋泄，行業(yè)標(biāo)準(zhǔn)是容器編排。Kubernetes正在通過Knative計(jì)劃嘗試將云原生和serverless鏈接起來规阀。其他項(xiàng)目恒序，例如CloudEvents和Substrate VM，也正在影響serverless生態(tài)系統(tǒng)谁撼，并將其推向一個開放歧胁、具備可移植性、互操作性、混合云和全球采用的時代与帆。

對于一些大眾所知的技術(shù)專業(yè)詞匯了赌，考慮到翻譯成中文反而覺得陌生引起歧義，因此進(jìn)行保留玄糟。為避免一些英文詞匯的直譯丟失部分原文含義勿她，在括號里加上了英文原詞幫助更準(zhǔn)確理解。