停止構建分佈式整體
> Photo by Markus Spiske on Unsplash
我見過很多文章，開發人員談論他們的組織如何轉向面向服務的體系結構（SOA），失敗並遷移回整體開發。 當然，這沒有錯。 我們工作的一個主要方面是嘗試某些東西，看看它是否有效，如果無效，則將其報廢。 SOA並不適合所有人。 如果不適合您的公司，則堅持使用整體設計。 但是，如果是這樣，那麼您必須做對！
與大型和單一代碼庫一起工作多年形成了我們對應該如何做的看法和偏見。 如果我們在使用服務時不自覺地遵循相同的習慣，那麼我們可能不會意識到我們失敗的領域。 在本文中，我將討論在SOA世界中應用整體實踐的危險。
1.高度耦合的數據和架構
為了在SOA世界中取得成功，必須避免高度耦合的數據和架構。 每個服務都應以深思熟慮的前瞻性抽象為基礎。 服務應在一定程度上是獨立的-理想情況下，他們不知道任何服務的存在。 在某些情況下，創建高度耦合的服務變得容易：
· 我們構建臨時服務以支持臨時用例。
· 創建良好的抽象可能會很昂貴。 耦合服務是組織阻力最小的途徑。
· 一些產品具有中央數據模型。 如果我們讓數據模型決定我們定義的抽象，我們的服務最終將在某種程度上被耦合。
如果我們不仔細檢查我們創建的抽象，則可能會導致高度耦合的服務生態系統。 這是一些耦合的依賴結構：
> Photo by the author.
· 左：服務A調用服務B，知道它將調用服務C。然後，它向服務C查詢結果。
· 正確：服務A依賴於B，而服務B依賴於C，服務C依賴於A。我們的依賴圖中有一個循環。
在這些結構中，您實際上是在開發分佈式整體。 在某個時候，您會遇到以下問題：
· 您需要同時更新兩項服務，但是由於它們彼此依賴，因此您將不知道先更新哪一項。 通過在一項服務中進行不間斷的向後兼容更改，然後對其進行更新，然後再更新第二項服務，然後再從這兩項服務中刪除無效代碼，即可解決此問題。 是的…不漂亮。
· 一個簡單的用戶流可以跨越多個服務。 如果存在問題，則只能由具有多種服務的上下文知識的人來診斷。
一個"壞的"依賴結構暗示了分佈式的整體-使用整體的所有痛苦，卻沒有使用服務的好處。 此外，高度耦合的服務通常會鋪平道路，並歡迎更多的服務。 換句話說，如果您不解決問題，那麼隨著服務生態系統的發展，情況會變得更糟。
數據耦合
當數據在各個服務之間高度耦合時，您將需要進行投資，以使用同步API調用和異步任務使數據保持同步。 這些同步過程也可以採用SAGA的形式。 無論如何，您都必須：
· 大量投資於基礎架構和測試，以確保數據正確同步。
· 對開發人員進行流程培訓，以免他們意外引入更改而導致數據同步問題。
· 隨著足夠多的數據點在多個服務之間同步，開發人員必定會犯一個錯誤-並可能造成災難性的錯誤。
· 投資可視性和檢測手段，以確保在同步過程中斷時收到提醒。 當確實發生故障時，您必須診斷問題並解決。 兩者都可能非常昂貴，具體取決於系統的剛性。
但是，如果您能夠建立很少/沒有數據耦合的服務生態系統，則可以避免不必要的麻煩。
2.整體開發習慣
在SOA世界中，通信結構，團隊，運營，部署和流程看起來都不同。 經過數年的整體開發，我們收集的工具不一定是與服務一起使用的工具。 如果開發人員（和組織）要成功實現SOA，則需要用等效的SOA代替舊的工具/習慣。
本地開發
當使用整體時，我們在本地計算機上運行大多數（如果不是全部）基礎架構。 開發人員有時會遇到"在我的計算機上不起作用"的問題。 組織在引導程序解決方案上進行投資以避免此問題並使開發人員儘快工作。 大多數解決方案都圍繞使基礎結構更易於在本地計算機上運行而進行。
當您開始使用多種服務時，無法在本地計算機上運行所有內容。
· 在大多數情況下，開發機功能不足以在功能開發期間運行必要的服務。 您可能無法運行一些大型服務，但是有時您的計算機將無法跟上。
· 在本地運行服務意味著開發人員必須知道如何運行（並可能部署）他們不擁有的服務。 理想情況下，服務所有者無需擔心所有權以外的任何服務。
投資易於在本地運行多個服務的解決方案是整體式的心態，並且以相同的方式暗示著分佈式整體式的方式進行服務開發。 我將在文章末尾留下一些資源，介紹其他公司如何進行本地服務開發，但是這些解決方案通常是這樣的：
· 使用依賴項注入和客戶端庫模擬與其他服務的交互。
· 在雲中運行您的一些基礎架構，在本地運行其中的一些，並將本地基礎架構插入到雲基礎架構中。
端到端測試
端到端測試有兩種形式：
· 自動化測試，通常在CI / CD管道中運行。
· 手動測試，開發人員在簽入代碼之前和進行代碼審查時進行的手動測試。
整體代碼庫中的端到端測試有些簡單。 設置適當的數據/狀態後，您就可以在本地計算機上測試新的用戶流。
即使我們編寫了很好的單元/集成測試來驗證代碼的正確性，在質量檢查過程中手動測試本地計算機上的所有內容也會增加我們的信心。 隨著您的服務生態系統的發展，功能和用例將得到多種服務的支持，並且無法在本地測試所有內容：
· 設置適當的狀態可能需要很長時間。
· 可能很難模擬與非平凡系統（消息代理，異步作業隊列等）的交互。
· 您的計算機無法運行所需的基礎架構。
端到端測試在SOA中看起來非常不同。 尋求一種易於在本地進行端到端測試的解決方案既昂貴又無法擴展。
SOA之所以受歡迎，是因為它有望加快迭代速度。 如果您要花費大量時間在本地測試您的更改，那麼您就無法利用SOA進行定位。 在某個時候，您需要放棄在本地進行所有測試的心理安全性。
您的測試策略取決於您將採用的本地開發解決方案。 以下是一些無需本地測試用戶流即可釋放代碼的方法：
· 隱藏在功能鰭背後的新功能，使您可以在為所有人啟用功能之前測試生產中的用戶流程。
· 金絲雀部署，影子部署，紅色/黑色部署等。
· 在開始生產之前，對階段中的新更改進行壓力測試。
當然，您可以通過其他方式獲得通過放棄本地測試而放棄的心理安全性：
· 全面且經過深思熟慮的儀器/可觀察性。
· 警報，工作簿和回滾過程可幫助您從故障中恢復。
我在文章末尾列出了測試/部署策略資源。
調試
另一方面，如果您的測試策略需要更改，那麼調試策略也需要更改。
在整體中，堆棧跟蹤足以使我們開始。 堆棧跟蹤將我們指向正確的方向，然後我們將跟蹤餅乾屑，直到解決問題為止。 堆棧跟蹤和傳統的調試工具通常足以調試SOA中的問題，但是它們對於某些類型的問題沒有用：
· 暫時性網絡錯誤。
· 跨多個服務的數據同步問題。
· 錯誤的配置-連接超時，讀/寫超時，工作線程數，擴展配置等。
儘管您仍會梳理代碼以查找問題，但調試工具箱還應包括：
· 用於下載和過濾生態系統中不同系統的訪問日誌的腳本。
· 分佈式跟蹤可幫助您瞭解單個用戶請求的生命週期。
· 具有CPU，內存和P99指標的儀表板可捕獲不會導致堆棧跟蹤的問題。
· 複製生產環境的負載模擬策略。
下一步
如果發現自己處於這種情況下該怎麼辦？ 當然，沒有一種萬能的解決方案。 這裡有一些想法可以幫助您入門：
· 首先，如果服務穩定且未更改，請不要理會系統。 它正在運行，並且您不想成為破壞它的人，因為您已經"開明"。
· 如果您當前的體系結構引起了問題，那麼我要做的第一件事就是分析維護當前系統的金錢成本，與遷移到更好的系統相關的成本以及新系統可以節省的成本。 這是一個艱苦的練習，但是您會驚訝地發現，使用提前期，錯誤/中斷數量，受影響的用戶數量等指標可以走多遠。一旦進行了全面的分析，您可能會意識到遷移 沒必要 但是，如果分析增強了您遷移系統的決心，請使用分析來獲得管理層的支持。
· 在許多情況下，更改當前系統是不現實的。 該組織不能承受緩慢的遷移速度，這可能太昂貴了，等等。沒關係。 您仍然可以確保系統的設計正確地向前發展。
結論
在SOA中開發分佈式整體非常容易。 我們需要避免將整體開發習慣應用於我們的服務。 以下是一些要注意的症狀：
· 高度耦合的數據和/或體系結構。
· 用於多個服務的本地開發策略不佳。
· 一個糟糕的測試策略，涉及在本地測試所有內容。
· 過時的調試工具無法診斷網絡和跨服務問題。
整體開發還不錯。 只是不同而已。 許多公司已經投資了向SOA的轉移，卻沒有意識到他們要投資於整體開發要好得多。 無論您堅持使用整體方案還是走服務路線，請務必避免構建分佈式整體方案，這是兩全其美的做法。
(本文翻譯自Talha Malik的文章《Signs of Failing Service-Oriented Architecture》，參考：https://medium.com/better-programming/signs-of-failing-service-oriented-architecture-fd405c58f75b)
閱讀更多 聞數起舞 的文章
