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