陳碩 (giantchen_AT_gmail)

這篇文章要解決的問題是：在接收到 protobuf 資料之後，如何自動建立具體的 Protobuf Message 物件，再做的反序列化。“自動”的意思是：當程式中新增一個 protobuf Message 型別時，這部分程式碼不需要修改，不需要自己去註冊訊息型別。其實，Google Protobuf 本身具有很強的反射(reflection)功能，可以根據 type name 建立具體型別的 Message 物件，我們直接利用即可。

本文假定讀者瞭解 Google Protocol Buffers 是什麼，這不是一篇 protobuf 入門教程。

本文以 C++ 語言舉例，其他語言估計有類似的解法，歡迎補充。

網路程式設計中使用 protobuf 的兩個問題

Google Protocol Buffers (Protobuf) 是一款非常優秀的庫，它定義了一種緊湊的可擴充套件二進位制訊息格式，特別適合網路資料傳輸。它為多種語言提供 binding，大大方便了分散式程式的開發，讓系統不再侷限於用某一種語言來編寫。

在網路程式設計中使用 protobuf 需要解決兩個問題：

• 長度，protobuf 打包的資料沒有自帶長度資訊或終結符，需要由應用程式自己在發生和接收的時候做正確的切分；
• 型別，protobuf 打包的資料沒有自帶型別資訊，需要由傳送方把型別資訊傳給給接收方，接收方建立具體的 Protobuf Message 物件，再做的反序列化。

第二個問題其實也很好解決，Protobuf 對此有內建的支援。但是奇怪的是，從網上簡單搜尋的情況看，我發現了很多山寨的做法。

山寨做法

以下均為在 protobuf data 之前加上 header，header 中包含 int length 和型別資訊。型別資訊的山寨做法主要有兩種：

• 在 header 中放 int typeId，接收方用 switch-case 來選擇對應的訊息型別和處理函式；
• 在 header 中放 string typeName，接收方用 look-up table 來選擇對應的訊息型別和處理函式。

這兩種做法都有問題。

第一種做法要求保持 typeId 的唯一性，它和 protobuf message type 一一對應。如果 protobuf message 的使用範圍不廣，比如接收方和傳送方都是自己維護的程式，那麼 typeId 的唯一性不難保證，用版本管理工具即可。如果 protobuf message 的使用範圍很大，比如全公司都在用，而且不同部門開發的分散式程式可能相互通訊，那麼就需要一個公司內部的全域性機構來分配 typeId，每次增加新 message type 都要去註冊一下，比較麻煩。

第二種做法稍好一點。typeName 的唯一性比較好辦，因為可以加上 package name（也就是用 message 的 fully qualified type name），各個部門事先分好 namespace，不會衝突與重複。但是每次新增訊息型別的時候都要去手工修改 look-up table 的初始化程式碼，比較麻煩。

其實，不需要自己重新發明輪子，protobuf 本身已經自帶了解決方案。

根據 type name 反射自動建立 Message 物件

Google Protobuf 本身具有很強的反射(reflection)功能，可以根據 type name 建立具體型別的 Message 物件。但是奇怪的是，其官方教程裡沒有明確提及這個用法，我估計還有很多人不知道這個用法，所以覺得值得寫這篇 blog 談一談。

以下是陳碩繪製的 Protobuf  class diagram，點選檢視原圖。

我估計大家通常關心和使用的是圖的左半部分：MessageLite、Message、Generated Message Types (Person, AddressBook) 等，而較少注意到圖的右半部分：Descriptor, DescriptorPool, MessageFactory。

上圖中，其關鍵作用的是 Descriptor class，每個具體 Message Type 對應一個 Descriptor 物件。儘管我們沒有直接呼叫它的函式，但是Descriptor在“根據 type name 建立具體型別的 Message 物件”中扮演了重要的角色，起了橋樑作用。上圖的紅色箭頭描述了根據 type name 建立具體 Message 物件的過程，後文會詳細介紹。

原理簡述

Protobuf Message class 採用了 prototype pattern，Message class 定義了 New() 虛擬函式，用以返回本物件的一份新例項，型別與本物件的真實型別相同。也就是說，拿到 Message* 指標，不用知道它的具體型別，就能建立和它型別一樣的具體 Message Type 的物件。

每個具體 Message Type 都有一個 default instance，可以通過 ConcreteMessage::default_instance() 獲得，也可以通過 MessageFactory::GetPrototype(const Descriptor*) 來獲得。所以，現在問題轉變為 1. 如何拿到 MessageFactory；2. 如何拿到 Descriptor*。

當然，ConcreteMessage::descriptor() 返回了我們想要的 Descriptor*，但是，在不知道 ConcreteMessage 的時候，如何呼叫它的靜態成員函式呢？這似乎是個雞與蛋的問題。

我們的英雄是 DescriptorPool，它可以根據 type name 查到 Descriptor*，只要找到合適的 DescriptorPool，再呼叫 DescriptorPool::FindMessageTypeByName(const string& type_name) 即可。眼前一亮？

在最終解決問題之前，先簡單測試一下，看看我上面說的對不對。

簡單測試

package muduo;

message Query {
  required int64 id = 1;
  required string questioner = 2;

  repeated string question = 3;
}

message Answer {
  required int64 id = 1;
  required string questioner = 2;
  required string answerer = 3;

  repeated string solution = 4;
}

message Empty {
  optional int32 id = 1;
}

其中的 Query.questioner 和 Answer.answerer 是我在前一篇文章這提到的《分散式系統中的程序標識》。

以下程式碼驗證 ConcreteMessage::default_instance()、ConcreteMessage::descriptor()、 MessageFactory::GetPrototype()、DescriptorPool::FindMessageTypeByName() 之間的不變式 (invariant)：

  typedef muduo::Query T;

  std::string type_name = T::descriptor()->full_name();
  cout << type_name << endl;

  const Descriptor* descriptor = DescriptorPool::generated_pool()->FindMessageTypeByName(type_name);
  assert(descriptor == T::descriptor());
  cout << "FindMessageTypeByName() = " << descriptor << endl;
  cout << "T::descriptor()         = " << T::descriptor() << endl;
  cout << endl;

  const Message* prototype = MessageFactory::generated_factory()->GetPrototype(descriptor);
  assert(prototype == &T::default_instance());
  cout << "GetPrototype()        = " << prototype << endl;
  cout << "T::default_instance() = " << &T::default_instance() << endl;
  cout << endl;

  T* new_obj = dynamic_cast(prototype->New());
  assert(new_obj != NULL);
  assert(new_obj != prototype);
  assert(typeid(*new_obj) == typeid(T::default_instance()));
  cout << "prototype->New() = " << new_obj << endl;
  cout << endl;
  delete new_obj;

根據 type name 自動建立 Message 的關鍵程式碼

好了，萬事具備，開始行動：

1. 用 DescriptorPool::generated_pool() 找到一個 DescriptorPool 物件，它包含了程式編譯的時候所連結的全部 protobuf Message types。
2. 用 DescriptorPool::FindMessageTypeByName() 根據 type name 查詢 Descriptor。
3. 再用 MessageFactory::generated_factory() 找到 MessageFactory 物件，它能建立程式編譯的時候所連結的全部 protobuf Message types。
4. 然後，用 MessageFactory::GetPrototype() 找到具體 Message Type 的 default instance。
5. 最後，用 prototype->New() 建立物件。

Message* createMessage(const std::string& typeName)
{
  Message* message = NULL;
  const Descriptor* descriptor = DescriptorPool::generated_pool()->FindMessageTypeByName(typeName);
  if (descriptor)
  {
    const Message* prototype = MessageFactory::generated_factory()->GetPrototype(descriptor);
    if (prototype)
    {
      message = prototype->New();
    }
  }
  return message;
}

  Message* newQuery = createMessage("muduo.Query");
  assert(newQuery != NULL);
  assert(typeid(*newQuery) == typeid(muduo::Query::default_instance()));
  cout << "createMessage(/"muduo.Query/") = " << newQuery << endl;

古之人不餘欺也 :-)

注意，createMessage() 返回的是動態建立的物件的指標，呼叫方有責任釋放它，不然就會記憶體洩露。在 muduo 裡，我用 shared_ptr 來自動管理 Message 物件的生命期。

執行緒安全性

Google 的文件說，我們用到的那幾個 MessageFactory 和 DescriptorPool 都是執行緒安全的，Message::New() 也是執行緒安全的。並且它們都是 const member function。

關鍵問題解決了，那麼剩下工作就是設計一種包含長度和訊息型別的 protobuf 傳輸格式。

Protobuf 傳輸格式

陳碩設計了一個簡單的格式，包含 protobuf data 和它對應的長度與型別資訊，訊息的末尾還有一個 check sum。格式如下圖，圖中方塊的寬度是 32-bit。

用 C struct 虛擬碼描述：

 struct ProtobufTransportFormat __attribute__ ((__packed__))
 {
   int32_t  len;
   int32_t  nameLen;
   char     typeName[nameLen];
   char     protobufData[len-nameLen-8];
   int32_t  checkSum; // adler32 of nameLen, typeName and protobufData
 };

注意，這個格式不要求 32-bit 對齊，我們的 decoder 會自動處理非對齊的訊息。

例子

用這個格式打包一個 muduo.Query 物件的結果是：

設計決策

以下是我在設計這個傳輸格式時的考慮：

• signed int。訊息中的長度欄位只使用了 signed 32-bit int，而沒有使用 unsigned int，這是為了移植性，因為 Java 語言沒有 unsigned 型別。另外 Protobuf 一般用於打包小於 1M 的資料，unsigned int 也沒用。
• check sum。雖然 TCP 是可靠傳輸協議，雖然 Ethernet 有 CRC-32 校驗，但是網路傳輸必須要考慮資料損壞的情況，對於關鍵的網路應用，check sum 是必不可少的。對於 protobuf 這種緊湊的二進位制格式而言，肉眼看不出資料有沒有問題，需要用 check sum。
• adler32 演算法。我沒有選用常見的 CRC-32，而是選用 adler32，因為它計算量小、速度比較快，強度和 CRC-32差不多。另外，zlib 和 java.unit.zip 都直接支援這個演算法，不用我們自己實現。
• type name 以 '/0' 結束。這是為了方便 troubleshooting，比如通過 tcpdump 抓下來的包可以用肉眼很容易看出 type name，而不用根據 nameLen 去一個個數字節。同時，為了方便接收方處理，加入了 nameLen，節省 strlen()，空間換時間。
• 沒有版本號。Protobuf Message 的一個突出優點是用 optional fields 來避免協議的版本號（凡是在 protobuf Message 裡放版本號的人都沒有理解 protobuf 的設計），讓通訊雙方的程式能各自升級，便於系統演化。如果我設計的這個傳輸格式又把版本號加進去，那就畫蛇添足了。具體請見本人《分散式系統的工程化開發方法》第 57 頁：訊息格式的選擇。

示例程式碼

為了簡單起見，採用 std::string 來作為打包的產物，僅為示例。

如果以上程式碼編譯通過，但是在執行時出現“cannot open shared object file”錯誤，一般可以用 sudo ldconfig 解決，前提是 libprotobuf.so 位於 /usr/local/lib，且 /etc/ld.so.conf 列出了這個目錄。

$ make all # 如果你安裝了 boost，可以 make whole

$ ./codec_test 
./codec_test: error while loading shared libraries: libprotobuf.so.6: cannot open shared object file: No such file or directory

$ sudo ldconfig

與 muduo 整合

muduo 網路庫將會整合對本文所述傳輸格式的支援（預計 0.1.9 版本），我會另外寫一篇短文介紹 Protobuf Message <=> muduo::net::Buffer 的相互轉化，使用 muduo::net::Buffer 來打包比上面 std::string 的程式碼還簡單，它是專門為 non-blocking 網路庫設計的 buffer class。

此外，我們可以寫一個 codec 來自動完成轉換，就行 asio/char/codec.h 那樣。這樣客戶程式碼直接收到的就是 Message 物件，傳送的時候也直接傳送 Message 物件，而不需要和 Buffer 物件打交道。

訊息的分發 (dispatching)

目前我們已經解決了訊息的自動建立，在網路程式設計中，還有一個常見任務是把不同型別的 Message 分發給不同的處理函式，這同樣可以藉助 Descriptor 來完成。我在 muduo 裡實現了 ProtobufDispatcherLite 和 ProtobufDispatcher 兩個分發器，使用者可以自己註冊針對不同訊息型別的處理函式。預計將會在 0.1.9 版本釋出，您可以先睹為快：

基於 muduo 的 Protobuf RPC?

Google Protobuf 還支援 RPC，可惜它只提供了一個框架，沒有開源網路相關的程式碼，muduo 正好可以填補這一空白。我目前還沒有決定是不是讓 muduo 也支援以 protobuf message 為訊息格式的 RPC，muduo 還有很多事情要做，我也有很多部落格文章打算寫，RPC 這件事情以後再說吧。

注：Remote Procedure Call (RPC) 有廣義和狹義兩種意思。狹義的講，一般特指 ONC RPC，就是用來實現 NFS 的那個東西；廣義的講，“以函式呼叫之名，行網路通訊之實”都可以叫 RPC，比如 Java RMI，.Net Remoting，Apache Thrift，libevent RPC，XML-RPC 等等。