Adapter是一種軟件工具，它允許在計算機上模擬本地網絡適配器的功能。當我們需要在單臺計算機上模擬多臺計算機之間的網絡連接時，例如進行網絡測試或開發時， Adapter就發揮了重要作用。它的設置和使用相對簡單，只需要在計算機的設備管理器中添加一個新的網絡適配器，選擇安裝 Adapter驅動程序即可。安裝后，系統將生成一個虛擬的網絡適配器，可以將其視為一個虛擬的網絡接口。使用 Adapter，我們可以通過配置IP地址、子網掩碼和默認網關等網絡參數來模擬多個虛擬網絡接口。這樣一來，我們就可以在單臺計算機上模擬多臺機器之間的網絡通信，測試和調試網絡應用程序，同時不受實際網絡環境的限制。另外， Adapter還可以用于創建虛擬的網絡環境，例如在開發環境中模擬局域網（LAN）或廣域網（WAN）的網絡拓撲。這對于開發人員來說特別有用，因為他們可以在不需要真實設備的情況下進行網絡應用程序的測試和調試工作。總之， Adapter是一個非常方便的工具，它允許我們在單臺計算機上模擬多臺機器之間的網絡連接，提供了一個便捷的方法進行網絡應用程序的測試和調試。 它是網絡開發者和測試人員的強大助手，可以節省時間和資源，提高工作效率。
用于軟件架構的 C4 模型
關鍵要點
軟件架構圖是一種非常好的表達方式，可以用它們來表達你將如何構建一個軟件系統（預先設計）或者現有的軟件系統是如何工作的（回顧文檔、知識分享和學習）。
然而，你所看到的大多數軟件架構圖很可能只是由混亂的框和線組成。敏捷軟件開發宣言的一個副作用就是讓很多團隊停止或縮減了他們的圖表和文檔工作，包括使用UML。
現在，這些團隊傾向于依靠他們在白板上繪制的臨時圖表，或者使用通用的圖表工具（如微軟的Visio）。Ionut Balosin 在去年寫了一篇叫作“軟件架構圖的藝術”的文章，他在文章中描述了一些常見問題，這些問題與不可理解的符號和不明確的語義有關。
含糊不清的軟件架構圖容易導致誤解，這可能會拖慢一個優秀團隊的前進步伐。在我們的行業中，我們真的應該努力創建出更好的軟件架構圖。多年來，我自己參與軟件開發，并與世界各地的團隊合作，基于這些經驗，我建立了一個稱之為“C4 模型”的東西。C4 代表上下文（Context）、容器（）、組件（）和代碼（Code）——一系列分層的圖表，可以用這些圖表來描述不同縮放級別的軟件架構，每種圖表都適用于不同的受眾。可以將其視為代碼的谷歌地圖。
要為你的代碼創建地圖，首先需要一組通用的抽象來創建一種無處不在的語言，用來描述軟件系統的靜態結構。C4 模型使用容器（應用程序、數據存儲、微服務等）、組件和代碼來描述一個軟件系統的靜態結構。它還考慮到使用軟件系統的人。
第1 層：系統上下文
第1 層是系統上下文圖，它顯示了你正在構建的軟件系統，以及系統與用戶及其他軟件系統之間的關系。以下是一個系統上下文圖的示例，描述了一個互聯網銀行系統的系統上下文：
銀行的個人客戶使用互聯網銀行系統查看有關銀行賬戶的信息并進行支付。互聯網銀行系統使用銀行現有的大型機銀行系統來執行此操作，并使用銀行現有的電子郵件系統向客戶發送電子郵件。圖中的顏色表示哪些軟件系統已經存在（灰色）以及待構建的系統（藍色）。
第2 層：容器
第2 層是一個容器圖，將軟件系統放大，顯示組成該軟件系統的容器（應用程序、數據存儲、微服務等）。技術決策也是該圖的關鍵部分。以下是互聯網銀行系統的容器圖示例。它顯示了互聯網銀行系統（虛線框）由五個容器組成：服務器端Web 應用程序、客戶端單頁面應用程序、移動應用程序、服務器端API 應用程序和數據庫。
Web 應用程序是一個 Java/Spring MVC Web 應用程序，它僅提供靜態內容（HTML、CSS 和 ），包括組成單頁應用程序的內容。單頁面應用程序是一個運行在客戶網絡瀏覽器中的 Angular 應用程序，提供所有的網上銀行功能。或者，客戶可以使用跨平臺 Xamarin 移動應用程序訪問互聯網銀行的部分功能。單頁應用程序和移動應用程序都調用 JSON/HTTPS API，這是由服務器端運行的另一個 Java/Spring MVC 應用程序提供的。API 應用程序從數據庫中獲取用戶信息（關系數據庫模式）。API 應用程序還使用專有的 XML/HTTPS 接口與現有的大型機銀行系統進行通信，以獲取有關銀行賬戶或交易的信息。如果需要向客戶發送電子郵件，API 應用程序還會調用現有的電子郵件系統。
第 3 層：組件
第 3 層是組件圖，將單個容器放大，以顯示其中的組件。這些組件映射到代碼庫中的真實抽象（例如一組代碼）。下面是一個虛擬的網上銀行系統的組件圖示例，顯示了 API 應用程序中的一些組件（而不是全部）。
兩個Spring MVC REST 控制器為JSON/HTTPS API 提供訪問點，每個控制器隨后使用其他組件訪問數據庫和大型機銀行系統中的數據。
第4 層：代碼
最后，如果你確實想要，或者說有這個必要，可以放大個別組件，以顯示該組件的實現方式。以下是一個虛擬的網上銀行系統的UML 類圖示例（部分），顯示了組成 組件的代碼元素（接口和類）。
它表明該組件由很多類組成，實現細節直接反映了代碼。我并不建議創建在這種詳細程度的圖表，有時候你可以直接從大多數IDE 中獲取它們。
符號
C4 模型沒有預定義任何特定的符號，你在這些示例圖中看到的是一個個簡單的符號，適用于白板、紙張、便簽、索引卡片和各種圖表工具。你也可以使用 UML 作為符號，并適當使用包、組件和原型。無論你使用哪種符號，我都會建議讓每個元素都包含名稱、元素類型（即“人”、“軟件系統”，“容器”或“組件”）、技術選型（如果有的話），以及一些描述性文字。在圖表中包含如此多的文本可能看起來很不尋常，但這些附加文本有助于消除軟件架構圖中通常會出現的不明確的表示。
即使符號對你來說是顯而易見的，仍然要確保為這些符號提供圖例。圖例中應該包括顏色、形狀、首字母縮略詞、線條樣式、邊框、尺寸等。理想情況下，符號應該在每個細節層次上保持一致。下面是前面顯示的容器圖的圖例。
最后，不要忘記了標題，它應該出現在每個圖表上，以明確地描述每個圖表的類型和范圍（例如，“網上銀行系統的系統上下文圖表”）。