\

本文要點(diǎn)

\\

• 當(dāng)前微服務(wù)架構(gòu)依然是最流行的分布式系統(tǒng)架構(gòu)風(fēng)格。Kubernetes和云原生運(yùn)動(dòng)已大規(guī)模地重新定義了應(yīng)用設(shè)計(jì)和開發(fā)中的一些方面。\\t
• 在云原生平臺(tái)上，服務(wù)僅具備可觀測(cè)性是不夠的。更基本的先決條件是使用檢查健康、響應(yīng)信號(hào)、聲明資源消耗等手段實(shí)現(xiàn)微服務(wù)的自動(dòng)化。\\t
• 在后Kubernetes時(shí)代，服務(wù)網(wǎng)格（Service Mesh）技術(shù)已完全取代了使用軟件庫實(shí)現(xiàn)網(wǎng)絡(luò)運(yùn)維（例如Hystrix斷路器）的方式。\\t
• 當(dāng)前，設(shè)計(jì)應(yīng)針對(duì)“可恢復(fù)性”。為此，微服務(wù)需要實(shí)現(xiàn)多個(gè)維度上的冪等性。\\t
• 現(xiàn)代開發(fā)人員必須做到不僅要精通編程語言去實(shí)現(xiàn)業(yè)務(wù)功能，而且同樣也要精通云原生技術(shù)去滿足一些非功能性基礎(chǔ)架構(gòu)層上的需求。\

\\

微服務(wù)的關(guān)注熱度起源于一大堆極端的想法，涉及組織的結(jié)構(gòu)、團(tuán)隊(duì)的規(guī)模、服務(wù)的規(guī)模、重寫和拋出服務(wù)而不是修復(fù)、避免單元測(cè)試等。依我的經(jīng)驗(yàn)看，其中大部分想法已被證明是錯(cuò)誤的、不實(shí)用的，或者至少在一般情況下是不適用的。當(dāng)前能殘存下來的微服務(wù)原則和實(shí)踐，大部分是非常通用和寬松定義的。雖然它們適合未來許多年內(nèi)的發(fā)展，但在實(shí)踐中并沒有多大的意義。

\\

早在Kubernetes橫空出世的幾年前，微服務(wù)理念就得到了采用，目前，它仍然是一種最流行的分布式系統(tǒng)架構(gòu)風(fēng)格。Kubernetes和云原生運(yùn)動(dòng)已大規(guī)模地重定義了應(yīng)用設(shè)計(jì)和開發(fā)的一些方面。在本文中，我試圖提出一些原始的微服務(wù)理念。我將指出，這些理念在后Kubernetes時(shí)代已不再像以前那樣強(qiáng)大。

\\

服務(wù)不僅應(yīng)可觀測(cè)，而且應(yīng)是自動(dòng)化的

\\

可觀測(cè)性(Observability) 是微服務(wù)自一開始就提出的一個(gè)基本原則?？捎^測(cè)性雖然適用于一般的分布式系統(tǒng)，但是當(dāng)前，尤其是在Kubernetes上，可觀測(cè)性的主要涉及平臺(tái)層的開箱即可用，例如進(jìn)程運(yùn)行狀況檢查、CPU和內(nèi)存消耗等。應(yīng)用能以JSON格式登錄控制臺(tái)，這就是可觀測(cè)性的最低要求。此外，平臺(tái)應(yīng)可以在無需過多服務(wù)層開發(fā)的情況下，實(shí)現(xiàn)跟蹤資源的消耗、開展請(qǐng)求追蹤、收集全部類型的指標(biāo)、計(jì)算錯(cuò)誤率等。

\\

在云原生平臺(tái)上，服務(wù)僅具備可觀測(cè)性是不夠的。更基本的先決條件是使用檢查健康、響應(yīng)信號(hào)、聲明資源消耗等手段實(shí)現(xiàn)微服務(wù)的自動(dòng)化。任何應(yīng)用都可以置于容器中并運(yùn)行。但是要?jiǎng)?chuàng)建一個(gè)可通過云原生平臺(tái)自動(dòng)化和協(xié)調(diào)編排容器的應(yīng)用，則需要遵循一定的規(guī)則。遵循這些原則和模式，可確保所生成的容器作為云本地成員在大多數(shù)容器編排引擎中表現(xiàn)為優(yōu)秀，并支持對(duì)容器進(jìn)行自動(dòng)化的調(diào)度、擴(kuò)展和監(jiān)視。

\\

我們希望平臺(tái)不僅可觀測(cè)服務(wù)中發(fā)生的情況，而且希望平臺(tái)能檢測(cè)到異常，并按照聲明情況做出協(xié)調(diào)。糾正措施可以是通過停止引導(dǎo)流量到服務(wù)實(shí)例、重新啟動(dòng)、向上/向下擴(kuò)展，也可以是將服務(wù)遷移到另一臺(tái)健康的主機(jī)、重試失敗的請(qǐng)求或是其它一些操作。如果服務(wù)實(shí)現(xiàn)了自動(dòng)化，那么所有這些糾正措施都會(huì)自動(dòng)做出，我們只需要描述所需的狀態(tài)，而不是去觀測(cè)并做出響應(yīng)。服務(wù)應(yīng)該是可觀測(cè)的，但也應(yīng)在無需人工干預(yù)的情況下由平臺(tái)實(shí)現(xiàn)問題整改。

\\

具備正確職責(zé)的智能平臺(tái)和智能設(shè)備

\\

在從SOA轉(zhuǎn)向微服務(wù)的過程中，在服務(wù)交互上發(fā)生的另一個(gè)根本轉(zhuǎn)變就是“智能端點(diǎn)啞管道”（smart endpoints and dumb pipes）這一理念。在微服務(wù)領(lǐng)域，服務(wù)不依賴于所具有的集中式智能路由層，而是依賴于具有某些平臺(tái)級(jí)功能的智能端點(diǎn)。服務(wù)的實(shí)現(xiàn)是通過在每個(gè)微服務(wù)中嵌入傳統(tǒng)ESB的部分功能，并轉(zhuǎn)為使用不具有業(yè)務(wù)邏輯元素的一些輕量級(jí)協(xié)議。

\\

這仍然是一種慣常采用的方法，即在不可靠的網(wǎng)絡(luò)層（使用諸如Hystrix之類的庫）實(shí)現(xiàn)服務(wù)交互，但在當(dāng)前的后Kubernetes時(shí)代，服務(wù)交互已完全被服務(wù)網(wǎng)格（Sevice Mesh技術(shù)取代。服務(wù)網(wǎng)格吸引人之處在于，它甚至要比傳統(tǒng)的ESB更智能。網(wǎng)格可以執(zhí)行動(dòng)態(tài)路由、服務(wù)發(fā)現(xiàn)、基于延遲的負(fù)載平衡、響應(yīng)類型、指標(biāo)和分布式跟蹤、重試、超時(shí)，以及我們所能想到的所有特性。

\\

與ESB的不同，服務(wù)網(wǎng)格只有一個(gè)集中路由層，每個(gè)微服務(wù)通常都具有自己的路由器，即一個(gè)使用額外中央管理層執(zhí)行代理邏輯的“跨斗模式容器”（Sidecar Container）。更重要的是，管道（即平臺(tái)和服務(wù)網(wǎng)格）中并不維持任何業(yè)務(wù)邏輯。管道完全聚焦于基礎(chǔ)架構(gòu)問題，而讓服務(wù)聚焦于業(yè)務(wù)邏輯。下圖表示了為適應(yīng)云環(huán)境的動(dòng)態(tài)和不可靠特性，ESB和微服務(wù)在認(rèn)知上的演變情況。

\\

\\

圖 從SOA到MSA和CNA

\\

如果查看服務(wù)的其他一些方面，我們就會(huì)注意到云原生不僅影響了端點(diǎn)和服務(wù)交互。Kubernetes平臺(tái)（及其所有附加技術(shù)）還負(fù)責(zé)資源的管理、調(diào)度、部署、配置管理、擴(kuò)展和服務(wù)交互等。與其再次稱之為“智能代理啞管道”，我認(rèn)為更好的描述應(yīng)是一種具備正確職責(zé)的智能平臺(tái)和智能服務(wù)。它不僅是與端點(diǎn)相關(guān)，而且也是一個(gè)完整的平臺(tái)，實(shí)現(xiàn)主要聚焦于業(yè)務(wù)功能的服務(wù)在所有基礎(chǔ)架構(gòu)上的自動(dòng)化。

\\

設(shè)計(jì)不應(yīng)針對(duì)“故障”，而應(yīng)針對(duì)“恢復(fù)”

\\

毫無疑問，要在基礎(chǔ)架構(gòu)和網(wǎng)絡(luò)本身并非可靠的云原生環(huán)境中運(yùn)行微服務(wù)，我們必須針對(duì)故障做出設(shè)計(jì)。但是越來越多的故障是由平臺(tái)檢測(cè)并處理的，而人們對(duì)如何從微服務(wù)中捕獲故障的考慮較少。相反，我們應(yīng)通過考慮從多個(gè)維度實(shí)現(xiàn)冪等性，設(shè)計(jì)我們的恢復(fù)服務(wù)。

\\

容器技術(shù)、容器編排和服務(wù)網(wǎng)格（serive mesh）可以檢測(cè)許多故障，并從中進(jìn)行恢復(fù)。例如無限循環(huán)（分配CPU份額）、內(nèi)存泄漏和OOM（運(yùn)行狀況檢查）、磁盤占用（配額問題）、Fork炸彈（進(jìn)程限制），批量處理和進(jìn)程隔離（限制內(nèi)存份額）、延遲和基于響應(yīng)的服務(wù)發(fā)現(xiàn)、重試、超時(shí)、自動(dòng)擴(kuò)展等。同樣，在過渡到無服務(wù)器模型后，服務(wù)必須在幾毫秒內(nèi)處理一個(gè)請(qǐng)求?？瓷先?duì)垃圾回收、線程池、資源泄漏等問題的關(guān)注，越來越成為一些毫不相關(guān)的問題……

\\

使用平臺(tái)處理所有諸如此類的問題，會(huì)將服務(wù)視為一個(gè)密封黑盒子。該黑盒子應(yīng)支持多次啟動(dòng)和停止（支持服務(wù)重新啟動(dòng)）、服務(wù)按比例的放大和縮小（通過將服務(wù)成為無狀態(tài)的以支持安全擴(kuò)展）、假定許多傳入請(qǐng)求最終會(huì)超時(shí)（使端點(diǎn)具有冪等性）、假定許多傳出請(qǐng)求將暫時(shí)失敗并且平臺(tái)將會(huì)做出重試（確保我們使用了冪等服務(wù)）。

\\

為實(shí)現(xiàn)自動(dòng)化在云原生環(huán)境中適用自動(dòng)化，服務(wù)必須滿足下列條件：

\\

• 對(duì)重啟的冪等（服務(wù)支持多次被殺掉并啟動(dòng)）。\\t
• 對(duì)向上/向下擴(kuò)展冪等（服務(wù)可實(shí)現(xiàn)多個(gè)實(shí)例的自動(dòng)擴(kuò)展）。\\t
• 對(duì)服務(wù)生成者冪等（其它服務(wù)可重試調(diào)用）。\\t
• 對(duì)服務(wù)消費(fèi)者冪等（服務(wù)或服務(wù)網(wǎng)格可以重試傳出請(qǐng)求）。\

如果服務(wù)在一次或是多次執(zhí)行上述行為中總是表現(xiàn)出同一方式，那么平臺(tái)就可以在無需人工干預(yù)的情況下從故障中恢復(fù)服務(wù)。

\\

最后請(qǐng)記住，平臺(tái)提供的所有恢復(fù)只是一些本地優(yōu)化。正如Christian Posta所指出的，分布式系統(tǒng)中應(yīng)用的安全性和正確性仍然是應(yīng)用的責(zé)任。對(duì)于設(shè)計(jì)一個(gè)整體穩(wěn)定的系統(tǒng)，業(yè)務(wù)流程整體范圍中的思維模式（可能跨越多個(gè)服務(wù)）十分重要的。

\\

雙重開發(fā)職責(zé)

\\

越來越多的微服務(wù)原則已被Kubernetes及一些補(bǔ)充項(xiàng)目實(shí)施和提供。因此，現(xiàn)代開發(fā)人員必須做到不僅要精通編程語言去實(shí)現(xiàn)業(yè)務(wù)功能，而且同樣也要精通云原生技術(shù)去完全滿足一些非功能性基礎(chǔ)架構(gòu)層上的需求。

\\

業(yè)務(wù)需求和基礎(chǔ)架構(gòu)（操作上的需求、跨功能的需求，或是一些系統(tǒng)質(zhì)量屬性）之間的界限通常是模糊不清的，我們不可能只采取其中的某個(gè)方面，而期望其他人去實(shí)現(xiàn)另一個(gè)方面。例如，如果要在服務(wù)網(wǎng)格層實(shí)現(xiàn)重試邏輯，那么必須使服務(wù)中的業(yè)務(wù)邏輯或數(shù)據(jù)庫層所使用的服務(wù)具有冪等性。如果在服務(wù)網(wǎng)格層使用超時(shí)，那么必須在服務(wù)中實(shí)現(xiàn)服務(wù)使用者超時(shí)的同步。如果必須要實(shí)現(xiàn)服務(wù)的定期執(zhí)行，那么必須配置Kubernetes作業(yè)去按時(shí)間執(zhí)行。

\\

展望未來，一些服務(wù)功能應(yīng)作為業(yè)務(wù)邏輯實(shí)現(xiàn)在服務(wù)中，而其它一些服務(wù)功能則應(yīng)作為平臺(tái)功能提供。雖然使用正確的工具去完成正確的任務(wù)是一種很好的責(zé)任分離，但新技術(shù)不斷出現(xiàn)極大地增加了整體的復(fù)雜性。要在業(yè)務(wù)邏輯方面實(shí)現(xiàn)簡單的服務(wù)，我們需要很好地理解分布式技術(shù)堆棧，因?yàn)殚_發(fā)職責(zé)是分散在各個(gè)層上的。

\\

事實(shí)證明，Kubernetes支持向上擴(kuò)展到數(shù)千個(gè)節(jié)點(diǎn)，數(shù)萬個(gè)Pod和每秒數(shù)百萬事務(wù)。但它是否同樣支持向下擴(kuò)展？對(duì)我來說，我并不清楚應(yīng)用的規(guī)模、復(fù)雜性或關(guān)鍵性的閾值應(yīng)該是多少，才能證明我們引入復(fù)雜的“云原生”是正確的。

\\

結(jié)論

\\

看到微服務(wù)運(yùn)動(dòng)為采用Docker和Kubernetes等容器技術(shù)提供了如此巨大的動(dòng)力，這是非常有意思的。雖然在一開始是微服務(wù)實(shí)踐推動(dòng)了這些技術(shù)的發(fā)展，但現(xiàn)在是Kubernetes重新定義了微服務(wù)架構(gòu)的原則和實(shí)踐。

\\

從最近的一些實(shí)例看，我們將很快采納功能模型作為有效的微服務(wù)原語，而不是將微服務(wù)視為納米（nanoservice）服務(wù)的反模式。我們并沒有充分質(zhì)疑云原生技術(shù)對(duì)于中小型案例的實(shí)用性和適用性，而是出于興奮有些隨意地投身到這個(gè)領(lǐng)域中。

\\

Kubernetes從ESB和微服務(wù)中汲取了大量經(jīng)驗(yàn)，因此它將會(huì)成為最終的分布式系統(tǒng)平臺(tái)。它是一種用于定義建筑風(fēng)格的技術(shù)，而不是反之。究竟是好是壞，只有時(shí)間才能證明。

\\

作者簡介

\\

Bilgin Ibryam (@bibryam) 是Red Hat的首席架構(gòu)師、提交者和ASF成員。他也是一名開源布道師、博客作者，《Camel設(shè)計(jì)模式》（Camel Design Patterns）和《Kubernetes模式》（Kubernetes Patterns）等書的作者在他的日常工作中，Bilgin 喜歡指導(dǎo)、編碼和領(lǐng)導(dǎo)開發(fā)人員成功地構(gòu)建云解決方案。他目前的工作重點(diǎn)是應(yīng)用程序集成、分布式系統(tǒng)、消息傳遞、微服務(wù)、DevOps 和云原生的挑戰(zhàn)?？赏ㄟ^Twitter、Linkedin和個(gè)人博客聯(lián)系Bilgin。

\\

查看英文原文： Microservices in a Post-Kubernetes Era

總結(jié)

以上是生活随笔為你收集整理的后Kubernetes时代的微服务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。