上一篇：【Go實現】實踐GoF的23種設計模式：裝飾者模式

簡單的分布式應用系統（示例代碼工程）：https://github.com/ruanrunxue/Practice-Design-Pattern--Go-Implementation

簡介

現在有 2 個服務，Service A 和 Service B，通過 REST 接口通信；Service A 在某個業務場景下調用 Service B 的接口完成一個計算密集型任務，假設接口為 http://service_b/api/v1/domain；該任務運行時間很長，但 Service A 不想一直阻塞在接口調用上。為了滿足 Service A 的要求，通常有 2 種方案：

1. Service A 隔一段時間調用一次 Service B 的接口，如果任務還沒完成，就返回 HTTP Status 102 Processing；如果已完成，則返回 HTTP Status 200 Ok。

   

2. Service A 在請求 Service B 接口時帶上 callback uri，比如 http://service_b/api/v1/domain?callbackuri=http://service_a/api/v1/domain，Service B 收到請求后立即返回 HTTP Status 200 Ok，等任務完成后再調用 Service A callback uri 進行通知。

   

方案 1 須要輪詢接口，輪詢太頻繁會導致資源浪費，間隔太長又會導致任務完成后 Service A 無法及時感知。顯然，方案 2 更加高效，因此也被廣泛應用。

方案 2 用到的思想就是本文要介紹的觀察者模式（Observer Pattern），GoF 對它的定義如下：

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

我們將觀察者稱為Observer，被觀察者（或主體）稱為Subject，那么Subject 和 Observer 是一對多的關系，當 Subject 狀態變更時，所有的 Observer 都會被通知到。

UML 結構

場景上下文

在簡單的分布式應用系統（示例代碼工程）中，應用之間通過 network 模塊來通信，其中通信模型采用觀察者模式：

從上圖可知，App 直接依賴 http 模塊，而 http 模塊底層則依賴 socket 模塊：

1. 在App2初始化時，先向 http 模塊注冊一個request handler，處理App1發送的 http 請求。
2. http 模塊會將request handler轉換為packet handler注冊到 socket 模塊上。
3. App 1發送 http 請求，http 模塊將請求轉換為socket packet發往App 2的 socket 模塊。
4. App 2的 socket 模塊收到 packet 后，調用packet handler處理該報文；packet handler又會調用App 2注冊的request handler處理該請求。

在上述socket - http - app 三層模型中，對 socket 和 http，socket 是 Subject，http 是 Observer；對 http 和 app，http 是 Subject，app 是 Observer。

代碼實現

因為在觀察者模式的實現上，socket 模塊和 http 模塊類似，所以，下面只給出 socket 模塊的實現：

//demo/network/socket.go
packagenetwork

//關鍵點1:定義Observer接口
//SocketListenerSocket報文監聽者
typeSocketListenerinterface{
//關鍵2:為Observer定義更新處理方法，入參為相關的上下文對象
Handle(packet*Packet)error
}

//Subject接口
//Socket網絡通信Socket接口
typeSocketinterface{
//Listen在endpoint指向地址上起監聽
Listen(endpointEndpoint)error
//Close關閉監聽
Close(endpointEndpoint)
//Send發送網絡報文
Send(packet*Packet)error
//Receive接收網絡報文
Receive(packet*Packet)
//AddListener增加網絡報文監聽者
AddListener(listenerSocketListener)
}

//關鍵點3:定義Subject對象
//socketImplSocket的默認實現
typesocketImplstruct{
//關鍵點4:在Subject中持有Observer的集合
listeners[]SocketListener
}

//關鍵點5:為Subject定義注冊Observer的方法
func(s*socketImpl)AddListener(listenerSocketListener){
s.listeners=append(s.listeners,listener)
}

//關鍵點6:當Subject狀態變更時，遍歷Observers集合，調用它們的更新處理方法
func(s*socketImpl)Receive(packet*Packet){
for_,listener:=ranges.listeners{
listener.Handle(packet)
}
}

...

總結實現觀察者模式的幾個關鍵點：

1. 定義 Observer 接口，上述例子中為SocketListener接口。
2. 為 Observer 接口定義狀態更新的處理方法，其中方法入參為相關的上下文對象。上述例子為Handle方法，上下文對象為Packet。
3. 定義 Subject 對象，上述例子為socketImpl對象。當然，也可以先將 Subject 抽象為接口，比如上述例子中的Socket接口，但大多數情況下都不是必須的。
4. 在 Subject 對象中，持有 Observer 接口的集合，上述例子為listeners屬性。讓 Subject 依賴 Observer 接口，能夠使 Subject 與具體的 Observer 實現解耦，提升代碼的可擴展性。
5. 為 Subject 對象定義注冊 Observer 的方法，上述例子為AddListener方法。
6. 當 Subject 狀態變更時，遍歷 Observer 集合，并調用它們的狀態更變處理方法，上述例子為Receive方法。

擴展

發布-訂閱模式

與觀察者模式相近的，是發布-訂閱模式（Pub-Sub Pattern），很多人會把兩者等同，但它們之間還是有些差異。

從前文的觀察者模式實現中，我們發現 Subject 持有 Observer 的引用，當狀態變更時，Subject 直接調用 Observer 的更新處理方法完成通知。也就是，Subject 知道有哪些 Observer，也知道 Observer 的數量：

在發布-訂閱模式中，我們將發布方稱為Publisher，訂閱方稱為Subscriber，不同于觀察者模式，Publisher 并不直接持有 Subscriber 引用，它們之間通常通過Broker來完成解耦。也即，Publisher 不知道有哪些 Subscriber，也不知道 Subscriber 的數量：

發布-訂閱模式被廣泛應用在消息中間件的實現上，比如 Apache Kafka 基于 Topic 實現了發布-訂閱模式，發布方稱為 Producer，訂閱方稱為 Consumer。

下面，我們通過簡單的分布式應用系統（示例代碼工程）中的 mq 模塊，展示一個簡單的發布-訂閱模式實現，在該實現中，我們將 Publisher 的 produce 方法和 Subscriber 的 consume 方法都合并到 Broker 中：

//demo/mq/memory_mq.go

//關鍵點1:定義通信雙方交互的消息，攜帶topic信息
//Message消息隊列中消息定義
typeMessagestruct{
topicTopic
payloadstring
}

//關鍵點2:定義Broker對象
//memoryMq內存消息隊列，通過channel實現
typememoryMqstruct{
//關鍵點3: Broker中維持一個隊列的map，其中key為topic，value為queue，go語言通常用chan實現。
queuessync.Map//key為Topic，value為chan*Message，每個topic單獨一個隊列
}

//關鍵點4:為Broker定義Produce方法，根據消息中的topic選擇對應的queue發布消息
func(m*memoryMq)Produce(message*Message)error{
record,ok:=m.queues.Load(message.Topic())
if!ok{
q:=make(chan*Message,10000)
m.queues.Store(message.Topic(),q)
record=q
}
queue,ok:=record.(chan*Message)
if!ok{
returnerrors.New("model'stypeisnotchan*Message")
}
queue<-?message
?returnnil
}

//關鍵點5:為Broker定義Consume方法，根據topic選擇對應的queue消費消息
func(m*memoryMq)Consume(topicTopic)(*Message,error){
record,ok:=m.queues.Load(topic)
if!ok{
q:=make(chan*Message,10000)
m.queues.Store(topic,q)
record=q
}
queue,ok:=record.(chan*Message)
if!ok{
returnnil,errors.New("model'stypeisnotchan*Message")
}
return<-queue,?nil
}

客戶端使用時，直接調用memoryMq的Produce方法和Consume方法完成消息的生產和消費：

//發布方
funcpublisher(){
msg:=NewMessage("test","helloworld")
err:=MemoryMqInstance().Produce(msg)
assert.Nil(t,err)
}

//訂閱方
funcsubscriber(){
result,err:=MemoryMqInstance().Consume("test")
assert.Nil(err)
assert.Equal(t,"helloworld",result.payload)
}

總結實現發布-訂閱模式的幾個關鍵點：

1. 定義通信雙方交互的消息，攜帶 topic 信息，上述例子為Message對象。
2. 定義 Broker 對象，Broker 是緩存消息的地方，上述例子為memoryMq對象。
3. 在 Broker 中維持一個隊列的 map，其中 key 為 topic，value 為 queue，go 語言通常用 chan 來實現 queue，上述例子為queues屬性。
4. 為 Broker 定義 produce 方法，根據消息中的 topic 選擇對應的 queue 發布消息，上述例子為Produce方法。
5. 為 Broker 定義 consume 方法，根據 topic 選擇對應的 queue 消費消息，上述例子為Consume方法。

Push 模式 VS Pull 模式

實現觀察者模式和發布-訂閱模式時，都會涉及到Push 模式或Pull 模式的選取。所謂 Push 模式，指的是 Subject/Publisher 直接將消息推送給 Observer/Subscriber；所謂 Pull 模式，指的是 Observer/Subscriber 主動向 Subject/Publisher 拉取消息：

Push 模式和 Pull 模式的選擇，取決于通信雙方處理消息的速率大小。

如果 Subject/Publisher 方生產消息的速率要比 Observer/Subscriber 方處理消息的速率小，可以選擇 Push 模式，以求得更高效、及時的消息傳遞；相反，如果 Subject/Publisher 方產生消息的速率要大，就要選擇 Pull 模式，由 Observer/Subscriber 方決定消息的消費速率，否則可能導致 Observer/Subscriber 崩潰。

Pull 模式有個缺點，如果當前無消息可處理，將導致 Observer/Subscriber 空輪詢，可以采用類似 Kafka 的解決方案：讓 Observer/Subscriber 阻塞一定時長，讓出 CPU，避免長期無效的 CPU 空轉。

典型應用場景

• 需要監聽某個狀態的變更，且在狀態變更時，通知到監聽者。
• web 框架。很多 web 框架都用了觀察者模式，用戶注冊請求 handler 到框架，框架收到相應請求后，調用 handler 完成處理邏輯。
• 消息中間件。如 Kafka、RocketMQ 等。

優缺點

優點

• 消息通信雙方解耦。觀察者模式通過依賴接口達到松耦合；發布-訂閱模式則通過 Broker 達到解耦目的。

• 支持廣播通信。

• 可基于 topic 來達到指定消費某一類型消息的目的。

缺點

• 通知 Observer/Subscriber 的順序是不確定的，應用程序不應該依賴通知順序來保證業務邏輯的正確性。
• 廣播通信場景，需要 Observer/Subscriber 自己去判斷是否需要處理該消息，否則容易導致unexpected update。

與其他模式的關聯

觀察者模式和發布-訂閱模式中的 Subject 和 Broker，通常都會使用單例模式來確保它們全局唯一。

文章配圖

可以在用Keynote畫出手繪風格的配圖中找到文章的繪圖方法。

審核編輯：湯梓紅