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

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

永無止境的改進

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

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

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

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

配置不堪重負(fù)

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

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

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

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

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

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

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

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

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

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

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

Fred

baiyan