就程序員而言，日后的職業(yè)發(fā)展可以走 3 個(gè)方向：專攻技術(shù)深度、轉(zhuǎn)團(tuán)隊(duì)管理、晉升架構(gòu)師。

成為一名優(yōu)秀的架構(gòu)師，是大多數(shù)技術(shù)人的追求。但資深架構(gòu)師的出現(xiàn)幾率僅約為 0.3%。

如果想在 3-5 年后穩(wěn)坐金字塔尖，必須有扎實(shí)的代碼功底和項(xiàng)目積累，也要意識地培養(yǎng)技術(shù)廣度和架構(gòu)思維能力。多學(xué)習(xí)牛人經(jīng)驗(yàn)也可獲益良多。

圖片

1 同步調(diào)用

同步調(diào)用是指在請求發(fā)起后，調(diào)用方一直阻塞等待調(diào)用處理完成的過程。在所提供的例子中，客戶端代碼 ClientCode 需要執(zhí)行發(fā)送郵件的操作 sendEmail，這會(huì)觸發(fā)對 EmailService 的調(diào)用。

EmailService 將調(diào)用 SmtpEmailAdapter 類來處理請求，而該類會(huì)通過 SMTP 和 TCP 協(xié)議調(diào)用遠(yuǎn)程服務(wù)，將請求發(fā)送到遠(yuǎn)程服務(wù)器。遠(yuǎn)程服務(wù)器收到消息后，會(huì)執(zhí)行一系列操作，然后將郵件發(fā)送出去，并返回結(jié)果。

Adapter 接收到返回后，再將結(jié)果返回給 EmailService。EmailService 收到返回結(jié)果后，再將其返回給 ClientCode。在整個(gè) sendEmail 過程中，ClientCode 會(huì)一直阻塞等待最終調(diào)用結(jié)果的返回，以確定操作是成功還是失敗。由于這個(gè)等待過程是阻塞的，因此被稱為同步調(diào)用。

2  異步調(diào)用

異步調(diào)用與同步調(diào)用相反。在異步調(diào)用的過程中，以發(fā)送郵件的例子為例，用戶 ClientCode 調(diào)用 EmailService 后，EmailService 將調(diào)用請求發(fā)送到消息隊(duì)列，然后立即返回。

ClientCode 在收到返回后可以繼續(xù)向下處理，而不會(huì)繼續(xù)阻塞等待。實(shí)際上，消息被發(fā)送到隊(duì)列后，尚未被處理。在后續(xù)的消息消費(fèi)階段，比 EmailService 的返回可能會(huì)稍晚一些。有一個(gè)消息隊(duì)列消費(fèi)者 QueueConsumer 從消息隊(duì)列中取出消息，然后將其發(fā)送給 SmtpAdapter，即調(diào)用 SmtpAdapter。

處理邏輯與同步調(diào)用類似，SmtpAdapter 通過 SMTP 通信協(xié)議將消息發(fā)送到遠(yuǎn)程服務(wù)器，執(zhí)行郵件發(fā)送操作，通過 RemoteServer 進(jìn)行處理。處理完成后，收到返回結(jié)果后通知消息隊(duì)列 Queue。

在這個(gè)過程中，客戶端的調(diào)用（即應(yīng)用程序的調(diào)用）和實(shí)際的業(yè)務(wù)邏輯（發(fā)送郵件的操作）是異步的。在郵件發(fā)送操作的處理過程中，客戶端代碼已經(jīng)返回，它可以繼續(xù)執(zhí)行自己的后續(xù)操作，而不需要等待郵件的發(fā)送完成，這就是異步調(diào)用。

圖片

使用異步調(diào)用架構(gòu)的主要手段之一是通過消息隊(duì)列來構(gòu)建。以下是該架構(gòu)的圖示：

1. 消息生產(chǎn)者（Message Producer）：負(fù)責(zé)產(chǎn)生消息并將其發(fā)送到消息隊(duì)列。消息生產(chǎn)者是異步的，它發(fā)送完消息后就可以繼續(xù)執(zhí)行其他任務(wù)，而不必等待消息被處理。
2. 消息隊(duì)列（Message Queue）：用于存儲(chǔ)和傳遞消息。消息隊(duì)列作為中介，接收生產(chǎn)者發(fā)送的消息，并將其提供給消費(fèi)者。常見的消息隊(duì)列系統(tǒng)包括 RabbitMQ、Apache Kafka、ActiveMQ 等。
3. 消息消費(fèi)者（Message Consumer）：從消息隊(duì)列中獲取消息并進(jìn)行相應(yīng)的業(yè)務(wù)邏輯處理。與消息生產(chǎn)者一樣，消息消費(fèi)者也是異步的，它可以在獲取消息后立即開始處理，而無需等待消息的產(chǎn)生。

使用消息隊(duì)列構(gòu)建一個(gè)異步調(diào)用架構(gòu)，你需要了解3種角色，一種是消息的生產(chǎn)者，一種是消息隊(duì)列，還有一種是消息的消費(fèi)者。

消息的生產(chǎn)者是客戶端應(yīng)用程序代碼的一部分，用來初始化異步調(diào)用處理流程。

在基于消息隊(duì)列的處理中，生產(chǎn)者的職責(zé)非常少，它要做的就是創(chuàng)建一個(gè)合法的消息，并把這個(gè)消息發(fā)送到消息隊(duì)列中，由應(yīng)用開發(fā)者決定生產(chǎn)者的代碼在哪里執(zhí)行，什么時(shí)候發(fā)送消息。

消息隊(duì)列是消息發(fā)送的目的地，也是消息發(fā)給消費(fèi)者的一個(gè)緩沖區(qū)。實(shí)現(xiàn)消息隊(duì)列的方法有很多種，可以使用共享文件夾，也可以利用關(guān)系數(shù)據(jù)庫或者 NoSQL 系統(tǒng)。

然而，最主要且常見的做法是使用專門的分布式消息隊(duì)列服務(wù)器。這些消息隊(duì)列服務(wù)器被設(shè)計(jì)用于高效地存儲(chǔ)、傳遞和處理大量的異步消息。它們提供了可靠性、可伸縮性和高性能的特性，以滿足不同應(yīng)用場景的需求。

一些流行的分布式消息隊(duì)列系統(tǒng)包括：

1. RabbitMQ：一個(gè)開源的消息隊(duì)列系統(tǒng)，實(shí)現(xiàn)了高級消息隊(duì)列協(xié)議（AMQP）。
2. Apache Kafka：分布式流處理平臺(tái)，具有高吞吐量和可持久性的特點(diǎn)。
3. ActiveMQ：一個(gè)開源的消息和集成模式服務(wù)器，實(shí)現(xiàn)了Java Message Service（JMS）規(guī)范。
4. Amazon SQS（Simple Queue Service）：由亞馬遜提供的托管消息隊(duì)列服務(wù)。
5. Redis：一種內(nèi)存中數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)，也可用作消息代理。

業(yè)務(wù)架構(gòu)的第三個(gè)重要角色就是消息的消費(fèi)者。消息的消費(fèi)者從消息隊(duì)列中接受并處理消息，消息的消費(fèi)者也是由應(yīng)用開發(fā)者實(shí)現(xiàn)的，但是它是一個(gè)異步處理的組件。

圖片

消息的消費(fèi)者不需要知道生產(chǎn)者存在，它只依賴消息隊(duì)列中的消息。消息的消費(fèi)者通常部署在獨(dú)立的服務(wù)器上，和消息的生產(chǎn)者完全隔離，并且可以通過添加硬件的方式進(jìn)行伸縮。

圖片

點(diǎn)對點(diǎn)模型是一種消息傳遞模型，其中消費(fèi)者和生產(chǎn)者只需知道消息隊(duì)列的名稱。在這種模型中，生產(chǎn)者將消息發(fā)送到消息隊(duì)列，而消息隊(duì)列的另一端有多個(gè)消費(fèi)者競爭消費(fèi)消息。

圖片

每個(gè)到達(dá)消息隊(duì)列的消息只會(huì)被路由到一個(gè)消費(fèi)者，因此每個(gè)消費(fèi)者看到的是全部消息的一個(gè)子集。

在這張圖中，有多個(gè)消息生產(chǎn)者和多個(gè)消息消費(fèi)者。多個(gè)生產(chǎn)者將消息發(fā)送到消息隊(duì)列，而多個(gè)消費(fèi)者在消息隊(duì)列中競爭性地消費(fèi)消息。

每條消息只會(huì)被一個(gè)消費(fèi)者消費(fèi)，每個(gè)消費(fèi)者只會(huì)消費(fèi)消息隊(duì)列中的一部分消息。這種點(diǎn)對點(diǎn)的模型適用于需要確保每條消息只被一個(gè)接收者處理的場景，以及在消息生產(chǎn)者和消費(fèi)者之間實(shí)現(xiàn)解耦的需求。

在發(fā)布訂閱模型中，消息可能被發(fā)送到不止一個(gè)消費(fèi)者，生產(chǎn)者發(fā)送消息到一個(gè)主題，而不是隊(duì)列中。

消息被發(fā)布到主題后，就會(huì)被克隆給每一個(gè)訂閱它的消費(fèi)者，每個(gè)消費(fèi)者接收一份消息復(fù)制到自己的私有隊(duì)列。

消費(fèi)者可以獨(dú)立于其他消費(fèi)者使用自己訂閱的消息，消費(fèi)者之間不會(huì)競爭消息。

常用的分布式消息隊(duì)列都支持發(fā)布訂閱模型，也就是說消息的發(fā)布訂閱模型是分布式消息隊(duì)列的一個(gè)功能特性。

圖片

兩種消息傳遞模型通常會(huì)根據(jù)業(yè)務(wù)需求和特點(diǎn)進(jìn)行選擇。點(diǎn)對點(diǎn)模型適用于一些耗時(shí)較長、邏輯相對獨(dú)立的業(yè)務(wù)場景，例如發(fā)送郵件。因?yàn)榘l(fā)送郵件是一個(gè)比較耗時(shí)的操作，應(yīng)用程序?qū)τ卩]件發(fā)送是否成功并不太關(guān)心，而且發(fā)送郵件的邏輯相對獨(dú)立。在這種情況下，應(yīng)用程序只需要把郵件消息放入消息隊(duì)列中就可以立即返回。消費(fèi)者則只需從消息隊(duì)列中取出郵件消息進(jìn)行處理，通過遠(yuǎn)程服務(wù)器將郵件發(fā)送出去。由于每封郵件只需要被發(fā)送一次，因此消息只需要被一個(gè)消費(fèi)者消費(fèi)即可。

圖片

相反，對于一些需要多個(gè)消費(fèi)者協(xié)同處理的、涉及多個(gè)步驟的業(yè)務(wù)，例如新用戶注冊，通常會(huì)選擇發(fā)布訂閱模型。新用戶注冊成功后，可能需要發(fā)送激活郵件、歡迎短信，將用戶注冊數(shù)據(jù)寫入數(shù)據(jù)庫，并將新用戶信息發(fā)送給關(guān)聯(lián)企業(yè)的系統(tǒng)，以實(shí)現(xiàn)一次注冊即可登錄多個(gè)關(guān)聯(lián)產(chǎn)品的需求。在這種情況下，可以使用按主題發(fā)布的方式，即發(fā)布訂閱模型。新用戶注冊消息可以發(fā)布到一個(gè)主題，多個(gè)消費(fèi)者可以訂閱這個(gè)主題，分別處理不同的任務(wù)，如發(fā)送郵件、發(fā)送短信、寫入數(shù)據(jù)庫等。這種模型允許多個(gè)消費(fèi)者同時(shí)對同一消息進(jìn)行處理，實(shí)現(xiàn)了業(yè)務(wù)邏輯的解耦和靈活性的提高。