pinus通常简单实用，功能全面，具有高可扩展性、可扩展性等优点，这与其技术选择和方案规划密不可分。在分析许多游戏引擎设计理念的前提下，结合过去的游戏开发经验，确认了pinus架构设计方案。

node.js自身的优势与服务器的惊人一致。 在node.在js官方定义中， fast、scalable、realtime、network满足服务器的需求。服务器是网络密集型的应用，对即时性有很高的要求，而node.js在网络io上的优势也可以完全满足这一点。应用node.汇总js开发服务器的优点：

• IO和可伸缩性的优点。使用io密集型选择nodee.js是最佳选择， 能达到最佳的可伸缩性。
• 多进程单线程应用架构。node.js自然选择单线程， 在处理复杂逻辑时，不需要考虑线程同步、锁、死锁等一系列问题， 减少了许多逻辑错误。 多过程node.js构成服务器群是最理想的应用程序架构。
• 语言优势。如果客户端应用html，javascript开发可以实现快速迭代 五、更能实现编码同用。

一个真正高度可扩展的游戏运行架构必须是多进程的。googlegritsgame, mozila的browserquest 都使用了node.js作为服务器编程语言， 但它们都使用了单个过程的node.js服务器，缺乏扩展，这使得它们能够支持的在线用户数量非常有限(这两款游戏通常被用作HTML5游戏的demo)。多流程架构可以很好地完成服务器的扩展，从而支持更多的在线客户，降低服务器的压力。

表明： 上图中的格子表示过程， 定义相当于“服务器”

操作结构表示：

• 根据websocket，客户端连接到conector服务器群。
• conector承担承重连接，并将请求转发到后端服务器组。
• 后端服务器群主要包括场景服务器(area)、闲聊服务器(chat)和状态服务器等(status)， 该服务器承担各自的领域模型。在真实的情况下，还有许多其他类型的服务器。
• 处理逻辑后，后端服务器将结论返回到conector， 再由conector广播回到客户端。
• Master负责统一管理该服务器，包括运行、监控和关闭云服务器。

从表面上看，游戏的操作架构与web的操作架构非常相似。conector类似于web使用的apache/nginx等web服务器，后端服务器组类似于web应用中的网站服务器(如tomcat)。但实际上有很大的区别：

• 长连接与短连接。根据http的短连接，web应用程序可以实现最大的可扩展，游戏应用程序基于socketet(websocket)长连接，实现最大实时。根据http的短连接，web应用程序可以实现最大的可扩展，游戏应用程序基于socketet(websocket)长连接，实现最大实时。
• 不同的分区对策。根据负载均衡，可以随意确定web使用的分区， 游戏是基于场景的(area)分区方式， 这使得同一场景的玩家在一个过程中奔跑， 实现最小跨过程启用。
• 有状态和无状态。web应用是无状态的， 能够实现无限扩张。 而且游戏应用是有状态的， 因为根据场景的分区对策，需要路由到指定的服务器， 这也使得游戏无法实现web使用相同的可扩展性。
• 广播和request/response。web使用request/response的请求响应方法。而游戏应用则更频繁地使用广播， 因为玩家在游戏中的行为应该实时通知场景中的其他玩家， 一定要通过广播即时推送。这也使得网络通信对游戏的要求高于web应用。

游戏的运行结构非常复杂，要想支撑如此复杂的运行结构，就必须有一个结构来简化开发。

pinus就是这样一个架构，它让我们使用最少的编码， 为了实现复杂的运行架构，最清晰的结构。

pinus framework的构成结构如图所示：

• server management, pinus是一个真正的多进程、分布式服务器。因此，对各种游戏server(流程)的监督是pinus的重要组成部分，架构很容易根据抽象管理云服务器。
• network, 要求、响应、广播、RPC、session系统形成了所有游戏框架的主脉，所有游戏流程都建立在这个主脉上。
• application, 使用定义，component管理，前后文配备， 这使得pinus framework的对外界面非常简单， 并具有松耦合、可插拔架构。

• 抽象和扩展服务器(过程)

在web应用中， 每个服务器都是无状态、对等的， 开发人员不需要根据架构或器皿管理服务器。

但是游戏应用程序不同， 游戏可能需要包括多种不同类型的服务器，每种类型的服务器也可能有不同的数量需求。这就要求架构抽象解耦服务器，适用于服务器类型和数量的扩展。

• 客户端的要求、响应和广播

客户端的要求和响应与web应用相似， 但是架构是基于长连接的， 实现模式不同于http要求。

广播是服务器最频繁的操作， API必须方便， 而且能达到极致。

• 服务器之间的通信和启用

虽然架构尽量减少跨过程的启用，但过程之间的通信是不可避免的， 因此，需要方便实用的RPC架构来支撑。

＊ 应用架构松耦合，可插拔。

应用的扩展非常重要， pinus framework适用于component插入所有第三方组件， 还支持添加自定义路由规则， 自定义filter等。

以下是对这三个目标的详细分析：

抽象分类云服务器

该架构抽象了服务器， 抽象分为两类：前服务器和后服务器， 如图：

前面服务器(frontend)的职责：

• 承重客户端要求连接
• 维护session信息
• 将请求转发到后面
• 把后面必须广播的消息发到前面

后端服务器(backend)的职责：

• 解决领域模型， 包括RPC和前面要求的想法
• 提醒前面的消息

云服务器家鸭种类

动态语言的面向对象有一个叫做家鸭的基本要素。

云服务器抽象也可以比作家鸭， 云服务器对外界面只有两种， 一是接受客户端的要求， 叫handler， 一是接受RPC要求， 叫remote， handler和remote的行为决定了服务器的外观。

所以我们只需要定义handler和remote两种动作， 这个云服务器的类型可以确定。

所以我们只需要定义handler和remote两种动作， 这个云服务器的类型可以确定。

抽象完成服务器

使用与服务器对应的目录结构， 云服务器抽象可以快速实现。

以下是示例图：

图中的connector， area, chat三个目录代表三种服务器类型， 每个目录下的handler和remote都取决于这个云服务器行为(对外界面)。 开发者只需在handler和remote目录中填写编码， 某种服务器可以实现。这使得服务器实现起来非常方便。

移动服务器， 只需填写一份环境变量serversers.json可以让服务器快速移动。

具体环境变量内容如下：

所有web应用框架都实现了抽象的要求和响应。虽然游戏应用是基于长连接的， 但是抽象的要求和响应与web应用非常相似。

下图中的编码是request要求的例子：

根据Conventionnn的要求，请求的api与web使用的ajax非常相似 over configuration的原则， 不需要任何设备。 如图所示，请求route字符串：chat.chatHandler.send， 它可以将要求分发到chathandler文档在chat服务器上定义的send方式。

requestfilter系统、广播/组播系统也在Pinus框架中实现。详见pinus架构参考。

服务器之间的通信主要通过底层RPC架构实现，RPC架构主要解决了路由和RPC底层通信协议的选择两个问题。

RPC在服务器之间的启用也实现了零配备。如图所示：案例：

RPC插口定义在上图的remote目录中： chatRemote.js，其插口定义如下：

RPC启用只需通过以下插口即可实现其他服务器(RPC客户端):

该启用程序将根据特定的路由规则转发给特殊服务器。(比如场景服务请求会根据玩家在哪个场景立即转发到相应的server)。(比如场景服务请求会根据玩家在哪个场景立即转发到相应的server)。

目前，Socketet在底层选择RPC架构.作为一种通信协议，io对顶层是透明的，然后可以用任何协议代替。

component是pinus自定义部件，开发者可以自载入自定义component。

在pinus架构参考中，component将进行更深入的探讨。

以下是component的生命周期图：

使用者只需完成component相关界面： start, afterStart, stop, 可载入自定义部件：

上面的应用框架形成pinus framework的前提。在此基础上，开发服务器将非常方便，配合pinus提供的游戏开发库和相关工具集。在此基础上，开发服务器将非常方便，配合pinus提供的游戏开发库和相关工具集。 后面的tutorial将带我们进入开发游戏应用的实际案例。