微服務領域的軟體架構

banq發表於2018-12-04
微服務架構

在討論微服務時，經常出現有關軟體架構的問題。許多微服務的新手不確定如何討論架構以及如何做出決策。本文將解答這些問題，並分享一些其他建議。

整個系統的高階檢視
首先，無論您決定什麼是處理架構決策的好方法，您都需要知道您的系統是什麼樣的。
我從事過一些專案，其中真正的架構是“部落知識”，從一組開發人員傳遞到另一組開發人員，以及最新的高階邏輯架構圖是一個貼在牆上的系統。
為了真正做出精確的架構決策並重構您的系統，您真的需要知道您正在使用的是什麼。進入“盲目”狀態很容易犯錯並忽視副作用和依賴性。
我的第一個建議是，無論你決定什麼 - 首先要在建立高階邏輯架構圖方面付出一些努力。理想情況下，您還可以為資料流，安全性和系統的其他重要方面製作一些圖表。
使用圖表工作可能看起來像是一件苦差事，所以請確保與那些對團隊有重要且真正有用的人一起工作。

架構選擇
是什麼讓微服務系統的架構更難以討論？我相信這將是這兩件事：

  • 快速變化
  • 每一步都有很多選擇

隨著每一步的選擇數量增加，你不能只相信自己的運氣而不去考慮細枝末節。此外，隨著開發的快速推進，你應該遠離TOGAF等類似的想法。（根據我的拙見，你應該遠離TOGAF）。

使用架構決策記錄作為系統設計工具
架構決定（AD）是一種軟體設計選擇，針對功能性或非功能性的需求進行的選擇設計。（ADR GitHub組織的主頁）
ADR並不是全新的--Michael Nygard已經在2011年的部落格文章中對它們進行了描述，但我僅在2018年與他們聯絡。在2002年，ThoughtWorks將其作為技術採用雷達列為ADOPT級技術。
這整個想法是什麼？有不同的方法，但它大致歸結為：

  • 對於您將採取的每個建築決策（AD），請遵循此流程。
  • 對於每個AD，使用模板記錄：
    • 上下文
    • 動機
    • 決策
    • 狀態
    • 後果
    • 上述組合（或其他要求）
  • 這些建立ADR（建築決策記錄）
  • 將它們儲存在像Git儲存庫，Google文件，Wiki（適用於您的團隊的東西）的地方

這裡的核心思想是保持簡單，保持標準化，保持可訪問性。
我相信對於許多團隊來說，這正是我們所需要的。你想知道決定了什麼，何時以及為什麼。這不需要花費太多精力。
將這個想法更進一步並使用Gi​​t-您可以將架構決策作為人們討論的拉取請求。讓更多人參與和聽到的好方法！

分散式系統的穩定性
由於構建像微服務這樣的分散式系統比較難，我建議在引導整體架構和設計時新增一種額外的，更微妙的技術：消費者驅動合約Consumer Driven Contracts（CDC）。
如果您不熟悉這個概念，請檢視  https://docs.pact.io/ ，在那裡您可以閱讀Pact（一種流行的CDC工具）的介紹。

如果您以真正的分散式方式（多個團隊，多個服務）工作，您需要找到一種方法讓其他團隊瞭解對您和您的系統來說具有架構意義的東西。一種方法是使用普通的ADR，另一種方法是使用CDC。

需要傳統的軟體架構師嗎？
我認為很明顯，在使用微服務時，您需要考慮軟體架構。您還應該參與架構決策（在ADR的幫助下）並發展您的API（安全地使用CDC）。
這是否意味著你需要一位架構師？做：

  • 更新高階架構圖
  • 幫助創造和進步ADR
  • 致力於跨團隊的API設計
  • 與團隊一起解決更具挑戰性的問題（安全等）

我認為在一個足夠大的專案上這四點可以是一個人的一份全職工作。你不一定需要有這樣頭銜的人，但你肯定需要擁有架構技能的人。


總結
希望本文能夠讓您瞭解如何在微服務系統中實現架構工作。在微服務上工作比僅僅構建巨石單體更困難。這意味著您不僅需要一個優秀的開發團隊，還需要具有敏銳架構直覺和現代輕量級工作的人才能工作！

 

相關文章