隨著微服務(wù)日益盛行，我們發(fā)現(xiàn)利用“適當(dāng)?shù)摹狈?wù)管理來運(yùn)行微服務(wù)的方法越來越成熟。舊的運(yùn)營方法經(jīng)過重新改造，變成了新方法（例如“容錯(cuò)預(yù)算”）。在確定是否可以采用“誰開發(fā)，誰運(yùn)行”的方法時(shí)，團(tuán)隊(duì)可以使用服務(wù)等級(jí)目標(biāo) (SLO) 作為一個(gè)明確的衡量標(biāo)準(zhǔn)。服務(wù)網(wǎng)格，例如 Istio，直接支持這些服務(wù)管理理念。 可觀測性備受關(guān)注，而且很多團(tuán)隊(duì)都在努力確保監(jiān)控工具可以充分洞察其系統(tǒng)的運(yùn)行狀況。

真正的“微服務(wù)運(yùn)行模式”還會(huì)改變團(tuán)隊(duì)設(shè)計(jì)與職責(zé)并且?guī)硐嚓P(guān)組織性影響。微服務(wù)運(yùn)行模式已開始涌現(xiàn)，但是我們認(rèn)為這些模式應(yīng)該建立在這樣的基礎(chǔ)上，即：首先確定一系列業(yè)務(wù)和平臺(tái)功能，然后協(xié)調(diào)各個(gè)長期團(tuán)隊(duì)進(jìn)行產(chǎn)品規(guī)劃、構(gòu)建和運(yùn)行，以實(shí)現(xiàn)這些功能。我們強(qiáng)烈反對(duì)建立一體化“平臺(tái)”團(tuán)隊(duì)，也不要指望共享業(yè)務(wù)功能能自然而然地出現(xiàn)并潛移默化地實(shí)現(xiàn)整合。

永無止境的改進(jìn)

如果說“良好的”技術(shù)人員與“杰出的”技術(shù)人員有何不同（無論他們的具體專業(yè)領(lǐng)域是什么），那就是后者永遠(yuǎn)不會(huì)對(duì)現(xiàn)有的解決方案感到滿意，而是會(huì)不斷努力創(chuàng)造更好的解決方案。在業(yè)界，我們堅(jiān)持不懈地改進(jìn)現(xiàn)有設(shè)計(jì)。某個(gè)問題可能已經(jīng)有一個(gè)好解決方案，但是如果有人創(chuàng)造了更好的解決方案，我們就會(huì)更新升級(jí)。

這方面的例子不勝枚舉。例如，Taiko 是一種節(jié)點(diǎn)庫，用于使 Chrome 瀏覽器實(shí)現(xiàn)自動(dòng)化，旨在改善和簡化 API。問題并不在于以前我們從未在瀏覽器中嘗試進(jìn)行過測試，而在于相應(yīng)技術(shù)正在逐步改進(jìn)。Deno是一種安全的服務(wù)器端 Java 和 Type 引擎，是 Node.js 的原始創(chuàng)造者開發(fā)的，他的初衷就是解決他在 Node.js 中發(fā)現(xiàn)的一些嚴(yán)重問題。Gremlin 是一種圖遍歷語言，也對(duì)其前幾代產(chǎn)品進(jìn)行了改進(jìn)。Immer.js 一直在不斷開拓不可變狀態(tài)樹的新前沿，并因此榮獲了“年度最佳突破獎(jiǎng)”。Micronaut 是一種構(gòu)建微服務(wù)和無服務(wù)器應(yīng)用程序的框架，在此領(lǐng)域帶領(lǐng)我們向前邁出了一大步。

我們今天邁出的每一步都將引導(dǎo)我們?cè)谖磥韺?shí)現(xiàn)更多創(chuàng)新，我們之前說過這些創(chuàng)新將不可估量（演進(jìn)架構(gòu)的一個(gè)核心原則就是明知無法有效預(yù)測這些變化的情況下，仍不斷構(gòu)建各種系統(tǒng)）。

我們無法預(yù)測兩年之后，也不知道這樣一步步、永無止境的改進(jìn)將會(huì)帶來怎樣的變革。

配置不堪重負(fù)

技術(shù)雷達(dá)曾經(jīng)著重討論過“配置中的編碼”問題，其中似乎會(huì)發(fā)生的一種困境是某種簡單的配置語言最終會(huì)不斷發(fā)展，直至實(shí)現(xiàn)“具有圖靈完備性的 XML”，這種 XML 非常難以進(jìn)行測試和分析。從構(gòu)建文件到模板化 Terraform 配置文件，很多情況下都會(huì)出現(xiàn)這個(gè)問題。最后，團(tuán)隊(duì)經(jīng)常會(huì)發(fā)現(xiàn)，與使用通過強(qiáng)制調(diào)整而具備可編程性配置的工具相比，以可編程語言來執(zhí)行測試代碼會(huì)更容易。

Kief Morris 是基礎(chǔ)設(shè)施即代碼的作者，他認(rèn)為根本問題在于，我們未能在配置和邏輯之間保持清晰的界限。在他看來，我們不應(yīng)該測試配置文件，也不應(yīng)該用可編程邏輯定義目標(biāo)狀態(tài)。如果執(zhí)行以上任一操作，就可能會(huì)混淆界限。

Morris 建議，聲明式語言應(yīng)在單獨(dú)的可測試組件中添加邏輯，以便于進(jìn)行擴(kuò)展。他說：“如果想要添加一個(gè)可以聲明的新東西，可以擴(kuò)展聲明語言以添加一個(gè)定義，然后實(shí)施這個(gè)定義在適當(dāng)語言中觸發(fā)的‘方式’邏輯，并且進(jìn)行測試。”

協(xié)調(diào)復(fù)雜性上升

技術(shù)行業(yè)一個(gè)普遍的趨勢是總體復(fù)雜性日益上升，組件之間所需的協(xié)調(diào)也不斷增加。Luigi 是數(shù)據(jù)領(lǐng)域的一款新工具，有助于為批處理作業(yè)構(gòu)建復(fù)雜的管道。利用 Apache Airflow 可以用編程的方式編寫、調(diào)度和監(jiān)控工作流程?，F(xiàn)在，各種新事物都開始進(jìn)入我們的系統(tǒng)，例如功能即服務(wù)、工作流程、Python 進(jìn)程等。

在我們最近的技術(shù)雷達(dá)會(huì)議上，Neal Ford 故意曲解 Dijkstra 的話說：“我們大幅減少了事物之間的關(guān)聯(lián)，最終這些事物就會(huì)像一盤散沙，現(xiàn)在我們必須把它們整合起來，使之發(fā)揮作用。”

務(wù)必謹(jǐn)記，協(xié)調(diào)本身不是壞事情。它就像關(guān)聯(lián)一樣。你需要適度的協(xié)調(diào)，才能讓系統(tǒng)有效運(yùn)行并創(chuàng)造價(jià)值。協(xié)調(diào)是好是壞，取決于協(xié)調(diào)在應(yīng)用程序中的普遍性及其覆蓋范圍。

業(yè)務(wù)行為擴(kuò)散

組織現(xiàn)在面臨的問題是過度依賴配置，而且協(xié)調(diào)復(fù)雜性日益提高，這意味著業(yè)界出現(xiàn)了一個(gè)更大的趨勢：業(yè)務(wù)邏輯不再局限于小代碼塊，而是會(huì)擴(kuò)散到整個(gè)系統(tǒng)中。業(yè)務(wù)邏輯已經(jīng)滲透到我們配置 Kubernetes pod 和協(xié)調(diào) lambda 函數(shù)的方式之中。Scott Shaw 指出：“有一種老理念認(rèn)為，如果你有一個(gè)‘工作負(fù)載’，你可以將該工作負(fù)載移到不同的位置。如今，編寫工作負(fù)載和托管工作負(fù)載分成了不同的職責(zé)，而且控制面和應(yīng)用程序都清晰地分離開了。所以這種理念再也不正確了?！?/p>

更具體一點(diǎn)來說，業(yè)務(wù)邏輯無疑只是執(zhí)行計(jì)算的東西。但是，我們還需要制定業(yè)務(wù)相關(guān)決策。如果我們要以這種方式擴(kuò)展，該怎么辦？我們?cè)撊绾卧谪?fù)載下降級(jí)？這些是產(chǎn)品負(fù)責(zé)人應(yīng)該考慮的問題，并且都屬于業(yè)務(wù)邏輯，但不是傳統(tǒng)意義上的業(yè)務(wù)邏輯。我們決定使用“業(yè)務(wù)行為”這個(gè)短語來囊括這些種類的特性。

我們對(duì)各團(tuán)隊(duì)的建議是，首先要認(rèn)識(shí)到已經(jīng)發(fā)生這種擴(kuò)散。在傳統(tǒng)架構(gòu)中，重要的東西都位于業(yè)務(wù)領(lǐng)域?qū)?。但是現(xiàn)在情況已經(jīng)改變，同等邏輯已經(jīng)遍布于基礎(chǔ)設(shè)施、配置、微服務(wù)和集成之中。事件驅(qū)動(dòng)、無服務(wù)器功能、觸發(fā) lambda 的 S3 桶中的文件，這些因素都導(dǎo)致很難跟蹤整個(gè)系統(tǒng)內(nèi)的邏輯流。各團(tuán)隊(duì)?wèi)?yīng)努力使用使整體行為更易于理解的模式，甚至可以通過降低任一系統(tǒng)中使用的技術(shù)的數(shù)量來實(shí)現(xiàn)此目的。

Fred

baiyan