（本文部分內(nèi)容只適合ESFramework V0.3+）
在 ESFramework介紹之（14）－－ AS與FS通信方案 一文中，我們講到了AS與FS之間基本的通信方案，并且采取了一些策略來(lái)保證AS與FS之間的穩(wěn)定通信。本文我們將給出AS與FS通信的兩種實(shí)現(xiàn)，即基于Tcp連接池的通信實(shí)現(xiàn)和基于Remoting的通信實(shí)現(xiàn)。
我們已經(jīng)知道，AS與FS之間的通信分為兩類(lèi)，一類(lèi)是非功能通信，一類(lèi)是功能通信。非功能通信指的是FS向AS注冊(cè)、注銷(xiāo)等通信，這種通信僅僅是FS主動(dòng)聯(lián)系A(chǔ)S，以表明FS自己的狀態(tài)。功能通信是指AS將功能請(qǐng)求轉(zhuǎn)發(fā)給FS處理，這可以通過(guò)Tcp連接池或Remoting的方式進(jìn)行。在 ESFramework介紹之（14）－－ AS與FS通信方案 一文中，我們主要描述了非功能通信的策略，這里我們將描述功能通信的兩種實(shí)現(xiàn)。
要能比較全面的說(shuō)清楚AS與FS之間的功能通信，我不得不從一個(gè)更大的視野來(lái)討論問(wèn)題，其中會(huì)涉及到對(duì)眾多FS的管理、調(diào)度、狀態(tài)顯示等問(wèn)題。讓我們先從基于Tcp連接池的通信開(kāi)始。先給出個(gè)與該實(shí)現(xiàn)相關(guān)的組件關(guān)系圖先：
我來(lái)解釋一下各個(gè)組件的作用、職責(zé)，以及它們之間的關(guān)系。
（1）IAsRemotingService_4Fs，AS通過(guò)該接口發(fā)布遠(yuǎn)程服務(wù)給FS，F(xiàn)S可以通過(guò)該接口來(lái)向AS表明自己的狀態(tài)，如注冊(cè)、啟動(dòng)、停止、注銷(xiāo)、發(fā)布FS自己的性能數(shù)據(jù)等。
（2）IFsManager ，該組件實(shí)現(xiàn)了IAsRemotingService_4Fs接口，它對(duì)所有在線的FS進(jìn)行管理和狀態(tài)監(jiān)控。IFsManager 實(shí)現(xiàn)了IServerScheduler接口，它能夠在多個(gè)FS之間進(jìn)行調(diào)度，從而實(shí)現(xiàn)負(fù)載均衡。因?yàn)镮FsManager 知道每個(gè)FS的實(shí)時(shí)性能數(shù)據(jù)，所以它可以做到這一點(diǎn)。
（3）IFsDisplayer ，用于在UI上顯示每個(gè)FS的相關(guān)數(shù)據(jù)，比如FS的編號(hào)、FS的名稱(chēng)、FS的服務(wù)列表、性能數(shù)據(jù)（Cpu利用率、Memory的利用率）等。
（4）ITcpPoolsManager，這是基于Tcp連接池實(shí)現(xiàn)AS與FS之間通信的核心組件，它用于管理一個(gè)應(yīng)用服務(wù)器和多個(gè)功能服務(wù)器之間的所有TCP連接池。它借助IServerScheduler從眾多的FS中選取一個(gè)最適合并且負(fù)載最小的FS來(lái)處理功能請(qǐng)求。
（5）TPBasedDataDealer，基于Tcp連接池的處理器，它是一種偽處理器（FakeDataDealer），即它自己并不真正的處理消息，而是將消息轉(zhuǎn)交給ITcpPoolsManager處理。相關(guān)更多內(nèi)容可參考這里： ESFramework介紹之（12）―― 基于Tcp連接池的消息處理器
（6）ITcpPool接口，在 ESFramework介紹之（11）－－ Tcp連接池管理器 中我們已經(jīng)知道，ITcpPool接口可以使我們將一組Tcp連接池當(dāng)作一個(gè)連接池來(lái)看待。
（8）Bridge，這是FsManager_TcpPoolsManager_Bridge橋接組件，它用于連接IFsManager和ITcpPoolsManager，主要目的是將IFsManager的FsAdded事件和FsRemoved事件鏈接到ITcpPoolsManager對(duì)應(yīng)的方法上，這樣ITcpPoolsManager就可以動(dòng)態(tài)的添加/移除對(duì)應(yīng)的Tcp連接池了。
理解了上面的組件關(guān)系圖，然后來(lái)組裝ESFramework中對(duì)應(yīng)的組件以形成基于Tcp連接池的AS與FS通信就非常的簡(jiǎn)單了。下面我們來(lái)看看基于Remoting的AS與FS通信的實(shí)現(xiàn)，這個(gè)實(shí)現(xiàn)在ESFramework V0.3+中才會(huì)提供。
還是先給出組件關(guān)系圖：
可以看到，大部分組件和基于Tcp連接池的實(shí)現(xiàn)是一樣的，這樣可以最大化組件的復(fù)用（要達(dá)到這樣的效果，需要不斷地重構(gòu)組件），下面介紹一下不一樣的那些組件的作用。
（1）IRemoteHandleManager，用于管理所有的(FS)遠(yuǎn)程句柄，因?yàn)橐c多個(gè)FS進(jìn)行遠(yuǎn)程通信，所以需要將這些遠(yuǎn)程句柄管理起來(lái)，并且IRemoteHandleManager同樣借助了IServerScheduler從眾多的FS中選取一個(gè)最適合并且負(fù)載最小的FS來(lái)以Remoting的方式處理功能請(qǐng)求。
（2）Bridge，這個(gè)橋接組件是FsManager_RemoteHandleManager_Bridge，它的作用與FsManager_TcpPoolsManager_Bridge橋接組件相同。它將IFsManager的FsAdded事件和FsRemoved事件鏈接到IRemoteHandleManager對(duì)應(yīng)的方法上，這樣IRemoteHandleManager就可以動(dòng)態(tài)的添加/移除對(duì)應(yīng)的FS遠(yuǎn)程句柄了。
（3）RemotingBasedDataDealer ，基于Remoting的處理器，通過(guò)IRemoteHandleManager將所有的請(qǐng)求轉(zhuǎn)交給遠(yuǎn)程句柄處理。
（4）INakeDispatcher，這是ESFramework最內(nèi)部的消息分派器組件，當(dāng)消息到達(dá)INakeDispatcher內(nèi)部，就不再與Spy或Hook相關(guān)。
（5）IFsRemotingService_4As，這是FS發(fā)布的遠(yuǎn)程服務(wù)組件，該組件將所有來(lái)自AS的請(qǐng)求都交給INakeDispatcher分派處理。
我們看到，基于Tcp連接池的實(shí)現(xiàn)和基于Remoting的實(shí)現(xiàn)的原理基本是一致的，那么何時(shí)該使用Tcp連接池的實(shí)現(xiàn)，何時(shí)又使用基于Remoting的實(shí)現(xiàn)了？答案取決于多個(gè)方面，比如
（1）如果AS與FS都基于ESFramework創(chuàng)建，并且位于同一局域網(wǎng)內(nèi)，使用Tcp連接池效率可能更高。因?yàn)镽emoting底層會(huì)對(duì)NetMessage進(jìn)行列集/散集，這會(huì)折損效率（即使其底層仍然使用Tcp）。
（2）如果AS與FS分布于廣域網(wǎng)中，并且需要穿越多個(gè)防火墻，那么直接使用Tcp連接池可能不可行，因?yàn)橛械姆阑饓赡荜P(guān)閉了我們服務(wù)的Tcp端口。這時(shí)可以考慮使用Remoting的方式，因?yàn)镽emoting可以基于Http進(jìn)行。
（3）又如果我們的FS為了獲取更高的效率，全部采用C++構(gòu)建，那么無(wú)法提供Remoting，這時(shí)就只有采用Tcp連接池了。
也許，還有很多其它的情景和對(duì)應(yīng)的選擇，你可以自己去思考。
如果兩種方式都可行，那么我們可以隨意的選擇一種，在這兩種實(shí)現(xiàn)之間進(jìn)行切換僅僅是個(gè)配置的問(wèn)題（比如借助Spring.net）。
上篇文章： ESFramework介紹之（32）―― Tcp客戶(hù)端核心組件關(guān)系圖
轉(zhuǎn)到： ESFramework 可復(fù)用的通信框架（序）
在 ESFramework介紹之（14）－－ AS與FS通信方案 一文中，我們講到了AS與FS之間基本的通信方案，并且采取了一些策略來(lái)保證AS與FS之間的穩(wěn)定通信。本文我們將給出AS與FS通信的兩種實(shí)現(xiàn)，即基于Tcp連接池的通信實(shí)現(xiàn)和基于Remoting的通信實(shí)現(xiàn)。
我們已經(jīng)知道，AS與FS之間的通信分為兩類(lèi)，一類(lèi)是非功能通信，一類(lèi)是功能通信。非功能通信指的是FS向AS注冊(cè)、注銷(xiāo)等通信，這種通信僅僅是FS主動(dòng)聯(lián)系A(chǔ)S，以表明FS自己的狀態(tài)。功能通信是指AS將功能請(qǐng)求轉(zhuǎn)發(fā)給FS處理，這可以通過(guò)Tcp連接池或Remoting的方式進(jìn)行。在 ESFramework介紹之（14）－－ AS與FS通信方案 一文中，我們主要描述了非功能通信的策略，這里我們將描述功能通信的兩種實(shí)現(xiàn)。
要能比較全面的說(shuō)清楚AS與FS之間的功能通信，我不得不從一個(gè)更大的視野來(lái)討論問(wèn)題，其中會(huì)涉及到對(duì)眾多FS的管理、調(diào)度、狀態(tài)顯示等問(wèn)題。讓我們先從基于Tcp連接池的通信開(kāi)始。先給出個(gè)與該實(shí)現(xiàn)相關(guān)的組件關(guān)系圖先：
我來(lái)解釋一下各個(gè)組件的作用、職責(zé)，以及它們之間的關(guān)系。
（1）IAsRemotingService_4Fs，AS通過(guò)該接口發(fā)布遠(yuǎn)程服務(wù)給FS，F(xiàn)S可以通過(guò)該接口來(lái)向AS表明自己的狀態(tài)，如注冊(cè)、啟動(dòng)、停止、注銷(xiāo)、發(fā)布FS自己的性能數(shù)據(jù)等。
（2）IFsManager ，該組件實(shí)現(xiàn)了IAsRemotingService_4Fs接口，它對(duì)所有在線的FS進(jìn)行管理和狀態(tài)監(jiān)控。IFsManager 實(shí)現(xiàn)了IServerScheduler接口，它能夠在多個(gè)FS之間進(jìn)行調(diào)度，從而實(shí)現(xiàn)負(fù)載均衡。因?yàn)镮FsManager 知道每個(gè)FS的實(shí)時(shí)性能數(shù)據(jù)，所以它可以做到這一點(diǎn)。
（3）IFsDisplayer ，用于在UI上顯示每個(gè)FS的相關(guān)數(shù)據(jù)，比如FS的編號(hào)、FS的名稱(chēng)、FS的服務(wù)列表、性能數(shù)據(jù)（Cpu利用率、Memory的利用率）等。
（4）ITcpPoolsManager，這是基于Tcp連接池實(shí)現(xiàn)AS與FS之間通信的核心組件，它用于管理一個(gè)應(yīng)用服務(wù)器和多個(gè)功能服務(wù)器之間的所有TCP連接池。它借助IServerScheduler從眾多的FS中選取一個(gè)最適合并且負(fù)載最小的FS來(lái)處理功能請(qǐng)求。
（5）TPBasedDataDealer，基于Tcp連接池的處理器，它是一種偽處理器（FakeDataDealer），即它自己并不真正的處理消息，而是將消息轉(zhuǎn)交給ITcpPoolsManager處理。相關(guān)更多內(nèi)容可參考這里： ESFramework介紹之（12）―― 基于Tcp連接池的消息處理器
（6）ITcpPool接口，在 ESFramework介紹之（11）－－ Tcp連接池管理器 中我們已經(jīng)知道，ITcpPool接口可以使我們將一組Tcp連接池當(dāng)作一個(gè)連接池來(lái)看待。
（8）Bridge，這是FsManager_TcpPoolsManager_Bridge橋接組件，它用于連接IFsManager和ITcpPoolsManager，主要目的是將IFsManager的FsAdded事件和FsRemoved事件鏈接到ITcpPoolsManager對(duì)應(yīng)的方法上，這樣ITcpPoolsManager就可以動(dòng)態(tài)的添加/移除對(duì)應(yīng)的Tcp連接池了。
理解了上面的組件關(guān)系圖，然后來(lái)組裝ESFramework中對(duì)應(yīng)的組件以形成基于Tcp連接池的AS與FS通信就非常的簡(jiǎn)單了。下面我們來(lái)看看基于Remoting的AS與FS通信的實(shí)現(xiàn)，這個(gè)實(shí)現(xiàn)在ESFramework V0.3+中才會(huì)提供。
還是先給出組件關(guān)系圖：
可以看到，大部分組件和基于Tcp連接池的實(shí)現(xiàn)是一樣的，這樣可以最大化組件的復(fù)用（要達(dá)到這樣的效果，需要不斷地重構(gòu)組件），下面介紹一下不一樣的那些組件的作用。
（1）IRemoteHandleManager，用于管理所有的(FS)遠(yuǎn)程句柄，因?yàn)橐c多個(gè)FS進(jìn)行遠(yuǎn)程通信，所以需要將這些遠(yuǎn)程句柄管理起來(lái)，并且IRemoteHandleManager同樣借助了IServerScheduler從眾多的FS中選取一個(gè)最適合并且負(fù)載最小的FS來(lái)以Remoting的方式處理功能請(qǐng)求。
（2）Bridge，這個(gè)橋接組件是FsManager_RemoteHandleManager_Bridge，它的作用與FsManager_TcpPoolsManager_Bridge橋接組件相同。它將IFsManager的FsAdded事件和FsRemoved事件鏈接到IRemoteHandleManager對(duì)應(yīng)的方法上，這樣IRemoteHandleManager就可以動(dòng)態(tài)的添加/移除對(duì)應(yīng)的FS遠(yuǎn)程句柄了。
（3）RemotingBasedDataDealer ，基于Remoting的處理器，通過(guò)IRemoteHandleManager將所有的請(qǐng)求轉(zhuǎn)交給遠(yuǎn)程句柄處理。
（4）INakeDispatcher，這是ESFramework最內(nèi)部的消息分派器組件，當(dāng)消息到達(dá)INakeDispatcher內(nèi)部，就不再與Spy或Hook相關(guān)。
（5）IFsRemotingService_4As，這是FS發(fā)布的遠(yuǎn)程服務(wù)組件，該組件將所有來(lái)自AS的請(qǐng)求都交給INakeDispatcher分派處理。
我們看到，基于Tcp連接池的實(shí)現(xiàn)和基于Remoting的實(shí)現(xiàn)的原理基本是一致的，那么何時(shí)該使用Tcp連接池的實(shí)現(xiàn)，何時(shí)又使用基于Remoting的實(shí)現(xiàn)了？答案取決于多個(gè)方面，比如
（1）如果AS與FS都基于ESFramework創(chuàng)建，并且位于同一局域網(wǎng)內(nèi)，使用Tcp連接池效率可能更高。因?yàn)镽emoting底層會(huì)對(duì)NetMessage進(jìn)行列集/散集，這會(huì)折損效率（即使其底層仍然使用Tcp）。
（2）如果AS與FS分布于廣域網(wǎng)中，并且需要穿越多個(gè)防火墻，那么直接使用Tcp連接池可能不可行，因?yàn)橛械姆阑饓赡荜P(guān)閉了我們服務(wù)的Tcp端口。這時(shí)可以考慮使用Remoting的方式，因?yàn)镽emoting可以基于Http進(jìn)行。
（3）又如果我們的FS為了獲取更高的效率，全部采用C++構(gòu)建，那么無(wú)法提供Remoting，這時(shí)就只有采用Tcp連接池了。
也許，還有很多其它的情景和對(duì)應(yīng)的選擇，你可以自己去思考。
如果兩種方式都可行，那么我們可以隨意的選擇一種，在這兩種實(shí)現(xiàn)之間進(jìn)行切換僅僅是個(gè)配置的問(wèn)題（比如借助Spring.net）。
上篇文章： ESFramework介紹之（32）―― Tcp客戶(hù)端核心組件關(guān)系圖
轉(zhuǎn)到： ESFramework 可復(fù)用的通信框架（序）
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號(hào)聯(lián)系： 360901061
您的支持是博主寫(xiě)作最大的動(dòng)力，如果您喜歡我的文章，感覺(jué)我的文章對(duì)您有幫助，請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長(zhǎng)非常感激您！手機(jī)微信長(zhǎng)按不能支付解決辦法：請(qǐng)將微信支付二維碼保存到相冊(cè)，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
