獨立系統(tǒng)架構

簡介

獨立系統(tǒng)架構（ISA，Independent Systems Architecture）是基于經(jīng)驗的最佳實踐的集合，特別是微服務和自包含系統(tǒng)以及這些項目所面臨的挑戰(zhàn)。

通常采用微服務的項目都未能成功。這套最佳實踐可確保避免常見的陷阱，并實現(xiàn)微服務所承諾的優(yōu)勢。

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

術語

這些原則中對于不能在系統(tǒng)中妥協(xié)且必須存在于系統(tǒng)中的方面使用“必須”?！皯摗庇糜诰哂泻芏嗪锰幍脑瓌t，但在某些情況下可以省略。這里描述的原則談論一個系統(tǒng)。通常在企業(yè)的IT環(huán)境中會包含許多系統(tǒng)。，每個系統(tǒng)可能使用不同的原則構建，甚至可能采用完全不同的方法。

原則

原則一：模塊

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

系統(tǒng)必須分為提供接口的模塊。只能通過這些接口訪問其他模塊。因此，模塊不能直接依賴于其他模塊的實現(xiàn)細節(jié)，例如：數(shù)據(jù)庫中的內(nèi)部數(shù)據(jù)表示。其余原則定義了如何實現(xiàn)模塊，以及ISA與其他模塊化方法有何不同。

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

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

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

• 宏架構包含涵蓋所有模塊的決策。所有進一步的原則都是宏架構的一部分。

• 微架構考慮可以針對每個模塊單獨進行的決策

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

原則三：容器

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

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

原則四：通信集成

必須對系統(tǒng)的集成和通信選項的選擇進行限制和標準化?？梢允褂猛交虍惒酵ㄐ?，并且/或者在UI級別上進行集成。通信必須使用一組有限的協(xié)議，如：RESTful HTTP或消息傳遞。為每個集成選項使用一個協(xié)議可能是有意義的。

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

原則五：身份認證&元數(shù)據(jù)

元數(shù)據(jù)，例如 對于身份認證，必須標準化。否則，用戶需要登錄每個微服務。這可以使用例如：與每個調(diào)用/請求一起傳輸?shù)牧钆啤Ｆ渌纠赡馨ǜ櫿{(diào)用的跟蹤ID及其通過微服務的相關調(diào)用。

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

原則六：獨立的持續(xù)交付流水線

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

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

原則七：標準化運維

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

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

原則八：標準化

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

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

原則九：彈性

模塊必須具有彈性：

• 它們必須對不可用的模塊或通信問題進行補償。

• 它們必須能夠應對意外停機而不會丟失數(shù)據(jù)或狀態(tài)。

• 必須可以將它們移動到其他運行時環(huán)境（主機，網(wǎng)絡，配置等）。

模塊級別的彈性極大地有助于整個分布式系統(tǒng)的高可用性的獲得。調(diào)度程序也可以選擇重新啟動模塊或?qū)⑺鼈円苿拥狡渌掌?。模塊必須能夠處理這個問題。

其他原則

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

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

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

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

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

這些原則帶來了不一致的數(shù)據(jù)等問題。這些是分布式系統(tǒng)的基本挑戰(zhàn)，需要加以解決。這超出了ISA的定義。

source: http://kaelzhang81.github.io/2019/08/30/獨立系統(tǒng)架構/

喜歡，在看