這是一篇關於純C++RPC框架的文章。所以，我們先看看，我們有什麼？ 1、一個什麼都能幹的C++。（前提是，你什麼都幹了） 2、原始的Socket介面，還是C API。還得自己去二次封裝... 3、C++11，這是最令人興奮的。有了它，才能夠有這篇文章；否則，CORBA之類的才是唯一的選擇。（因為需 ...
這是一篇關於純C++RPC框架的文章。所以，我們先看看，我們有什麼？
1、一個什麼都能幹的C++。（前提是，你什麼都幹了）
2、原始的Socket介面，還是C API。還得自己去二次封裝...
3、C++11，這是最令人興奮的。有了它，才能夠有這篇文章；否則，CORBA之類的才是唯一的選擇。（因為需要代碼生成）
那麼，我們沒有什麼，或者需要什麼？
1、一套完善的序列化框架；在不同的進程間傳輸數據，序列化是第一步，如何可靠且方便地將對象轉化為二進位（或者其他格式），在對端則是如何正確且安全地將其從二進位恢復為對象。
2、完善的底層通信協議；其需要提供合適的語義抽象：服務端支持怎樣的併發，是單客戶單訪問，還是多訪問；而客戶端的併發模型由服務端決定。當然，還需要健壯且足夠的介面抽象，畢竟分散式環境，“一切皆有可能”，需要應對各種問題。
3、一個可用的反射系統。是的，需要在C++環境下建立一個反射系統。這一步是最為關鍵的，其由C++11支持。因為，我們需要註冊一個類的各種信息，以供RPC調用。
當然，本文是提綱式的；也就是，在這裡暫時只會講【目標】——一個可用的C++RPC所需要的全部組件。而更詳細的內容，即如何構建這些組件，將由後續篇章回答。
一、序列化
在分散式環境下，序列化是永遠繞不過的一個坎；而作為一個支撐性組件，其所需要提供不只是“可用”，而是易用且安全！安全！重要的事說兩遍。我們不能夠約定從網路傳來的內容，代表了什麼；而是其本身必須帶有信息，告訴我們它是什麼。
在純C++環境下，要從零開始構建一個序列化框架，是困難的。畢竟語言本身並沒有提供什麼保證。所幸的是，C++並非完全沒有提供，只是需要我們去發掘。template，模板可以給我們所需要的一切；C++中最令人興奮的部分，其提供了另一個簡單且可靠的擴展模型：通過特化模板，能夠提供類似面向對象的“介面”。當然，需要的還不止這些，我們需要更強大的工具：模板元編程，由其來提供所需要的類型信息（在我的系統中有兩種擴展方式：特化模板和成員函數，後者需要類型信息）。
下麵將是我們需要完成的目標：
Buffer buffer; Object obj1; //序列化 Serialize(&buffer, obj1); Object obj2; //反序列化 Deserialize(&buffer, obj2);
其中的buffer，便是我們的成果；其以二進位保存了對象。當然，還有許多的細節需要補充。
二、通信
UDP還是TCP，這是一個需要糾結的問題。但我們的關註點並不在這，我們需要一個完善的、健壯的通信組件。為了完成這個目標，需要付出一些努力：併發模型、中斷與超時通知。前者是整個RPC框架的語義保證，我們需要保證調用語義的完整性：客戶端的併發訪問請求，到了服務端不能變成串列請求；而普通的通信協議，並不能夠直接提供這點，我選擇了從零開始構建。中斷與超時，是整個調用語義，所面臨的最大挑戰；所以，我們需要合適的通知，以決定如何進行下一步操作。
當然，UDP與TCP，依舊是一個重要的話題；我的實現，提供了二者的完整實現，所需的只是，選擇。
三、反射
在C++的世界里，講這個話題是不合時宜的。畢竟，無論怎樣的努力，在一個沒有完整運行時環境的語言里，“反射”這樣奢侈的東西，只是一個夢想。但，我們並不是想要重新打造一門語言，而僅僅是給我們的RPC提供一些服務而已。
在RPC的世界里講“反射”並不是一件突兀的事。看一看，各種沒有IDL的RPC在Java里的實現，無一不是使用了反射這一技術。是的，我的RPC里並沒有IDL，我並不打算再創建一門語言（我有一個腳本語言），哪怕只是一個DSL（領域特定語言）。為了“封裝”類型的各種信息：構造函數、析構函數以及一些我們需要的方法。反射，提供了最合適的語義。
我的RPC是非侵入式的，在不改變任何原有的代碼的前提下，提供相應的RPC調用。而這一“調用”通過反射來實現。
四、RPC
前面三大組件，和我的RPC並沒有什麼必然的聯繫。但沒有這三個組件，我的RPC框架，將不復存在。所以，最後再來講講我們的主角：RPC。
其實，RMI（遠程方法調用）更合適一點。我的RPC提供了3中“對象”：
1、由單一客戶端獨占的，非共用對象；只有該客戶端能夠訪問該對象，其創建和析構，都由一個客戶端發起和執行。
2、服務對象，這在服務端本身是一個“服務”；也就是其本身是一個單例，因此，所有客戶都是直接在一個對象上，執行各種請求；該對象的構造和析構，可由服務端的本地服務管理框架（我的另一個東西）管理。這個方式，提供了“服務化”的最佳語義；當然，也就需要面對併發。
3、註冊對象，其也是全局可訪問的，所有客戶端都可以發送請求；不同的是，其是由服務端的某段代碼顯示註冊的，該對象的所有權也由其持有；客戶端只能訪問其介面。一旦服務端取消了註冊，便也消失在所有的客戶端眼前，並且是可能在任何時刻取消註冊，即使有請求還在路上（當然，有請求正在執行，需要等待其執行完成）。
還有一個重要的事情，我只提供了，同步訪問；因為，我有一個分散式消息系統，可提供非同步服務（這隻是托詞，懶，而已）。
其實，在擁有了前面的三個組件後，RPC本身便只剩下，需不需要構建，而不是如何。這樣，我們也就可以將重心轉向RPC的語義保證上了。一般有三種語義可以提供：至少一次、至多一次，可能一次。分別代表如下3中結果：
1、該請求被執行，因為我們將重覆地發送請求，直到答覆。也就意味著，該請求可能被重覆執行多次。
2、該請求被執行，我們會一直發送重覆的請求，直到答覆。但服務端，將識別這些重覆的請求，並只會執行一次。
3、該請求被髮送，但我們並不保證被執行；因為，我們沒有等待答覆。
對於通用的RPC，除了“至多一次”，並沒有其他的選擇。當然，為了完成這點，需要一些努力，所幸並不困難。我的RPC正是提供這樣的調用語義。
我們將要構建的RPC並沒有使用IDL。所以，客戶端的訪問，將會是顯示的RPC調用；而非是其他框架所宣傳的，能夠完全屏蔽本地和分佈，但我們是在C++的環境下，要完全屏蔽，是不可能的；所以，我所提供的調用方式，並沒有排除原始的方案。其與本地調用的不同是：需要統一從一個RPC客戶端對象中傳入所需要的對象名字，以及在方法調用時，需要一個額外的方法名字。
比如：
RPCClient client("Something");
int val = client.Invoke("GetValue", 12, "I Want ...").To<int>();
當然，如果你不習慣這樣的方式（你會習慣的）；我還提供了類似IDL的功能：代碼生成。其能夠將上面的顯示訪問，封裝起來，提供和本地調用完全一樣的方式：
#include "Generated\\Something.h"//這個頭文件是生成的 Something obj; int val = obj.GetValue(12, "I Want ...");
而在服務端則，使用如下方式提供遠程對象：
Class<Somthing>* type = GetServiceAs<ReflectionService>()->Register<Something>();//也可以重新命名：Register<Something>("OtherName");
type->AddMethod("GetValue", &Somthing::GetValue);//也可註冊重載函數（方式後面再講）
總之，本篇，完。
PS：如需，請期待下一篇——序列化。
PS：以及，下下篇——通信。
PS：還有，下下下篇——反射。
