组件概述
我们知道，pinus的应用程序执行的全部过程，就是对其相应组件的生命周期的管理，实际的所有逻辑功能均由pinus组件提供。pinus内建提供了十多个组件，这些组件适用于不同的服务器，提供不同的功能。有些组件提供的功能比较复杂，有些则比较简单。下面我们将以提供的功能为主线来阐述pinus提供的内建组件。
master组件仅仅由master服务器加载，它主要的功能包括启动所有的应用服务器、管理和监控所有的应用服务器和接受管理客户端的请求与响应。
在master组件的start方法里，会根据用户提供的服务器配置信息，启动用户配置的所有的具体应用服务器。
当master组件start结束后，他将开启一个socket监听端口，接受应用服务器和监控客户端的连接和注册，收集应用服务器上报的监控信息，给应用服务器推送一些消息，并对管理客户端发出的管理请求给予响应。管理客户端如pinus-cli可能发出的请求包括查看某个服务器进程状态，增加一个服务器，停掉一个服务器等。以增加一个服务器为例，当管理客户端发出增加服务器请求时，会提供相应的服务器参数，如服务器类型，主机ip，开启的端口等。此时，master组件接受后，会启动相应的服务器，并将新增加的服务器信息广播通知给其他已经启动的服务器。
master组件无配置项。
monitor组件由所有的包括master服务器在内的服务器都会加载，它的主要功能就是与master建立连接进行通信，从而对整个应用服务器群进行管理和监控。master服务器本身也会加载monitor服务器，因为master服务器也会收集其本身自己的监控信息。
可以认为monitor服务器与master服务器是对等组件，monitor会通过master接受一些命令，比如关闭整个服务器等。对于一些周期性监控的信息，pinus提供了两种收集方式，即pull方式和push方式。pull方式要求master周期地去与monitor通信，拉取相应的监控信息；push方式，则是由monitor周期地主动地向master报告其监控信息。
monitor组件无配置项。
connector组件是一个重量级的组件，它会依赖于session组件，server组件,pushScheduler组件和connection组件。connector组件仅仅被前端服务器加载，它主要用来管理客户端的连接。connector组件会加载底层的connector，创建端口监听，绑定事件响应。当有客户端连接请求时，connector组件会请求session组件，获得当前连接的session，如果session组件中没有相应的session的话，session组件会为这个新连接创建新的session，并维护相应的连接；然后connector组件还会向connection组件上报连接信息，供统计使用；最后，将拿到的session以及客户端的请求，一起抛给server组件，由server组件进行请求处理。当server组件处理完请求后，又会通过connector组件将响应返回给客户端。在返回响应给客户端的时候，connector组件做了一个缓存选择，这个缓存实现依赖于pushScheduler组件，也就是说connector组件并不是直接将响应发给客户端，而是将响应给pushScheduler组件。pushScheduler组件根据相应调度策略，可能不缓存直接通过session组件维护的连接，将响应发出去，也可能进行缓存，并按时flush。这是可以配置的。
connector组件支持如下配置项:
- connector: 底层使用的通信connector，不配置的话，会默认使用sioconnector;
- useProtobuf: 目前仅仅支持connector配置使用hybridconnector的情况，配置其为true，将开启消息的protobuf功能；
- useDict： 目前仅仅支持connector配置使用hybridconnector的情况，配置其为true时，将会开启基于字典的路由消息压缩；
- useCrypto： 目前仅仅支持connector配置为hybridconnector的情况，配置其为true时，将会启用通信时的数字签名；
- encode/decode： 消息的编码解码方式，如果不配置的话，将会默认使用connector配置中，底层connector提供的相应的编码解码函数。
- transports：这个配置选项是用于sioconnector的，因为socket.io的通信方式可能会有多种，如websocket，xhr-polling等等。通过这个配置选项可以选择需要的方式。
配置connector组件，通过调用如下方式进行:
app.set('connectorConfig', opts);
session组件跟connector相关，也是仅仅被前端服务器加载，为sessionService提供一个组件包装, 加载session组件后，会在app的上下文中增加sessionService，可以通过app.get('sessionService')获取。它主要用来维护客户端的连接信息，以及生成session并维护session。如果与经典TCP进行类比的话，那么session中维护的连接就可以粗略地认为就是TCP服务器端accept返回的socket句柄。一个连接与一个session对应，同时session组件还维护具体登录用户与session的绑定信息。一个用户可以有多个客户端登录，对应于多个session。当需要给客户端推送消息或者给客户端返回响应的话，必须通过session组件拿到具体的客户端连接来进行。
session组件支持如下配置项:
- singleSession： 如果这个配置项配置为true的话，那么将将不允许一个用户同时绑定到多个session，在绑定用户一次后，后面的绑定将会失败。
配置session组件，通过调用如下方式进行:
app.set('sessionConfig', opts);
connection组件是一个功能相对简单的组件，也是仅仅被前端服务器加载,为connectionService提供一个组件包装,他主要进行连接信息的统计,connector组件接收到客户端连接请求以及有客户端离线时，以及用户登录下线等等情况，都会向其汇报。
connection组件无配置项。
server组件也是一个功能比较复杂的组件，它被除master外的服务器加载。server组件会加载并维护自身的Filter信息和Handler信息。server组件会从connector组件的回调里获得到相应的客户端请求或者通知，然后会使用自己的before filters对其消息进行过滤，再次调用自己的相应Handler进行请求的逻辑处理，然后将响应通过回调的方式发给connector处理。最后调用after filters进行一些清理处理。
当然，如果客户请求的服务本来就是前端服务器提供的话，会是上面的那种处理流程。如果客户请求的服务是后端服务器提供的服务的话，则将不是上面的那种处理流程，此时会出现sys rpc调用。前面那种前端服务器自己处理的情况具体调用为doHandle，而发起rpc调用的情况则为doForward。这两种处理流程的不同点是，对于自身的请求，调用自己的filter-handler链进行处理，对于不是前端服务器自己提供的服务，则是发起一个sys rpc，然后将rpc调用的结果作为响应，发给connector进行处理。关于这个rpc调用则是pinus内建的msgRemote实现的。
对于后端服务器来说，其客户请求不是直接来源于真实的客户端，而是来源于前端服务器对其发起的sys rpc调用，这个rpc调用的实现就是pinus内建的msgRemote，在msgRemote的实现里，会将来自前端服务器的sys rpc调用请求派发给后端服务器的server组件，然后后端服务器会启用filter-handler链对其进行处理，最后通过rpc调用的返回将具体的响应返回给前端服务器。
在前端服务器将客户端请求向后端服务器分派时，由于同类型的后端服务器往往有很多，因此需要一个路由策略router，一般情况下用户通过Application.route调用为后端服务器配置router。
server组件无配置项。
pushScheduler组件也是一个功能较为简单的组件，它仅仅被前端服务器加载，与connector组件的关系密切。当connector组件收到server组件的对客户端请求的响应后，connector并不直接将此响应返回给客户端，而是将这个给客户端发送响应的操作调度给scheduler组件。pushScheduler组件完成最后通过session组件拿到具体的客户端连接并将请求的响应发送给客户端的任务。因此，通过pushScheduler组件可以对发给用户的响应进行缓冲，从而提高通信效率。pinus实现了两种调度策略，一种是不进行任何缓冲，直接将响应发送给客户端，一种是进行缓冲，并定时地将已缓冲的响应发送给对应的客户端。
pushScheduler配置项:
- scheduler： scheduler组件的具体调度策略配置，默认的是直接将响应发给客户端，同时pinus还提供了有缓冲并且定时刷新的调度策略。用户也可以自定义自己的调度策略。
配置pushScheduler组件，通过调用如下:
app.set('pushSchedulerConfig', opts);
如果要启用使用缓冲的scheduler的话，可以在app.js中增加:
app.set('pushSchedulerConfig', {scheduler: pinus.pushSchedulers.buffer, flushInterval: 20});
flushInterval是刷新周期，默认为20毫秒。
proxy组件是一个重量级的组件，它被除master外的所有服务器加载。proxy组件会扫描具体应用服务器的目录，抽取其中的remote部分，由于javascript语言的动态性，可以很轻易地获得到remote中的关于远程调用的元信息，生成stub，并将这些调用都挂到app.rpc下面，当用户发起rpc调用时，proxy组件会查看其扫描到的stub信息，以此决定此远程调用是否合法。同时，proxy又会创建一个RpcClient，当发起远程调用时，负责与远端的remote进行通信，并得到远程调用的结果供调用者使用。当进行远程调用时，由于同类型的远程服务器可能有多个，所以这里同样需要配置相应的router。
proxy的配置项：
- cacheMsg, 配置cacheMsg为true的话，将开启rpc调用时的对消息的缓冲，而不是直接一旦有rpc请求就发出。
- interval, 与配置参数cacheMsg配合使用，设置flush缓存的周期
- mailBoxFactory, rpc底层实现需要的，用户可以定义自己的mailBoxFactory,我们将在rpc原理里面详述。
另外，可以开启rpc的调用日志，通过如下的调用:
app.enable('rpcDebugLog');
配置proxy使用：
app.set('proxyConfig', opts);
remote组件是与proxy组件对等的组件，它用来提供rpc调用服务。rpc组件完成对当前服务器的remote的加载，并开启监听端口，等待rpc客户端的连接及相应的rpc调用。当接收到具体的调用请求时，会根据调用请求中描述的调用请求信息，调用相应的remote中的相应方法。然后再将具体的处理结果返回给rpc客户端。rpc服务端还支持对调用请求的filter，也就是说跟server组件处理客户端请求一样，rpc服务端处理具体请求时也会使用filter-remote链进行处理。
remote组件配置项:
- cacheMsg, 与proxy组件的含义相同
- interval， 与proxy组件的含义相同
- acceptorFactory, rpc底层实现需要的,可以认为跟proxy配置中的mailBoxFactory是对等的，我们将在rpc原理里面详述。
跟proxy组件一样，用户可以开启rpcDebugLog来得到所有的rpc调用过程的日志。 配置remote组件使用：
app.set('remoteConfig', opts);
dictionary组件是一个可选组件，不会被默认加载，只有当connector组件的配置中开启了useDict的时候，此组件才会被加载。此组件会遍历所有handler的route字符串，还会从config/dictionary.json中读取客户端的route字符串，然后对这些字符串进行编码，给予每一个路由赋予一个唯一的小整数，实现route信息压缩，当客户端与前端服务器通信时需要路由信息时，将不会再使用很长的那个字符串，而仅仅使用一个小整数。
dictionary的配置项:
-
dict, 客户端路由字符串文件的位置，默认使用的是config/dictionary.json 配置dictionary组件使用:
app.set('dictionaryConfig', opts);
protobuf组件也是一个可选组件，不会被默认加载，只有当connector组件的配置中开启了useProtobuf的时候，此组件才会被加载。此组件会加载对应的proto文件，并完成消息的基于protobuf的编解码。默认的proto文件的配置信息在config/serverProtos.json和config/clientProtos.json中。具体会在详细介绍pinus-protobuf中详细介绍。
protobuf组件无配置项。
channel组件维护channel信息，可以被除了master之外的服务器加载。channel组件可以看作是channelService的组件包装,加载该组件后，会在app上下文中加入channelService，可以通过app.get('channelService')获取。可以认为一个channel就是一个用户的集合，每一个用户大致对应于前端服务器中的一个session，用户可以通过channel组件向一个channel里面的所有用户推送消息。当然，由于后端服务器并不与客户端直接相连，故后端服务器会发起一个sys rpc来表示向客户端推送消息，接受这个远程调用的是pinus已经实现的ChannelRemote。
channel组件的配置项：
-
broadcastFilter， broadcast的过滤函数。会在执行channel的broadcast的时候，在前端服务器上，在消息发送给每个session之前，进行一个过滤。其函数签名为
broadcastFilter(session, msg, filterParam)
其中filterParam参数由在channelService的broadcast调用时传入，如下:
channelService.broadcast(type, route, {filterParam: param}, cb);
可以通过如下方式对Channel组件进行配置：
app.set('channelConfig', opts)
BackendSession组件可以看作是BackendSessionService的组件包装，加载该组件后，会在app的上下文中加入backendSessionService，可以通过app.get('backendSessionService')调用获取。可以被除了master之外的服务器加载。它主要为后端服务器提供BackendSession信息，并通过远程过程调用完成一些比如对原始session绑定uid等操作。
backendSession组件无配置项。