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