pomelo学习笔记(一)术语

转自https://github.com/NetEase/pomelo/wiki/%E6%9C%AF%E8%AF%AD%E8%A7%A3%E9%87%8A

 

使用pomelo框架的话,有pomelo自己的术语,这里先对术语做一些简单的解释,给读者一个直观的概念,不至于看到相应术语时产生迷惑。

常见术语

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: SessionServiceBackendSessionService,也是最令人迷惑的地方,这里尝试给出一些说明,让你的理解更清晰一些: Session指的是一个客户端连接的抽象,它的大致字段如下:

{
    id :  // readonly
    frontendId :  // readonly
    uid :  // readonly
    settings :  // read and write  
    __socket__ : 
    __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 :  // readonly
    frontendId :  // readonly
    uid :  // readonly
    settings :  // 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中实现的是监控逻辑,比如收集进程状态等。用户在使用时,可以通过applicationregisterAdmin注册管理模块,实现用户自己定制的监控管理功能。每一个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中的一些术语,因为在下面的例子中,会涉及到这些术语,不至于当出现这些术语时一头雾水。下面我们就正式进入我们的例子,获取源码并安装我们的例子应用。

Test hi

中文首页

你可能感兴趣的:(pomelo,nodejs,pomelo,nodejs)