（本文部分内容只适合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 可复用的通信框架（序）
