RSF分布式服務框架設計：Hasor-RSF
是時候設計一個分布式服務框架了。我先將它定名為 Hasor-RSF，“RSF”為 Remote Service Framework 的縮寫。
RSF的目的是為了提供一種高效的遠程服務訪問方式，例如“A機器訪問在B機器上的一個服務”。當然首先它是運行在Java上的，但是我并不希望 Java 成為 RSF的唯一平臺。
它應該是分布式的，就是說服務 A 可能會分布在若干臺機器內。 當我的應用打算調用這個服務時我應該可以在這若干服務提供的機器上隨機調用。這樣做的好處是有助于高并發、高訪問、高可用。
RSF 的本質其實就是 RPC 那么我們可以先對比一下 RPC 里都有什么可以被我們拿來選用。下面列出來的只是其中一些我相信聰明的朋友們會列舉出更多的解決方案，我也敢保證你們知道的比我還多。
- Java原生的 RMI。
- Hessian
- WebServices
- Restful
- HTTP Request
- RTMP/AMF
- 淘寶的 HSF、Dubbo
RMI，這個 Java 原生的東東似乎從一開始就沒有被人們所看好，究其原因是速度太慢。但是它的好處是Java原生，使用 RMI 不需要引入其它任何第三方軟件包。不過挑剔的同學們似乎不太看好這個優點。
Hessian，原則上說Hessian我并不認為它是一個遠程服務框架范疇的東西。我更覺得 Hessian 是一種數據交互格式。就像是 JSON，XML-RPC，AMF，Kryo 一類的東西。Hessian 的優點是大量的兼容平臺例如：“IOS、Java、.net、C++、Python、Flash、Ruby、PHP”，其次它的第二個有點是二進制格式。在大對象序列化上會占有很大的優勢。
WebServices，一個老牌技術解決方案。在我印象中 WebServices 是跟隨著 SOA 這個東西一起出名的，他有一個***的好處是防火墻穿透。畢竟人家是靠 80 端口吃飯的，牛叉的很。不過話說回來WebServices的***要害就是，Xml傳輸格式。把一個對象序列化成為一個Xml數據是一件很容易的事，但是反序列化成本似乎是很高。再加上 SOAP 協議本身是建立在 XML 形式上，這就使得 Web Service 奇慢無比了。當然因素還有很多我就不多說了。
Restful，其實 restful 我更覺得它是一種 API 表述規范。但在社區論壇中討論看來，restful 的應用似乎也延伸到遠程服務的領域。所以有必要說明一下。restful 最初是出現在 web 上，究其本質是還是 HTTP。例如對于：“http://xxxxx/xxxx”這個資源的訪問可以利用 HTTP 的“GET、PUT、DELETE”等方法對資源操作加以描述說明。我個人覺得這東西用在 RPC 上并不合適。
HTTP，這是我用過最多的一種遠程交互方式。遠離很見dna，服務發布者將服務發布成為一個http資源。調用者請求這個http資源。數據傳輸格式完全程序雙方自行協商。這種方法簡單除暴行之有效。不過缺點是我們要自己補充通信協議，例如請求參數和響應數據格式。常規的交互格式有 JSON、XML。
RTMP/AMF，這個組合的確是一套很完善的遠程調用解決方案。RTMP協議中專門為 Invoke 開辟了一條通道，在配合 AMF 格式極大的方便了 Flash 下遠程服務訪問。不過這些都是 Flash下的東西，即使是擁有 Red5 這樣的神器讓我們在 java 下可以使用 rtmp 但是究其目的還是為了和 flash 通信。一般 flash 調用業務系統的方式還都停留在 http 請求或者通過 red5 服務器代為轉發。
HSF，這個東西是淘寶內部用的很廣泛的遠程服務框架。它是使用NIO、Mina 并且工作在長連接模式下。話說這個東西的確是個好東西，淘寶也將其開源了！只可惜，開源了 hsf 但是相關配套依賴沒有開源。在加上 hsf 依賴繁雜。這個東西也就只能讓局外人膜拜一下，在淘系之外的同學們是無福享受了。
Dubbo，也是淘系的另外一個服務框架，它比較 HSF 來說要輕巧很多。依賴會少一些，這個東東目前也是開源狀態。由于我對 dubbo 一點都不了解，在這里保持沉默不做評價。
***補充一下，真正原生就支持分布式服務調用的也就只有“HSF、Dubbo”至于京東內部是否有更好的解決方案我并不知道。哦還有一點，如果您想脫離 Spring 的話 HSF、Dubbo 會讓你失望的。這就是說您的技術構架如果是非 Spring 陣營的會比較悲催。
so，上面提到了很多可用的技術方案，想必***符合要求也就只有其中 HSF 和 Dubbo 了。為什么其它的方案都不入選呢？原因就是它們雖然可以完成 RPC 但是并不支持分布式。當然您可以通過架設集群來提高它們的可靠性，這些都是您需要額外付出的。
------------------------------
下面這個是 RSF 的架構圖，包括服務生產著和消費者在內 RSF 被分為 6 層（網絡層、協議層、請求響應層、調度層、接口層、消費者生產者）。
關鍵5層：
Netty，其中位于最下層的網通信部分 RSF 采用 Netty 實現。Netty 是一款非常優秀的網絡通信框架，使用 Netty 可以幫助 RSF 減少大量底層網絡上的代碼開發。這也就意味著 RSF 將采用 Selector 方式實現異步IO。
Protocol，協議層。該層主要的目的是負責解釋翻譯 RSF 數據包，并將 RSF 數據包轉意成為 Request 和 Response 對象。協議層可以是一個協議棧，這就意味您可以通過 RTMP 、或者其它自定義網絡協議傳輸 RSF 數據包。
Request/Response層，請求響應層。這個在這個層中，RSF 脫離了底層網絡方面的特性將每次調用請求對象化為一個 Request 對象，并且將調用結果封裝成為一個 Response 對象。這種編程模式和 Web 很像。
調度層，這一層最為復雜。它負責管理本地 RSF 服務的注冊，遠程傳輸對象序列化方式的管理，并且還要負責實現其它更加復雜的功能。
接口層，這一層是最終 RSF 暴露給業務系統的接口，將會由兩個類提供。一個代表服務生產著，另一個是服務消費者。
序列化格式：
RSF 規定在網絡中傳輸的數據格式可以是任意的。這就意味著您可以使用 AMF 作為 RSF 數據傳輸格式發布（同時如果協議層支持 RTMP 那您可以在 Flash 中無需通過 red5 這樣的中間代理直接訪問 RSF 服務）。同樣的，如果您使用 Hessian 作為數據傳輸格式，在其它平臺。例如 .net、php。也會很方便的調用 RSF 服務（需要解析 RSF 數據包）。如果協議采用 HTTP，RSF序列化格式采用 JSON ，那么運行在瀏覽器中的 javascript 也可以繞過 web 服務器，直接訪問 RSF 服務。
服務配置Config：
說是服務配置，其實就是路由的功能。先假設我們有4臺服務器，其中有兩臺是位于北京機房，另外兩臺分別位于青島和內蒙古。這四臺機器上都運行著 RSF，跑著相同的業務系統，這種架構通常前端會有一個 CDN 之類的東西負責讓用戶就近訪問網站。
如果沒有服務路由的情況下，用戶A在北京即使訪問了最近的北京服務器，但是由于調用的 RDS 服務是青島的，那么也會降低訪問速度。因此服務配置所負責的 路由特性可以很方便的高速服務調用程序，優先選用北京機房的 RSF 服務。只有當北京機房的服務撐不住的情況下才會動用其它地域的 RSF 服務。
流量管控：高級一點的特性是可以通過服務路由來控制服務流量。假如目前要做一個全國范圍的活動，我們充分的為每個地方準備了若干機器。但是在活動現場很可能某一個地區的服務使用量達到了臨界點，服務路由應該可以通過配置的方式讓附近地區的機器提供一定的流量來減緩這個地區的訪問壓力。
