實踐GoF的23種設計模式：觀察者模式

摘要：當你需要監聽某個狀态的變更，且在狀态變更時通知到監聽者，用觀察者模式吧。

本文分享自華為雲社群《【Go實作】實踐GoF的23種設計模式：觀察者模式》，作者： 元閏子 。

簡介

現在有 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
package network
// 關鍵點1: 定義Observer接口
// SocketListener Socket封包監聽者
type SocketListener interface {
 // 關鍵2: 為Observer定義更新處理方法，入參為相關的上下文對象
Handle(packet *Packet) error
}
// Subject接口
// Socket 網絡通信Socket接口
type Socket interface {
// Listen 在endpoint指向位址上起監聽
Listen(endpoint Endpoint) error
// Close 關閉監聽
Close(endpoint Endpoint)
// Send 發送網絡封包
Send(packet *Packet) error
// Receive 接收網絡封包
Receive(packet *Packet)
// AddListener 增加網絡封包監聽者
AddListener(listener SocketListener)
}
// 關鍵點3: 定義Subject對象
// socketImpl Socket的預設實作
type socketImpl struct {
 // 關鍵點4: 在Subject中持有Observer的集合
listeners []SocketListener
}
// 關鍵點5: 為Subject定義注冊Observer的方法
func (s *socketImpl) AddListener(listener SocketListener) {
s.listeners = append(s.listeners, listener)
}
// 關鍵點6: 當Subject狀态變更時，周遊Observers集合，調用它們的更新處理方法
func (s *socketImpl) Receive(packet *Packet) {
for _, listener := range s.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 消息隊列中消息定義
type Message struct {
topic   Topic
payload string
}
// 關鍵點2: 定義Broker對象
// memoryMq 記憶體消息隊列，通過channel實作
type memoryMq struct {
 // 關鍵點3: Broker中維持一個隊列的map，其中key為topic，value為queue，go語言通常用chan實作。
queues sync.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 {
return errors.New("model's type is not chan *Message")
}
queue <- message
return nil
}
// 關鍵點5: 為Broker定義Consume方法，根據topic選擇對應的queue消費消息
func (m *memoryMq) Consume(topic Topic) (*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 {
return nil, errors.New("model's type is not chan *Message")
}
return <-queue, nil
}      

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

// 釋出方
func publisher() {
msg := NewMessage("test", "hello world")
err := MemoryMqInstance().Produce(msg)
assert.Nil(t, err)
}
// 訂閱方
func subscriber() {
result, err := MemoryMqInstance().Consume("test")
assert.Nil(err)
assert.Equal(t, "hello world", 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畫出手繪風格的配圖 中找到文章的繪圖方法。

參考

[1] 【Go實作】實踐GoF的23種設計模式：SOLID原則, 元閏子

[2] 【Go實作】實踐GoF的23種設計模式：單例模式, 元閏子

[3] Design Patterns, Chapter 5. Behavioral Patterns, GoF

[4] 觀察者模式, refactoringguru.cn

[5] 觀察者模式 vs 釋出訂閱模式, 柳樹

點選關注，第一時間了解華為雲新鮮技術~