（翻譯自Martin Sústrik的ZeroMQ一文中的Architecture Overview）
首先我們來看一下ZeroMQ的結構圖：
用戶使用使用套接字socket來和ZeroMQ打交道。這些套接字有點像TCP的套接字，他們之間的最主要的差別在於，ZeroMQ的單個套接字可以處理和多個套接字的通信，有點像UDP套接字的行爲。
這些socket對象存在於用戶線程中。除此之外，ZeroMQ運行着許多worker線程。這些worker線程處理異步通信、從網絡中讀取數據、把消息放入隊列、接受外來的連接請求等。
有各種各樣的對象存在於worker線程中。每一個這種對象被特定的一個父對象所擁有。相對於子對象，父對象可以存在於不同的線程中。大多數對象直接歸屬於socket。我們能得到一棵對象樹，對於每一個socket便有這麼一棵樹。這棵樹在關閉過程中會用到。沒有哪一個對象可以關閉自己知道它關閉了它的所有子對象。這種方式確保我們能按照預期的方式關閉程序。例如，懸掛的還沒傳送出去的消息會在傳送過程被終結時優先被傳送到網絡上去。
大致地來說，存在兩種異步對象：介入消息傳送的對象和不介入消息傳送的對象。不介入消息傳送的對象必須處理連接的管理。例如，一個TCP監聽對象監聽外來的TCP連接請求併爲每一個新的連接創建一個engine/session對象。同樣的，當一個TCP連接對象試圖連接到一個TCP端併成功連接後，它會創建一個engine/session對象來管理這個連接。當這個連接失敗時，這個連接對象便會試着去恢復這個連接。
而介入消息傳送的對象則負責處理數據傳輸。這些對象由兩部分組成：session對象負責和ZeroMQ 的socket對話，而engine對象負責網絡上的通信。只存在着一種session對象，而對每一種ZeroMQ支持的底層通信協議都相對應存在一種engine類型。因此，我們有TCP engines, IPC engines, PGM engines等等。這個engines的集合是可以擴展的——在未來我們也許會做一些擴展，比如說，添加一個WebSocket engine 或者一個叫 SCTP 的engine。
session對象和套接字socket交互消息。存在着兩個方向傳遞信息並且每一個方向的傳遞由一個pipe對象來處理(如上圖)。每一個pipe基本上是被優化過的無鎖隊列從而可以更快地在線程之間傳遞消息。
最後，還有一個context對象，它持有全局狀態，並可被所有的socket和所有的異步對象獲取。