gate服务器
一个应用的gate服务器,一般不参与rpc调用,也就是说其配置项里可以没有port字段,仅仅有clientPort字段,它的作用是做前端的负载均衡。客户端往往首先向gate服务器发出请求,gate会给客户端分配具体的connector服务器。具体的分配策略一般是根据客户端的某一个key做hash得到connector的id,这样就可以实现各个connector服务器的负载均衡。
connector服务器
connector服务器接收客户端的连接请求,创建与客户端的连接,维护客户端的session信息。同时,接收客户端对后端服务器的请求,按照用户配置的路由策略,将请求路由给具体的后端服务器。当后端服务器处理完请求或者需要给客户端推送消息的时候,connector服务器同样会扮演一个中间角色,完成对客户端的消息发送。connector服务器会同时拥有clientPort和port,其中clientPort用来监听客户端的连接,port端口用来给后端提供服务。
应用逻辑服务器
gate服务器和connector服务器又都被称作前端服务器,应用逻辑服务器是后端服务器,它完成实际的应用逻辑,提供服务给客户端,当然客户端的请求是通过前端服务器路由过来的。后端服务器之间也会通过rpc调用而有相互之间的交互。由于后端服务器不会跟客户端直接有连接,因此后端服务器只需监听它提供服务的端口即可。
master服务器
master服务器加载配置文件,通过读取配置文件,启动所配置的服务器集群,并对所有服务器进行管理。
rpc调用
pomelo中使用rpc调用进行进程间通信,在pomelo中rpc调用分为两大类,使用namespace进行区分,namespace为sys的为系统rpc调用,它对用户来说是透明的,目前pomelo中系统rpc调用有:
- 后端服务器向前端服务器请求session信息
- 后端服务器通过channel推送消息时对前端服务器发起的rpc调用
- 前端服务器将用户请求路由给后端服务器时也是sys rpc调用
除了系统rpc调用外,其余的由用户自定义的rpc调用属于user namespace的rpc调用,需要用户自己完成rpc服务端remote的handle代码,并由rpc客户端显式地发起调用
route,router
route用来标识一个具体服务或者客户端接受服务端推送消息的位置,对服务端来说,其形式一般是..,例如"chat.chatHandler.send", chat就是服务器类型,chatHandler是chat服务器中定义的一个Handler,send则为这个Handler中的一个handle方法。对客户端来说,其路由一般形式为onXXX,当服务端推送消息时,客户端会有相应的回调。 一般来说具体的同类型应用服务器都会有多个,当客户端请求到达后,前端服务器会将用户客户端请求派发到后端服务器,这种派发需要一个路由函数router,可以粗略地认为router就是根据用户的session以及其请求内容,做一些运算后,将其映射到一个具体的应用服务器id。可以通过application的route调用给某一类型的服务器配置其router。如果不配置的话,pomelo框架会使用一个默认的router。pomelo默认的路由函数是使用session里面的uid字段,计算uid字段的crc32校验码,然后用这个校验码作为key,跟同类应用服务器数目取余,得到要路由到的服务器编号。注意这里有一个陷阱,就是如果session没有绑定uid的话,此时uid字段为undefined,可能会造成所有的请求都路由到同一台服务器。所以在实际开发中还是需要自己来配置router。
Session, FrontendSession, BackendSession, SessionService, BackendSessionService
在pomelo框架中,有这三个session的概念,同时又有两个service:SessionService
和BackendSessionService
,也是最令人迷惑的地方,这里尝试给出一些说明,让你的理解更清晰一些: Session的是一个客户端连接的抽象,它的大致字段如下:
{
id : <session id> // readonly
frontendId : <frontend server id> // readonly
uid : <bound uid> // readonly
settings : <key-value map> // read and write
__socket__ : <raw_socket>
__state__ : <session state>
// ...
}
- id是这个session的id,是全局唯一的,一般使用自增的方式来生成;
- frontendId是维护这个session的前端服务器的id;
- uid是这个session所绑定的用户id;
- __socket__是底层原生socket的引用;
- __state__用来指明当前session的生命周期状态。
- settings维护一个key-value map,用来描述session的一些自定义属性,比如聊天应用中的房间号就可以看作是session的一个自定义属性。
从上面的分析看,一个session一旦建立,那么id, frontendId,__socket__, __state__, uid都是确定的,都应该是只可读不可写的。而settings也不应该被随意的修改。 因此,在前端服务器中,引入了FrontendSession, 可以把它看作是一个内部session在前端服务器中的傀儡,FrontendSession的字段大致如下:
{
id : <session id> // readonly
frontendId : <frontend server id> // readonly
uid : <bound uid> // readonly
settings : <key-value map> // read and write
}
其作用:
- 通过FrontendSession可以对settings字段进行设置值,然后通过调用FrontendSession的push方法,将设置的settings的值同步到原始session中;
- 通过FrontendSession的bind调用,还可以给session绑定uid;
- 当然也可以通过FrontendSession访问session的只读字段,不过对FrontendSession中与session中相同的只读字段的修改并不会反映到原始的session中。
SessionService维护所有的原始的session信息,包括不可访问的字段,绑定的uid以及用户自定义的字段。
下面再说BackendSession,与FrontendSession类似,BackendSession是用于后端服务器的,可以看作是原始session的代理,其数据字段跟FrontendSession基本一致。
BackendSession是由BackendSessionService创建并维护的,在后端服务器接收到请求后,由BackendSessionService根据前端服务器rpc的参数,进行创建。对BackendSessionService的每一次方法调用实际上都会生成一个远程调用,比如通过一个sid获取其BackendSession。同样,对于BackendSession中字段的修改也不会反映到原始的session中,不过与FrontendSession一样,BackendSession也有push,bind,unbind调用,它们的作用与FrontendSession的一样,都是用来修改原始session中的settings字段或者绑定/解绑uid的,不同的是BackendSession的这些调用实际上都是名字空间为sys的远程调用。
Channel
channel可以看作是一个玩家id的容器,主要用于需要广播推送消息的场景。可以把某个玩家加入到一个Channel中,当对这个Channel推送消息的时候,所有加入到这个Channel的玩家都会收到推送过来的消息。一个玩家的id可能会被加入到多个Channel中,这样玩家就会收到其加入的Channel推送过来的消息。需要注意的是Channel都是服务器本地的,应用服务器A和B并不会共享Channel,也就是说在服务器A上创建的Channel,只能由服务器A才能给它推送消息。
request, response, notify, push
pomelo中有四种消息类型的消息,分别是request,response,notify和push,客户端发起request到服务器端,服务器端处理后会给其返回响应response;notify是客户端发给服务端的通知,也就是不需要服务端给予回复的请求;push是服务端主动给客户端推送消息的类型。在后面的叙述中,将会使用这些术语而不再作解释。
filter
filter分为before和after两类,每类filter都可以注册多个,形成一个filter链,所有的客户端请求都会经过filter链进行一些处理。before filter会对请求做一些前置处理,如:检查当前玩家是否已登录,打印统计日志等。after filter是进行请求后置处理的地方,如:释放请求上下文的资源,记录请求总耗时等。after filter中不应该再出现修改响应内容的代码,因为在进入after filter前响应就已经被发送给客户端。
handler
handler是实现具体业务逻辑的地方,在请求处理流程中,它位于before filter和after filter之间,handler的接口声明如下:
handler.methodName = function(msg, session, next) {
// ...
}
参数含义与before filter类似。handler处理完毕后,如有需要返回给客户端的响应,可以将返回结果封装成js对象,通过next传递给后面流程。
error handler
error handler是一个处理全局异常的地方,可以在error handler中对处理流程中发生的异常进行集中处理,如:统计错误信息,组织异常响应结果等。error handler函数是可选的,如果需要可以通过
app.set('errorHandler', handleFunc);
来向pomelo框架进行注册,函数声明如下:
errorHandler = function(err, msg, resp, session, next) {
// ...
}
其中,err是前面流程中发生的异常;resp是前面流程传递过来,需要返回给客户端的响应信息。其他参数与前面的handler一样。
component
pomelo 框架是由一些松散耦合的component组成的,每个component完成一些功能。整个pomelo框架可以看作是一个component容器,完成component的加载以及生命周期管理。pomelo的核心功能都是由component完成的,每个component往往有start,afterStart,stop等调用,用来完成生命周期管理。
admin client, monitor, master
在对pomelo服务器进行管理的时候,有三个概念admin client, monitor, master。
-
monitor运行在各个应用服务器中,它会向master注册自己,向master上报其服务器的信息,当服务器群有变化时,接收master推送来的变化消息,更新其服务器上下文。
-
master运行在应用服务器中,它会收集整个服务器群的信息,有变化时会将变化推送到各个monitor;同时,master还接受admin client的请求,按照client发出的命令,执行对应的操作,如查询整个服务器群的状态,增加一个服务器等。
-
client独立运行自己的进程,它会发起到master的连接,然后通过对master发出请求或者命令,来管理整个服务器群。目前工具pomleo-cli就是这样的一个客户端。
admin module
在pomelo中,module特指服务器监控管理模块,与component类似,不过在module中实现的是监控逻辑,比如收集进程状态等。用户在使用时,可以通过application
的registerAdmin
注册管理模块,实现用户自己定制的监控管理功能。每一个module中都会定义下面四种回调函数,不过都是可选的:
- masterHandler(agent, msg, cb) 当有应用服务器给master发监控数据时,这个回调函数会由master进程进行回调,完成应用服务器的消息处理;
- monitorHandler(agent, msg, cb) 当有master请求应用服务器的一些监控信息时,由应用服务器进行回调,完成对master请求的处理;
- clientHandler(agent, msg, cb)当由管理客户端向master请求服务器群信息时,由master进程进行回调处理客户端的请求。
- start(cb) 当admin module,注册加载完成后,这个回调会被执行,在这里可以做一些初始化工作。
plugin
plugin是pomelo 0.6加入的全新的扩展机制,一个plugin由多个component以及一些事件响应处理器组成。它提供了一种很灵活的机制来扩展pomelo。不仅可以提供component的功能,还可以对整个框架的全局事件作出响应处理。
小结
上面简要地介绍了pomelo中的一些术语,因为在下面的例子中,会涉及到这些术语,不至于当出现这些术语时一头雾水。下面我们就正式进入我们的例子