獨立系統架構 微服務原則

獨立系統架構

簡介

獨立系統架構（ISA，Independent Systems Architecture）是基於經驗的最佳實踐的集合，特別是微服務和自包含系統以及這些項目所面臨的挑戰。

通常採用微服務的項目都未能成功。這套最佳實踐可確保避免常見的陷阱，並實現微服務所承諾的優勢。

但是，ISA 原則並不總是適用 - 有關詳細信息，請參閱常見問題。

術語

這些原則中對於不能在系統中妥協且必須存在於系統中的方面使用 “必須”。“應該” 用於具有很多好處的原則，但在某些情況下可以省略。這裏描述的原則談論一個系統。通常在企業的 IT 環境中會包含許多系統。，每個系統可能使用不同的原則構建，甚至可能採用完全不同的方法。

原則

原則一：模塊

模塊是一個存在已久的概念，一個系統由多個模塊構成。

系統必須分爲提供接口的模塊。只能通過這些接口訪問其他模塊。因此，模塊不能直接依賴於其他模塊的實現細節，例如：數據庫中的內部數據表示。其餘原則定義瞭如何實現模塊，以及 ISA 與其他模塊化方法有何不同。

長期以來模塊化被認爲是處理大型複雜軟件系統的重要工具。使用術語 “模塊” 重用了這些想法。模塊意味着例如：高凝聚力和低耦合作爲架構的目標，或單一責任原則。信息隱藏也意味着任何其他模塊都不得訪問數據和數據庫。因此，沒有必要明確說明這些想法。

原則二：宏架構和微架構（The Micro Architecture）

系統必須具有兩個明確分離的架構決策級別：

這裏提出的架構允許大量自由。但是，所有模塊仍然需要顯示爲一個整體。因此需要在宏架構層面上做出一些決策。一經定義，宏和微架構清楚地說明了在哪個級別上必須決定什麼。目標是在宏架構級別上儘可能少地定義，以便在沒有充分理由的情況下不受限制。並非每個細節都應在宏架構中定義。此外，宏架構應該專注於從長遠來看相當穩定的決策，而微架構決策則不那麼穩定。宏架構影響所有模塊，因此更難改變。所以不應該過於頻繁地改變它。

原則三：容器

模塊必須作爲單獨的進程，容器或虛擬機實現，以最大限度地提高獨立性並實現宏架構和微架構之間的分離。

將模塊分成進程，容器或虛擬機允許如每個模塊在不同平臺上以不同的編程語言實現。因此，技術決策僅針對一個模塊。此外，這種分離意味着每個模塊都可以在沒有任何其他模塊崩潰的情況下崩潰。如果所有模塊只是一個過程的一部分，那麼這將是不同的。這有助於彈性能力。

原則四：通信集成

必須對系統的集成和通信選項的選擇進行限制和標準化。可以使用同步或異步通信，並且 / 或者在 UI 級別上進行集成。通信必須使用一組有限的協議，如：RESTful HTTP 或消息傳遞。爲每個集成選項使用一個協議可能是有意義的。

模塊被劃分爲多個進程。因此無法使用本地方法調用集成它們，但需要不同的集成方法。標準意味着創建真正的系統。如果每個模塊的集成方式均不相同，則很難將集成結果視爲一個系統。乍看似乎只有一種融合方式就足夠了。但事實上，集成通常會在 UI 層和邏輯層上完成。這已經需要兩種不同類型的集成。在同一系統中可能存在不同的情況，例如，同步和異步集成可能很有用。通信定義了模塊用於交互的底層協議。當然，通信和集成之間存在關聯。但是例如 REST 允許同步和異步集成。與集成一樣，一種通信選擇可能還不夠。對於通信和集成，原則僅考慮系統內模塊之間的通信。與其他系統的通信可以使用一組不同的集成和通信技術來完成。有時，通信和集成已經定義，因此係統無法更改。系統的公共接口也不同於架構的觀點：更難於更改，因爲更改將影響其他系統。

原則五：身份認證 & 元數據

元數據，例如 對於身份認證，必須標準化。否則，用戶需要登錄每個微服務。這可以使用例如：與每個調用 / 請求一起傳輸的令牌。其他示例可能包括跟蹤調用的跟蹤 ID 及其通過微服務的相關調用。

用戶不必登錄每個模塊，而是登錄到整個系統。因此，傳輸身份驗證信息（包括主體及其角色）也是標準化的一部分。授權與領域邏輯密切相關，應該在每個模塊中完成。因此，每個模塊都可以允許訪問或特定操作。除認證信息之外的其他元數據也可能需要標準化。例如，跟蹤微服務之間的調用，必須傳輸調用和所有相關調用的唯一 ID。

原則六：獨立的持續交付流水線

每個模塊必須有自己獨立的持續交付流水線。測試是持續交付流水線的一部分，因此模塊必須獨立測試。

只有每個模塊都可以自行部署，才能實現真正的獨立性。架構只是一個先決條件。換句話說：如果架構允許獨立模塊，但它們仍然需要作爲一個整體進行部署，那麼該方法僅提供所需獨立性的一部分，但仍然需要花費大量精力。在某些情況下，存在共享集成測試階段。每個模塊最終傳播到此階段並進行獨立測試，即所有其他模塊必須等到該模塊通過集成測試階段。這是部署流水線中的依賴性瓶頸的示例：在模塊通過階段之前，其他流水線無法繼續。必須避免這種情況，例如通過使用消費者驅動的契約測試和通過 Mock 來測試模塊之間的接口，或通過分離集成測試階段。

原則七：標準化運維

運營應該標準化。這包括配置，部署，日誌分析，跟蹤，監控和告警。如果模塊有非常具體的要求，標準可能會有例外。

每個模塊都是一個單獨的進程、容器或虛擬機。運維部門必須處理每一項問題，因此面臨着巨大的挑戰。標準化有助於應對這種複雜性。但是，可能仍然存在具有特殊要求的服務，這些服務可能使用不同的操作方法。另外：在 “You build it - you run it” 組織中，每個團隊都應該負責選擇最適合它們的操作方法。大多數情況下，這仍然是一種標準化方法，因爲這會減少團隊的工作量。請注意，該標準僅涵蓋該技術。當然，每個模塊可能都有自己的一組指標，告警等。ISA 需要高度成熟的運維：大多數運維程序必須自動化。必須處理許多模塊。缺乏這種成熟度可能會導致無法成功實施 ISA。

原則八：標準化

應在接口級別強制執行運維，集成或通信的標準化。例如，通信協議和數據結構可以標準化爲使用 HTTP 交互的特定 JSON 有效載荷格式，但每個模塊應該可以自由使用不同的 REST 庫 / 實現。

在某種程度上，這是模塊化的結果：模塊可能只能通過接口訪問。對於任何標準案例理應如此， 例如：運維。此外，技術水平的標準限制了技術的自由選擇，這是該架構的主要優點。但在某些情況下，可能無法將標準限制爲接口級別。所以該原則只是 “應該”。

原則九：彈性

模塊必須具有彈性：

模塊級別的彈性極大地有助於整個分佈式系統的高可用性的獲得。調度程序也可以選擇重新啓動模塊或將它們移動到其他服務器。模塊必須能夠處理這個問題。

其他原則

ISA（獨立系統架構）是最佳實踐的集合。但是 ISA 沒有定義完整的體系結構。以下內容介紹了不屬於 ISA 的其他原則以及它們被忽略的原因。

ISA 定義了模塊技術層面的內容。但系統如何拆分爲模塊超出 ISA 的範圍。 領域驅動設計和限界上下文是很好的指導原則。但有時技術模塊需要因爲可擴展性等原因的分離也很重要。正確拆分爲模塊非常困難，因此不能輕易地將其放在一些原則中。

架構可以產生巨大的組織和文化影響。該方法允許更好的分離模塊，允許獨立，自組織的團隊。 康威定律指出，軟件架構反映了團隊中的社會邊界，因此組織與架構之間存在着密切的關係。但是，ISA 在不調整組織結構的場景下工作，因此這種想法可以通過這種方式更廣泛地應用。

ISA 不偏好通信協議或運維技術。它陳述了一般原則，而不是具體的技術決策。

遵循這些原則可提供獨立可擴展性，負載平衡和高可用性等優勢。然而，這些好處是遵循原則的結果而非原則本身，所以它們未被明確提及。

這些原則帶來了不一致的數據等問題。這些是分佈式系統的基本挑戰，需要加以解決。這超出了 ISA 的定義。

source: http://kaelzhang81.github.io/2019/08/30/獨立系統架構/
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/e7WLnsRQXv-NVfLyz81mYQ

猜你喜歡