多年來，我們一直使用大單體代碼庫，于是形成了對某些事情的看法和偏見。如果我們在采用 SOA 時仍然無意識地堅持過去的習慣，可能就意識不到將會在哪些方面遭遇失敗。

在本文中，我們將討論在 SOA 架構(gòu)中采用單體系統(tǒng)開發(fā)實踐會存在哪些風險。

想要在 SOA 世界中取得成功，就要避免數(shù)據(jù)和架構(gòu)的高度耦合，這點很重要。每一個服務(wù)都應該建立在深思熟慮的抽象基礎(chǔ)之上。在某種程度上，服務(wù)應該是獨立的——理想情況下，它們不需要知道其他服務(wù)的存在。而在以下這些情況下，很容易創(chuàng)建出高度耦合的服務(wù)：

• 為了臨時緊急用例，而構(gòu)建了臨時的服務(wù)。

• 抽象的成本可能很高。對于企業(yè)來說，耦合服務(wù)是阻力最小的一條路徑。

• 有些產(chǎn)品的數(shù)據(jù)模型是中心化的，如果由數(shù)據(jù)模型來決定抽象的定義，那么服務(wù)就會存在某種程度的耦合。

如果不注意，我們可能會得到一個高度耦合的服務(wù)生態(tài)系統(tǒng)。下面是一些耦合的依賴結(jié)構(gòu)：

左邊：服務(wù) A 調(diào)用服務(wù) B，知道服務(wù) B 需要調(diào)用服務(wù) C，然后它再調(diào)用服務(wù) C 獲取結(jié)果。

右邊：服務(wù) A 依賴服務(wù) B，服務(wù) B 依賴服務(wù) C，而服務(wù) C 又依賴服務(wù) A。這是一個依賴循環(huán)。

這些結(jié)構(gòu)最終會變成分布式單體。到了某個時候，你會遇到以下這些問題：

• 你需要同時更新兩個服務(wù)，但不知道先更新哪一個，因為它們彼此依賴。你可以先在其中一個服務(wù)中引入非中斷的向后兼容性變更，更新它，然后再更新第二個服務(wù)，最后移除不需要的代碼，但這樣做不夠“優(yōu)雅”。

• 一個簡單的邏輯可能會跨越多個服務(wù)。如果出了問題，只能由對多個服務(wù)都了解的人來診斷問題。

“糟糕”的依賴結(jié)構(gòu)是分布式單體的征兆——開發(fā)單體的痛苦一點都不會少，面向服務(wù)的好處卻一點都不會有。此外，高度耦合的服務(wù)通常會讓你越陷越深。換句話說，如果不解決這些問題，隨著服務(wù)生態(tài)系統(tǒng)的增長，情況會變得更糟。

當數(shù)據(jù)高度耦合時，你需要使用同步 API 和異步任務(wù)來保持數(shù)據(jù)同步。這些同步過程也可能以 Saga 的形式出現(xiàn)。但不管怎樣，你不得不做這些事情：

• 在基礎(chǔ)設(shè)施上大力投入，并進行大量的測試，以確保數(shù)據(jù)正確同步。

• 培訓開發(fā)人員，這樣他們就不會意外地做出一些會導致數(shù)據(jù)同步故障的變更。

• 在多個服務(wù)之間同步足夠多的數(shù)據(jù)之后，開發(fā)人員肯定會犯錯——而且可能是災難性的錯誤。

• 在可見性和異常檢測方面做很多工作，確保在同步過程出現(xiàn)中斷時能夠收到警報。當出現(xiàn)故障時（很可能會出現(xiàn)），你不得不去診斷問題并解決它們。根據(jù)系統(tǒng)要求，這兩種方法的成本都非常高。

但是，如果服務(wù)生態(tài)系統(tǒng)的數(shù)據(jù)耦合程度很低或者沒有耦合，就可以避免這些麻煩。

當你發(fā)現(xiàn)自己正處在這樣的境地，你該怎么辦？當然，并不存在放之四海而皆準的解決方案，這里只是提供一些建議：

• 首先，如果服務(wù)很穩(wěn)定，并且沒有人在修改它，那就不要管它了。你不會想成為那個打破這種“寧靜”的人。

• 如果當前的架構(gòu)出了問題，那么你要做的第一件事就是分析當前系統(tǒng)的維護成本、修改系統(tǒng)的成本以及新系統(tǒng)所節(jié)省的成本之間存在怎樣的關(guān)系。做好這件事情并不容易，但如果去做了，你會驚訝地發(fā)現(xiàn)使用一些指標（比如交付時間、bug 個數(shù)或宕機次數(shù)、受影響的用戶數(shù)量等）會給你帶來些什么。在進行了徹底的分析之后，你會發(fā)現(xiàn)遷移可能是沒有必要的。但是，如果分析之后確定需要進行遷移，那么就可以使用分析結(jié)果來獲得管理層的支持。

• 在很多情況下，修改已有的系統(tǒng)是不現(xiàn)實的。遷移會影響企業(yè)的運營，成本可能很高。不過沒關(guān)系，只要你確保系統(tǒng)的設(shè)計是正確的，那就可以繼續(xù)這樣下去。

在 SOA 世界里，溝通方式、團隊、運營、部署和流程與單體架構(gòu)世界是不一樣的。我們開發(fā)單體系統(tǒng)使用的工具與開發(fā)面向服務(wù)系統(tǒng)使用的工具不一定都一樣。如果開發(fā)人員（和企業(yè)）想要成功轉(zhuǎn)向 SOA，那么舊工具和開發(fā)習慣也需要被新的工具和開發(fā)習慣所取代。

在開發(fā)單體系統(tǒng)時，我們在本地機器運行大部分的基礎(chǔ)設(shè)施。開發(fā)人員或多或少都會遇到“它無法在我的機器上運行”的問題。企業(yè)會提供引導解決方案來避免這個問題，讓開發(fā)人員盡快恢復開發(fā)工作。大多數(shù)解決方案的目標是讓基礎(chǔ)設(shè)施更容易在本地機器上運行。

在開發(fā)面向服務(wù)的系統(tǒng)時，在本地機器上運行所有的東西將會遇到伸縮性問題。

• 在大多數(shù)情況下，開發(fā)機配置不高，無法在開發(fā)期間運行必需的服務(wù)。你的機器可能可以運行少量的大型服務(wù)，但總有一天配置會跟不上。

• 要在本地運行服務(wù)，開發(fā)人員必須知道如何運行（或者部署）不是他們開發(fā)的服務(wù)。

在本地運行多個服務(wù)的解決方案是一種單體思維，以這種方式來開發(fā)面向服務(wù)的系統(tǒng)可能會變成分布式單體。一些公司提供了本地服務(wù)開發(fā)解決方案，它們通常是這樣的：

• 通過依賴注入和客戶端開發(fā)庫來模擬與其他服務(wù)的交互。

• 在云端運行一部分基礎(chǔ)設(shè)施，在本地運行一部分基礎(chǔ)設(shè)施，并將本地的基礎(chǔ)設(shè)施與云端集成在一起。

端到端測試有兩種形式：

• 自動化測試，通常會借助 CI/CD 管道。

• 手動測試，這是開發(fā)人員在提交代碼之前和在進行代碼評審時所做的工作。

單體代碼庫的端到端測試比較容易。在準備好適當?shù)臄?shù)據(jù)之后，就可以在本地機器上執(zhí)行測試。

雖然我們已經(jīng)進行了單元和集成測試，讓測試人員在本地機器上進行端到端手動測試仍然會進一步提升我們的信心。隨著服務(wù)生態(tài)系統(tǒng)的發(fā)展，服務(wù)會越來越多，想要在本地測試所有東西是不可能的事情：

• 準備數(shù)據(jù)可能需要很長時間。

• 難以模擬系統(tǒng)（如消息代理、異步作業(yè)隊列等）交互。

• 開發(fā)機無法運行所需的基礎(chǔ)設(shè)施。

SOA 架構(gòu)的端到端測試則不太一樣。進行本地端到端測試的成本非常高，而且不具備伸縮性。

SOA 之所以流行，是因為它可以加快迭代速度。如果你花了大量時間在本地測試上，那就無法利用 SOA 的優(yōu)勢。你需要放棄在本地測試一切的想法。

你的測試策略取決于你將要采用的本地開發(fā)解決方案。下面是一些無需進行本地測試就可以發(fā)布代碼的方法：

• 啟用功能開關(guān)，在將功能發(fā)布給所有用戶之前就可以在生產(chǎn)環(huán)境中進行測試。

• 金絲雀部署、影子部署、紅黑部署，等等。

• 在發(fā)布到生產(chǎn)環(huán)境之前對變更進行壓力測試。

當然，雖然你放棄了本地測試，但仍然可以通過以下這些途徑來提升信心：

• 成熟的可觀測性。

• 警報、工作簿和回滾過程，可在發(fā)生故障時進行回滾。

另一方面，如果測試策略發(fā)生了變化，那么調(diào)試策略也需要做出改變。

在單體系統(tǒng)中，一個堆棧跟蹤信息就足以讓我們著手診斷問題。堆棧跟蹤信息為我們指明了方向，我們層層深入，直到找到問題根源。堆棧跟蹤信息和傳統(tǒng)的調(diào)試工具通常也可以用來調(diào)試 SOA 架構(gòu)中出現(xiàn)的問題，但對某些問題是毫無用處的：

• 臨時的網(wǎng)絡(luò)錯誤。

• 多個服務(wù)之間的數(shù)據(jù)同步問題。

• 不正確的配置——連接超時、讀寫超時、工作進程數(shù)量、伸縮配置等等。

除了看代碼找問題，你的調(diào)試工具箱中也需要包括這些：

• 用于下載和篩選訪問日志的腳本。

• 分布式跟蹤，幫你了解用戶請求的生命周期。

• 帶有 CPU、內(nèi)存和 P99 指標的儀表盤，用于捕獲沒有拋出堆棧跟蹤信息的問題。

• 用于模擬生產(chǎn)環(huán)境負載的策略。

在采用 SOA 架構(gòu)時很容易把系統(tǒng)開發(fā)成分布式單體。我們要避免將單體系統(tǒng)的開發(fā)習慣帶到 SOA 架構(gòu)中。以下是一些需要注意的癥狀：

• 高度耦合的數(shù)據(jù)或架構(gòu)。

• 糟糕的本地多服務(wù)開發(fā)策略。

• 糟糕的測試策略，包括在本地測試所有東西。

• 過時的調(diào)試工具，無法診斷網(wǎng)絡(luò)和跨服務(wù)問題。

單體系統(tǒng)并不是壞東西。很多公司為了轉(zhuǎn)向 SOA 而大肆投入資源，但卻沒有意識到，在某些情況下，單體可能更適合它們。無論你是堅持使用單體還是采用 SOA，都要避免把系統(tǒng)變成分布式單體——這才是最糟糕的。

拓展閱讀

https:///better-programming/signs-of-failing-service-oriented-architecture-fd405c58f75b