技術(shù)架構(gòu)圖提供了您組織的基礎(chǔ)架構(gòu)的鳥瞰圖。 該圖說明了系統(tǒng)中的組件如何在大型事物中相互交互。

[[332522]]

有多種服務(wù)于不同目的的架構(gòu)圖。 通常，數(shù)字解決方案架構(gòu)師會草擬高層架構(gòu)圖，以促進(jìn)技術(shù)解決方案設(shè)計(jì)。 架構(gòu)圖有兩個(gè)主要優(yōu)點(diǎn)：

• 它們有助于理解-提供可用系統(tǒng)和交互的概述，這有助于輕松地從更改中評估影響。
• 它們改善了溝通與協(xié)作-跨項(xiàng)目和利益相關(guān)者調(diào)整實(shí)施計(jì)劃，以減少溝通差距。 有用的架構(gòu)圖應(yīng)在一定程度上滿足利益相關(guān)者的每個(gè)需求。

在本文中，我將介紹五種架構(gòu)圖，這些架構(gòu)圖對我設(shè)計(jì)和實(shí)施數(shù)字解決方案非常有用。 他們是：

• 應(yīng)用架構(gòu)圖
• 集成架構(gòu)圖
• 部署架構(gòu)圖
• DevOps架構(gòu)圖
• 數(shù)據(jù)架構(gòu)圖

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

就像軟件代碼一樣，在系統(tǒng)變得龐大和復(fù)雜之前，通常會忽略結(jié)構(gòu)良好的架構(gòu)的有用性。 有用的架構(gòu)圖將這三個(gè)組件結(jié)合在一起：

• 標(biāo)準(zhǔn)化的信息處理流程，例如 自上而下的讀數(shù)-指示組件之間如何交互。
• 通過邏輯分組在組件中提供足夠的信息-這表明約束位于何處，例如 網(wǎng)絡(luò)邊界。
• 包括帶有更多信息的注釋-稍微多一些細(xì)節(jié)的步驟，以促進(jìn)解決方案的實(shí)施，例如 進(jìn)度解析。

我將嘗試提供一些上下文和示例，說明如何使用每個(gè)圖表來幫助解決方案的設(shè)計(jì)和實(shí)現(xiàn)。

#1：應(yīng)用程序架構(gòu)圖

應(yīng)用程序架構(gòu)圖包括系統(tǒng)內(nèi)組件和基本交互的高級概述，例如 微服務(wù)，數(shù)據(jù)庫等

應(yīng)用程序體系結(jié)構(gòu)圖主要解決與系統(tǒng)有關(guān)的"內(nèi)容"。

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

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

• 每個(gè)群集中都有哪些類型的應(yīng)用程序?
• 應(yīng)用程序的依賴性和交互作用是什么?
• 架構(gòu)的預(yù)期結(jié)果和預(yù)期狀態(tài)是什么?

下面的示例圖說明了應(yīng)用程序體系結(jié)構(gòu)的現(xiàn)狀。 圖的"邏輯層"中的組件解決了前兩點(diǎn)。

 

 

> Sample Diagram by Author

解決了這些問題后，假設(shè)計(jì)劃將AWS ECS集群應(yīng)用程序合并到Kubernetes集群中，那么有幾個(gè)操作項(xiàng)需要基于該圖的各利益相關(guān)方的輸入。

例如，您可以聯(lián)系項(xiàng)目經(jīng)理以檢查合作伙伴集成的類型，例如 內(nèi)部/外部，DevOps檢查密鑰和配置管理，以及系統(tǒng)工程師檢查群集的組織方式等，以協(xié)助進(jìn)行影響分析。

從各利益相關(guān)者那里獲得相關(guān)信息后，您便可以根據(jù)重要考慮因素來建立所需的/將來的架構(gòu)和實(shí)施計(jì)劃狀態(tài)。

該圖中的有用組件：

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

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

#2：集成架構(gòu)圖

集成體系結(jié)構(gòu)圖與應(yīng)用程序體系結(jié)構(gòu)圖非常相似，不同之處在于它特別強(qiáng)調(diào)了組件之間的集成協(xié)議，例如： 批處理，事件，REST / SOAP / XML等

集成架構(gòu)圖解決了系統(tǒng)中組件互連的"方式"。

此圖的常見用法是促進(jìn)合作伙伴或其他內(nèi)部系統(tǒng)對外部系統(tǒng)的集成。 如今，隨著企業(yè)通過生態(tài)系統(tǒng)建立新的合作伙伴關(guān)系來創(chuàng)造共同的價(jià)值，您可能經(jīng)常需要與合作伙伴一起將系統(tǒng)集成在一起，例如 電子商務(wù)，付款，酒店預(yù)訂，航班等

例如，有一個(gè)合作伙伴擁有一個(gè)旅行應(yīng)用程序，該應(yīng)用程序希望在其應(yīng)用程序上列出您的產(chǎn)品目錄，以增加其消費(fèi)者的選擇范圍。 您的任務(wù)是與合作伙伴解決方案架構(gòu)師合作，以促進(jìn)系統(tǒng)集成以向您提供服務(wù)。 合作伙伴更喜歡通過REST API使用服務(wù)。

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

• 目前我的服務(wù)在內(nèi)部/外部如何組織和公開?
• 合作伙伴如何與我的系統(tǒng)集成，例如 內(nèi)部網(wǎng)絡(luò)，協(xié)議等?
• 如何保護(hù)，跟蹤和管理暴露服務(wù)的集成?

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

 

 

> Diagram by Author

從上圖，您將意識到該系統(tǒng)被設(shè)計(jì)為由API驅(qū)動(dòng)，因此易于集成。 幾乎所有服務(wù)都是通過Web服務(wù)公開的，包括數(shù)據(jù)存儲組件。

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

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

該圖中的有用組件：

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

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

#3：部署架構(gòu)圖

部署架構(gòu)圖由網(wǎng)絡(luò)邊界和基礎(chǔ)架構(gòu)硬件/軟件組件組成。 有時(shí)還會指定組件的大小和數(shù)量，以方便規(guī)劃。

部署體系結(jié)構(gòu)主要針對系統(tǒng)中的組件處理"位置"和"數(shù)量"。

此圖的常見用法是促進(jìn)應(yīng)用程序和服務(wù)的升級，以處理額外的負(fù)載或優(yōu)化資源。 隨著時(shí)間的流逝，隨著來自世界各地的更多用戶開始使用您的應(yīng)用程序和服務(wù)，您現(xiàn)有的資源可能無法處理規(guī)模和負(fù)載的增加。

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

• 多少個(gè)AZ?
• 在哪里部署實(shí)例?
• 新實(shí)例有多大?

下面的部署體系結(jié)構(gòu)說明了網(wǎng)絡(luò)和組件的當(dāng)前設(shè)置。 ap-southeast-1中具有API網(wǎng)關(guān)實(shí)例的當(dāng)前應(yīng)用程序有兩個(gè)可用區(qū)。

 

 

> Diagram by Author

根據(jù)上圖，您將能夠獲取有關(guān)API網(wǎng)關(guān)實(shí)例的現(xiàn)有尺寸的信息，例如 (t2.xlarge)，用作新實(shí)例大小調(diào)整的基準(zhǔn)。 在同一可用性區(qū)域中，還有一個(gè)標(biāo)記為API Gateway實(shí)例的對應(yīng)數(shù)據(jù)庫實(shí)例。

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

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

通常有多種方法可以解決此類性能問題。 如果您在大型組織中，那么通過中央架構(gòu)委員會調(diào)整方法以進(jìn)行適當(dāng)?shù)募軜?gòu)管理非常重要。

該圖中的有用組件：

• 網(wǎng)絡(luò)邊界-展示組件的隔離和潛在的連接影響。
• 實(shí)例大小確定—表示機(jī)器的大小確定，以便于根據(jù)性能要求對資源進(jìn)行優(yōu)化和基準(zhǔn)測試。
• 顯示外部集成的各個(gè)部分-展示系統(tǒng)對其他系統(tǒng)和網(wǎng)絡(luò)的擴(kuò)展(如果有的話)，以顯示更大的圖景，并促進(jìn)資源精簡(即公共/共享服務(wù)等)和協(xié)作機(jī)會的簡化。

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

#4：DevOps架構(gòu)圖

DevOps體系結(jié)構(gòu)圖通常包含系統(tǒng)組件，流程和環(huán)境。 該圖類似于過程流程圖，該過程流程圖說明了將代碼庫/應(yīng)用發(fā)布到生產(chǎn)環(huán)境的操作。

DevOps體系結(jié)構(gòu)主要解決與流程和部署流程優(yōu)化有關(guān)的"如何"和"什么"。

此圖的常見用法是促進(jìn)有關(guān)應(yīng)用程序部署的流程的改進(jìn)。 系統(tǒng)架構(gòu)的不斷變化和部署工具/方法的改進(jìn)，例如 容器，無服務(wù)器等提示需要適應(yīng)現(xiàn)有的DevOps體系結(jié)構(gòu)和流程以適應(yīng)時(shí)代的發(fā)展。

例如，應(yīng)用程序管理，例如 您團(tuán)隊(duì)的配置等目前尚未跨平臺標(biāo)準(zhǔn)化，您的任務(wù)是探索一種新工具(棲息地)的實(shí)施方式，以有效管理應(yīng)用程序。 您可能會想到的一些問題是：

• 當(dāng)前的流程是什么?
• 當(dāng)前如何跨應(yīng)用程序管理配置?
• 要部署的應(yīng)用程序類型是什么?

下面的DevOps架構(gòu)說明了跨環(huán)境將應(yīng)用程序部署到Kubernetes集群中的流程。 對于不同的應(yīng)用程序類型，該圖可能有多種變體。

 

 

> Diagram by Author

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

各種應(yīng)用程序類型的DevOps圖表可能會促使進(jìn)行進(jìn)一步的討論，以探索潛在的新流程和工具集，以滿足團(tuán)隊(duì)的需求。

下一步將是讓各利益攸關(guān)方參與，討論流程和工具的改進(jìn)以及實(shí)施人居署對現(xiàn)有業(yè)務(wù)的潛在影響，例如： 需要新的插件，等等。

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

該圖中的有用組件：

• 在整個(gè)環(huán)境中展示流程-DevOps通?？绛h(huán)境，并且顯示應(yīng)用程序升級流程通常很有用。
• 帶有附加信息的注釋-可以包括各個(gè)階段和過程的更多詳細(xì)信息，以促進(jìn)討論和規(guī)劃。
• 決策網(wǎng)關(guān)和用戶流程-DevOps不僅包括系統(tǒng)組件，而且還涉及很大一部分人為因素以建立良好的DevOps文化。 人為過程的組成部分不容忽視。

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

#5：數(shù)據(jù)架構(gòu)圖

數(shù)據(jù)體系結(jié)構(gòu)圖包含系統(tǒng)內(nèi)的組件，這些組件定義了如何收集，處理，存儲和使用數(shù)據(jù)。 該圖還說明了IT基礎(chǔ)架構(gòu)內(nèi)跨系統(tǒng)組件的數(shù)據(jù)流。

數(shù)據(jù)體系結(jié)構(gòu)圖涉及與數(shù)據(jù)的處理，流和使用有關(guān)的"如何"和"在哪里"。

該圖的用例之一是促進(jìn)資源升級以優(yōu)化數(shù)據(jù)收集和存儲成本。 隨著當(dāng)今捕獲的數(shù)據(jù)量的增加和數(shù)據(jù)存儲成本的降低，企業(yè)的數(shù)據(jù)架構(gòu)必然會不斷調(diào)整。

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

• 當(dāng)前如何處理數(shù)據(jù)?
• 數(shù)據(jù)在哪里存儲和使用?
• 我們在談?wù)摱嗌贁?shù)據(jù)?

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

 

 

> Diagram by Author

下一步可能是讓利益相關(guān)者參與討論實(shí)施細(xì)節(jié)，例如 數(shù)據(jù)保留期，績效要求，業(yè)務(wù)目標(biāo)和見解，數(shù)據(jù)結(jié)構(gòu)和模型，成本估算等。

該圖中的有用組件：

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

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

總結(jié)

• 應(yīng)用程序體系結(jié)構(gòu)圖提供了組件的高層概述，以基于升級，替換和合并應(yīng)用程序的影響評估的形式促進(jìn)規(guī)劃。
• 集成體系結(jié)構(gòu)圖著重于應(yīng)用程序組件之間的集成協(xié)議，以促進(jìn)內(nèi)部/外部合作伙伴系統(tǒng)的集成。
• 部署體系結(jié)構(gòu)圖突出顯示了網(wǎng)絡(luò)邊界和基礎(chǔ)結(jié)構(gòu)組件的大小，以便于出于優(yōu)化目的對應(yīng)用程序和服務(wù)進(jìn)行計(jì)劃和升級。
• DevOps體系結(jié)構(gòu)圖說明了跨部署環(huán)境的涉及系統(tǒng)和人員的流程流，以促進(jìn)流程改進(jìn)和自動(dòng)化。

這些圖經(jīng)常在數(shù)字解決方案設(shè)計(jì)中一起使用，因?yàn)樗鼈兿嗷パa(bǔ)充，從而為利益相關(guān)者提供系統(tǒng)的圖片。

但是，請記住，地圖不是領(lǐng)土。 鑒于活動(dòng)部件和變更的數(shù)量，幾乎不可能記錄系統(tǒng)的每個(gè)部件。 我遇到過許多實(shí)例，由于各種原因，這些更改和組件未在圖中捕獲。 準(zhǔn)備應(yīng)對這種情況。

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

歸根結(jié)底，這些圖是促進(jìn)交流和理解的工具，并且必須根據(jù)您的團(tuán)隊(duì)的需求和風(fēng)格來定制圖。

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