技術架構圖提供了您組織的基礎架構的鳥瞰圖。 該圖說明了系統中的組件如何在大型事物中相互交互。

[[332522]]

有多種服務于不同目的的架構圖。 通常，數字解決方案架構師會草擬高層架構圖，以促進技術解決方案設計。 架構圖有兩個主要優點：

• 它們有助于理解-提供可用系統和交互的概述，這有助于輕松地從更改中評估影響。
• 它們改善了溝通與協作-跨項目和利益相關者調整實施計劃，以減少溝通差距。 有用的架構圖應在一定程度上滿足利益相關者的每個需求。

在本文中，我將介紹五種架構圖，這些架構圖對我設計和實施數字解決方案非常有用。 他們是：

• 應用架構圖
• 集成架構圖
• 部署架構圖
• DevOps架構圖
• 數據架構圖

快速說明：優秀的做法通常因組織而異。 我將從AWS云的角度分享在實施云基礎架構解決方案方面對我有用的東西。

就像軟件代碼一樣，在系統變得龐大和復雜之前，通常會忽略結構良好的架構的有用性。 有用的架構圖將這三個組件結合在一起：

• 標準化的信息處理流程，例如 自上而下的讀數-指示組件之間如何交互。
• 通過邏輯分組在組件中提供足夠的信息-這表明約束位于何處，例如 網絡邊界。
• 包括帶有更多信息的注釋-稍微多一些細節的步驟，以促進解決方案的實施，例如 進度解析。

我將嘗試提供一些上下文和示例，說明如何使用每個圖表來幫助解決方案的設計和實現。

#1：應用程序架構圖

應用程序架構圖包括系統內組件和基本交互的高級概述，例如 微服務，數據庫等

應用程序體系結構圖主要解決與系統有關的"內容"。

此圖的常見用法是通過評估升級，替換或合并現有應用程序的影響來促進計劃和解決方案的實施。 隨著新應用程序不斷投放市場，并有望提高效率和降低成本(尤其是在集裝箱化領域)，對系統中的應用程序進行概述至關重要。

例如，由于各種原因，您的應用程序可能駐留在多個容器集群中，即裸機Kubernetes，AWS ECS等。 并且您的任務是合并和合并應用程序以使用單個容器管理平臺，例如 裸機Kubernetes可以優化成本并簡化多云環境中的運營。 首先，您可能會想到以下一些問題：

• 每個群集中都有哪些類型的應用程序?
• 應用程序的依賴性和交互作用是什么?
• 架構的預期結果和預期狀態是什么?

下面的示例圖說明了應用程序體系結構的現狀。 圖的"邏輯層"中的組件解決了前兩點。

 

 

> Sample Diagram by Author

解決了這些問題后，假設計劃將AWS ECS集群應用程序合并到Kubernetes集群中，那么有幾個操作項需要基于該圖的各利益相關方的輸入。

例如，您可以聯系項目經理以檢查合作伙伴集成的類型，例如 內部/外部，DevOps檢查密鑰和配置管理，以及系統工程師檢查群集的組織方式等，以協助進行影響分析。

從各利益相關者那里獲得相關信息后，您便可以根據重要考慮因素來建立所需的/將來的架構和實施計劃狀態。

該圖中的有用組件：

• 將組件分為層次和有界的上下文-每個邊界都可能暗示一個不同的利益相關者組，例如 數據層的數據工程師，公共/共享服務的核心平臺團隊等，提供了誰參與計劃/討論的想法。
• 帶有附加信息的注釋-提供有關如何管理和組織每個群集的更多詳細信息，例如 基于應用程序的性質和安全性等方面的考慮，可能會包含一些內容以促進討論。
• 應用程序詳細信息和上下文-說明應用程序的名稱和類型，以提供有關如何組織應用程序的想法

您可以在此處下載上圖的樣本。

#2：集成架構圖

集成體系結構圖與應用程序體系結構圖非常相似，不同之處在于它特別強調了組件之間的集成協議，例如： 批處理，事件，REST / SOAP / XML等

集成架構圖解決了系統中組件互連的"方式"。

此圖的常見用法是促進合作伙伴或其他內部系統對外部系統的集成。 如今，隨著企業通過生態系統建立新的合作伙伴關系來創造共同的價值，您可能經常需要與合作伙伴一起將系統集成在一起，例如 電子商務，付款，酒店預訂，航班等

例如，有一個合作伙伴擁有一個旅行應用程序，該應用程序希望在其應用程序上列出您的產品目錄，以增加其消費者的選擇范圍。 您的任務是與合作伙伴解決方案架構師合作，以促進系統集成以向您提供服務。 合作伙伴更喜歡通過REST API使用服務。

您可能會想到以下一些問題：

• 目前我的服務在內部/外部如何組織和公開?
• 合作伙伴如何與我的系統集成，例如 內部網絡，協議等?
• 如何保護，跟蹤和管理暴露服務的集成?

下面的集成圖(高層)說明了組件之間的現有通信協議。 您還將看到如何通過邏輯層的外部API網關向第三方開發人員公開某些服務。

 

 

> Diagram by Author

從上圖，您將意識到該系統被設計為由API驅動，因此易于集成。 幾乎所有服務都是通過Web服務公開的，包括數據存儲組件。

下一步是與合作伙伴一起檢查他們所需的服務列表，例如集成方式。 內部或外部，并將需求與通過API目錄公開的服務進行交叉引用。 還有一些后續操作項目，即與系統工程師一起確定公開服務的安全性和監視。

有時，可能存在需求缺口，例如合作伙伴希望在外部進行集成，但是您的服務僅在內部公開，或者缺少某些數據屬性。 在這種情況下，必須考慮到滿足要求的努力。 集成圖必須突出顯示詳細信息，即內部服務/ API，API目錄的鏈接等，以快速識別此類差距。

該圖中的有用組件：

• 將組件分為層和有界上下文-內部/外部API網關和服務的指示
• 帶有附加信息的注釋-API目錄的參考鏈接，可在其中獲得詳細的服務數據屬性以評估差距
• 應用程序詳細信息和上下文-對服務進行適當命名，以允許快速評估需求。 實際

您可以在此處下載上圖的樣本。

#3：部署架構圖

部署架構圖由網絡邊界和基礎架構硬件/軟件組件組成。 有時還會指定組件的大小和數量，以方便規劃。

部署體系結構主要針對系統中的組件處理"位置"和"數量"。

此圖的常見用法是促進應用程序和服務的升級，以處理額外的負載或優化資源。 隨著時間的流逝，隨著來自世界各地的更多用戶開始使用您的應用程序和服務，您現有的資源可能無法處理規模和負載的增加。

例如，您的API網關當前部署在單個大型EC2實例(t2.xlarge)中，并且由于性能最近遇到了間歇性的服務中斷。 您的任務是將API網關轉換為具有多個可用區(AZ)的群集設置(使用新計算機)，以提高網關的可用性。 您可能會想到的一些問題是：

• 多少個AZ?
• 在哪里部署實例?
• 新實例有多大?

下面的部署體系結構說明了網絡和組件的當前設置。 ap-southeast-1中具有API網關實例的當前應用程序有兩個可用區。

 

 

> Diagram by Author

根據上圖，您將能夠獲取有關API網關實例的現有尺寸的信息，例如 (t2.xlarge)，用作新實例大小調整的基準。 在同一可用性區域中，還有一個標記為API Gateway實例的對應數據庫實例。

該圖還可以促使人們進一步討論新實例的位置，即私有子網2b或2c等，或者是否可能有進一步計劃來整合AWS Core Platform上所有服務的中央API網關以集中API 管理。

下一步將基于各種實施計劃(即集中式API管理或分散式管理等)估算影響，并向管理層和相關利益相關者提出評估建議。

通常有多種方法可以解決此類性能問題。 如果您在大型組織中，那么通過中央架構委員會調整方法以進行適當的架構管理非常重要。

該圖中的有用組件：

• 網絡邊界-展示組件的隔離和潛在的連接影響。
• 實例大小確定—表示機器的大小確定，以便于根據性能要求對資源進行優化和基準測試。
• 顯示外部集成的各個部分-展示系統對其他系統和網絡的擴展(如果有的話)，以顯示更大的圖景，并促進資源精簡(即公共/共享服務等)和協作機會的簡化。

您可以在此處下載上圖的樣本。

#4：DevOps架構圖

DevOps體系結構圖通常包含系統組件，流程和環境。 該圖類似于過程流程圖，該過程流程圖說明了將代碼庫/應用發布到生產環境的操作。

DevOps體系結構主要解決與流程和部署流程優化有關的"如何"和"什么"。

此圖的常見用法是促進有關應用程序部署的流程的改進。 系統架構的不斷變化和部署工具/方法的改進，例如 容器，無服務器等提示需要適應現有的DevOps體系結構和流程以適應時代的發展。

例如，應用程序管理，例如 您團隊的配置等目前尚未跨平臺標準化，您的任務是探索一種新工具(棲息地)的實施方式，以有效管理應用程序。 您可能會想到的一些問題是：

• 當前的流程是什么?
• 當前如何跨應用程序管理配置?
• 要部署的應用程序類型是什么?

下面的DevOps架構說明了跨環境將應用程序部署到Kubernetes集群中的流程。 對于不同的應用程序類型，該圖可能有多種變體。

 

 

> Diagram by Author

根據上圖，您將能夠獲取有關DevOps流程各個階段的信息，以識別可通過新工具(例如， 配置管理或集成點以合并新工具。

各種應用程序類型的DevOps圖表可能會促使進行進一步的討論，以探索潛在的新流程和工具集，以滿足團隊的需求。

下一步將是讓各利益攸關方參與，討論流程和工具的改進以及實施人居署對現有業務的潛在影響，例如： 需要新的插件，等等。

對于大型組織而言，流程要復雜得多，并且要考慮整個環境的安全問題，從而嚴重限制了資源的部署。 還有許多遺留應用程序遵循舊的部署方法。 建議記錄不同應用程序變體的流程，并從整體上看待它們，以提高效率。

該圖中的有用組件：

• 在整個環境中展示流程-DevOps通常跨環境，并且顯示應用程序升級流程通常很有用。
• 帶有附加信息的注釋-可以包括各個階段和過程的更多詳細信息，以促進討論和規劃。
• 決策網關和用戶流程-DevOps不僅包括系統組件，而且還涉及很大一部分人為因素以建立良好的DevOps文化。 人為過程的組成部分不容忽視。

您可以在此處下載上圖的樣本。 另外，這是31種DevOps參考架構的列表。

#5：數據架構圖

數據體系結構圖包含系統內的組件，這些組件定義了如何收集，處理，存儲和使用數據。 該圖還說明了IT基礎架構內跨系統組件的數據流。

數據體系結構圖涉及與數據的處理，流和使用有關的"如何"和"在哪里"。

該圖的用例之一是促進資源升級以優化數據收集和存儲成本。 隨著當今捕獲的數據量的增加和數據存儲成本的降低，企業的數據架構必然會不斷調整。

例如，從API網關捕獲的日志數據當前存儲在MySQL數據庫中，并在Web儀表板上可視化。 隨著數據庫中數據的不斷積累，查詢變得越來越慢，成本也越來越高。 您的任務是解決性能問題，并為將來來自其他應用程序的數據集的機器學習和分析功能奠定基礎。 您可能會想到一些問題：

• 當前如何處理數據?
• 數據在哪里存儲和使用?
• 我們在談論多少數據?

下面的數據架構說明了從源到存儲和可視化的數據流。 在某些情況下，在圖表中包括新組件以顯示更改以方便討論可能會很有用。

 

 

> Diagram by Author

下一步可能是讓利益相關者參與討論實施細節，例如 數據保留期，績效要求，業務目標和見解，數據結構和模型，成本估算等。

該圖中的有用組件：

• 顯示原樣和將來的組件-快速概覽更改，以評估影響并重點討論要點。
• 數據增量率的指示-使利益相關者對數據規模有所了解，以進行估計和解決方案設計。
• 組件的邏輯分組-說明了各個階段的組件目標，例如 處理，可視化等，以簡化可讀性。

您可以在此處下載參考圖的樣本。

總結

• 應用程序體系結構圖提供了組件的高層概述，以基于升級，替換和合并應用程序的影響評估的形式促進規劃。
• 集成體系結構圖著重于應用程序組件之間的集成協議，以促進內部/外部合作伙伴系統的集成。
• 部署體系結構圖突出顯示了網絡邊界和基礎結構組件的大小，以便于出于優化目的對應用程序和服務進行計劃和升級。
• DevOps體系結構圖說明了跨部署環境的涉及系統和人員的流程流，以促進流程改進和自動化。

這些圖經常在數字解決方案設計中一起使用，因為它們相互補充，從而為利益相關者提供系統的圖片。

但是，請記住，地圖不是領土。 鑒于活動部件和變更的數量，幾乎不可能記錄系統的每個部件。 我遇到過許多實例，由于各種原因，這些更改和組件未在圖中捕獲。 準備應對這種情況。

另外，為滿足不同的目的，有很多不同的架構圖(基于Google圖像)可以滿足需要-沒有固定的方式繪制架構圖。 我在這里提供的是示例準則和原則，可幫助您更好地了解系統，以制定出可能的解決方案。

歸根結底，這些圖是促進交流和理解的工具，并且必須根據您的團隊的需求和風格來定制圖。

感謝您的閱讀，希望您從本文中有所收獲!