随着Node.js的不断发展与壮大，应用范围也越来越广泛，从传统的企业应用，到互联网使用，再到云计算的发展，它的身影也是随处可见。当然，它的受欢迎程度能在短时间内得到这么快的发展，除却与其本身的事件模型及V8的性能优化等一系列特性有关之外，还和国内外很多互联网公司的攻城师的大量应用和参与到开源项目中有密切关系，如网易的游戏开发，淘宝的数据之美等等。随着HTML5应用和移动互联网平台的指数增长，越来越多的用户使用了移动平台的休闲服务，采用Node.js实现高性能和可扩展性的游戏服务将是一件有意义的工作。
 
　　在互联网上，目前有一些采用Node.js实现的开源游戏服务框架，如 Mozilla的 Browser Quest，Google的 Grits，Chilly等。但是无一例外，这些框架不但与游戏逻辑联系紧密，而且几乎没有可扩展性和性能数据，同时也不提供任何游戏开发的管理工具，除了采用JavaScript编写外，很难体现出采用Node.js实现游戏开发的优越性。

　　概念

　　通常游戏分为角色扮演类和策略类及混合类等几种游戏类型。那么在网页游戏类型中，根据游戏的类型，开发者可能采用不同的架构实现方式，如策略类游戏可能更偏重于游戏的策略性和逻辑性，也就是考验游戏玩家的各种组合或搭配之类的游戏，对实时性的要求不会很高，在用户的可接受范围之内即可，因此也可以采用常用的Web应用开发模式来实现，而客户端采用轮询或长连接等方式来实现，这些应用模式也有很多的相关经验可以参考，因此能做到具有较好的可扩展性及伸缩性；此外，应用服务器和服务框架等也可以采用现存的技术实现，但是这只能满足对游戏实时性要求不高的场景服务，由于此类的应用方案非常成熟，在下文的讨论中，将不再详述。

　　角色扮演类游戏根据策划的要求可以实现各种各样的功能，如聊天，打斗，自动刷怪等各种复杂的功能，但是开发者基本可以把这些功能抽象地划分为二大类，即服务端的网络传输与逻辑运算能力，这样游戏服务的开发和实现会稍微简单些。现在，网络的实时传输基本上是采用Socket服务器来实现的，逻辑运算这个就不需要再述了，因此，游戏服务器就可以粗略的归纳为Socket的服务器综合游戏业务逻辑的实现。

　　与Web应用区别

　　从上面游戏服务的概念简单介绍中可以得知，实时游戏服务器的开发与传统的Web开发还是具有一些不同点，这些不同点着重体现在以下几个方面：

　　大部分的Web应用还是短连接的方式去实现，而游戏的实时性需要采用长连接的方式进行。

　　Web应用的场景一般是读多写少的应用，热点数据基本可以缓存；游戏服务的数据经常发生变动，如移动中的路径，打怪掉血等，缓存基本很快就失效，属于写多读少的应用场景。

　　广播特性，即Web应用行为上基本只需要用户与服务器交互，其他用户要实现共享他人信息的时候，会采用类似拉的方式如长轮询来实现数据交互，即使在没有数据更新的状态时也需要消耗一定的服务端资源，造成一定的浪费；游戏里面的交互方式需要实时进行，对影响三方的数据，必须采用广播的方法进行消息推送，即推的模式。

　　目前的Web应用开发一般采用无状态性的方式来实现，因此可以实现较好的可扩展性，很多Web服务会采用绑定会话或集中会话等方式工作，当后面的某台服务器出现宕机时，服务也可以很快的切换；但是游戏服务器和用户之间的连接是有状态的，在断开时需要进行相关的通知和数据持久化，在重连时需要进行状态恢复等手段来维护游戏世界的运行。

　　除以上几点不同之外，还有负载均衡的策略，服务驱动方式，系统判定，系统安全如外挂作弊等相关问题，文章中不再对他们进行对比说明。一般来讲，根据游戏的规模与需求，通常游戏服务器的实现的模式会使用如下的三种架构方式来实现。

　　单进程服务架构

图1 单进程服务架构

　　图1是目前互联网上的很多游戏服务器使用的架构，比如商用的SmartFoxServer游戏服务器,开源的有Google的 Grits, Mozilla的 Browser Quest等框架。所有的程序在同一个进程里面运行，架构简单，开发人员上手快，开发和调试非常方便又快速，成本较低，后期的维护成本可能随着游戏项目的大小而不同，但是整体应该不会太高。很明显，游戏的世界是在同一个进程里运行，在单个场景都有不少在线用户的时候，如果采用单进程的 Node.js 实现的话，每个用户的操作可能会有一定的延迟，特别是在大量用户同时做大量操作与AI运算时，如服务端寻路和自动杀怪，延迟会更加严重；同时单进程对计算机资源使用有限。因此只适合游戏的原型制作或小型的游戏开发。另外，由于游戏的状态与复杂性，也无法较好的实现游戏的可扩展性，基本只能通过添加游戏服务器的方式来实现，即所谓的开新服，而这些用户之间是无法在同一个世界里通信会话和交互的。尽管Node.js支持原生的TCP服务，使用简单；但是目前大部分网络应用中，尤其是支持HTML5的应用，socket.io由于性能较好并且使用简单，成为大部分应用采用的网络库来实现高性能websocket服务。在移动互联网应用中，由于协议较复杂与通信数据等问题，需要一定的裁减。下面示例中，就是最简单的单进程服务的原型：

var socketio = require(‘socket.io’); var io = socketio.listen(8080); io.sockets.on(‘connection’,function(socket){      socket.on(‘disconnect’,function(){      //user leave      });  socket.on(‘message’,function(msg){      if (getLoginStatus(socket)) {      game[data.action].apply(null,[socket,msg]);       } else {      game[‘login’].apply(null,[socket,msg]);       }  }); });

　　多进程服务架构

图2 多进程服务架构

　　在上图2中，我们可以看出，每个进程负责采用单一职责，各进程间通过一定的规则（如RPC远程过程调用）来进行通信，游戏中的各场景服务使用一个进程来服务，实现各场景游戏运行的分离。但是在开发过程中，不需要考虑每个场景具体的信息，全部采用统一的代码来实现，开发方便，通过添加适当的参数来实现较易的调试，每个进程分别运行在服务器的多核上，即可以充分使用计算机的资源，也由于职责单一，由于每个进程都专职做自己的事，因此，在压力大的时候，可以很明显的查出问题所在，并可以较好的实现对相应的服务进行调优，可以达到较好的性能和一定的可伸缩性。但是，在各游戏的世界里，无法准确的知道游戏的状态如在线人数之类的，会存在热点数据和服务过载等一些问题，造成部分服务堵死等现象，也无法达到在不停服务的情况下进行服务器扩容与自动切换等问题，同时会给游戏运营带来一定的问题，不能充分的对玩家数据进行分析与挖掘，因此，这种实现方式可以满足中小型的游戏开发。这种架构目前很多的游戏服务器中还在使用，技术发展也较成熟，如传奇服务端架构等。

　　分布式服务架构

图3 分布式的服务架构

　　同样，分布式的服务架构与多进程的架构具有很多相同点，如进程服务单一职责，较好的性能调优，同时采用集中式的方式对游戏服务器进行管理，各游戏服务器可以通过自定义的方式即DSL进行游戏业务的路由与分发，通过主备服务器的状态可以很清楚的知道每个服务的状态及运行情况，这样可通过动态添加服务来到达负载均衡，具备较好的性能和可扩展性，能满足大型游戏的开发。当然，采用这样方式，会具有一定的复杂性，同时各服务之间可能是不在同一台服务器上的，因此会带来一定的网络开销，在大量广播的场景中，网络IO压力大，需要通过定时批量或AOI服务等方式来进行广播通信，同时，游戏的通信协议需要经过特别的设计，尽量避免数据序列化上的CPU重复开销，采用胖客户端的方式去分担游戏服务器的序列化与反序列化；另外还有可能引入分布式事务等相关问题，需要在一个集中点进行处理。当然，在游戏设计中，策划开发人员需要尽量避免这种跨场景跨进程的游戏逻辑需求。

　　在分布式架构实现中，目前商业上较成功的案例是BigWorld游戏服务框架，国内外很多大型的游戏开发商都在使用。而在开源部分，目前还没有较稳定成熟的方案，我们团队采用Node.js正在开发的Pomelo游戏服务框架正在努力实现这一目标，现已进入最后的文档整理阶段，预计将在十月份进行开源与线上示例演示。

　　总结

　　采用 Node.js 来实现网络游戏服务器的开发，除了能利用JavaScript的动态语言的优势特性、强大的开源社区和V8引擎的优越性能外，在网络数据传输的异步化方面具有快速、实时等事件编程模型；特别在HTML5的应用开发中，还具有前后端代码共享、DSL灵活定义等特点。但是也由于JavaScript的动态脚本语言的性质，同时V8在内存使用上的限制等问题。尽管V8引擎对脚本语言通过动态编译进行了静态化，但如果开发工程师在大规模开发时，没有注意到一些代码的细节，比如代码的额外异常检查和类属性的动态变化等方面，导致未经过调优的代码整体上还是无法和C、Java等静态语言相比的，然而在经过调优过后的代码是可以达到静态语言的性能的。在云计算应用中，也得到很多公司的推广与使用，如国外的SmartOS,Vmware以及国内的阿里云等，相信其性能与应用层面都会发展的越来越好；

　　此外，采用 Node.js 来实现游戏服务框架并开源也是一件非常有价值的事情，在追求高性能与低成本同时，希望能给开发者提供即简单又快速的开发方式，游戏开发者通过使用游戏框架，可以完全把精力放在业务代码的实现，不需要再把精力放在框架的实现。有机会我们将在后面的一系列讨论中介绍采用 Node.js 来开发游戏服务架构遇到的很多性能问题及优化过程。 最后，本文并不是建议大家一定要采用 Node.js 去开发游戏服务器，只是给新老游戏开发者提供一种解决方案，欢迎大家关注和探讨我们团队近期将开源的 Node.js 游戏服务解决框架。

 

基于SOA架构的业务安全性研究
2012-09-27 00:00比特网悠虎
关键字：
SOA 在提供价值链上企业之间信息共享和业务流程自动化的同时，也给业务信息安全带来了负面影响，且存在安全隐患，这些你知道吗？

SOA,SOA安全标准,安全套接字层,XML,

SOA在提供价值链上企业之间信息共享和业务流程自动化的同时，也给业务信息安全带来了负面影响，且存在安全隐患。为了确保SOA 能够切实给企业带来效益，企业一定要注意。

　　SOA(Service-Oriented Architecture，面向服务的体系结构)是一个组件模型，它将应用程序的不同功能单元通过这些单元之间定义良好的接口和契约联系起来。这些接口独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。和以往联网的分布式的系统不同，SOA 与平台相独立，其通信和特定的平台和技术没有必然的联系。

　　在企业中，将日常的各种业务应用划分为若干服务，然后通过SOA，用户可以构建、部署和整合这些服务，且无须依赖应用程序及其运行平台，从而提高业务流程的灵活性。例如，一个电子商务网站建立SOA架构后能够使自己与供应商、分销商、信用卡公司和消费者无缝地集成在一起。在一个客户下订单之后，系统将自动编排大量的信息，而不需要在每一次登录时都询问用户或者系统。对于企业来说，这种业务灵活性可以大大加快开发新业务的速度，并降低总体拥有成本，同时改善对及时、准确性业务信息的访问。

　　不过，SOA在带给企业灵活性，便捷性的同时，对于现实的要求也是很高的。因为整个SOA 应用架构相当于企业的信息平台，而企业本身对于平台本身的安全性、可靠性以及相关的服务质量都有相当高的要求。为了确保SOA 能够切实给企业带来效益，企业必须通盘考虑这种新架构的运行平台。因为，SOA 在提供价值链上企业之间信息共享和业务流程自动化的同时，也给业务信息安全带来了负面影响，且存在安全隐患。

　　一 SOA架构的负面影响

　　SOA架构是一种松耦合服务模式，通过标准化的接口来联系各种形式的服务，无论服务置于何地，均能通过一种便捷而统一的方式实现相关功能，这对信息资源的二次利用和服务模式的二次重整具有极大的作用。但是，如果没有适当的安全措施，它也会把这个服务平台的钥匙交给黑客。另外，SOA安全标准的不成熟加剧了互操作性方面的难题。如果想严加保护涉及多个企业的庞大Web服务网络，每个企业必须就采用的技术、甚至安全策略达成共识。

　　此外，企业中使用Web服务进行相互操作的系统对于内、外部攻击的防御能力越来越差。当这些系统使用的Web服务由供应商和业务伙伴等外部机构提供时，SOA和Web服务的部署工作将变得更加复杂，不得不谨慎部署最新的安全解决方案，如应用级防火墙、IDP、SSL VPN 和SSL卸载产品等，以便为企业中的SOA环境提供安全保护。

　　二 基于SOA架构的业务安全隐患

　　SOA虽然在某些方面使安全简化，但是在其他方面却使安全问题变得复杂。由于在基础设施中使用了XML一类的数据结构通用协议、IP 通信协议和通用操作系统，SOA 有助于简化某些安全决策；但在模块程序中，由于许多移动部件作为最终应用要集成在一起，使得安全决策变得复杂。

　　2.1 企业机构中缺乏对安全风险严重性的认识和知识

　　企业机构中的人员普遍认为被攻击的几率极低，不可能发生在他们身上，因此对安全风险缺乏认识。没有安全意识，则导致对保障系统信息安全的知识不重视。事实上，安全应该作为一套核心的服务实施，允许集中管理和维护安全。此外，管理层必须理解这个风险并且提供适当的支持和资金以便有效地保证企业的安全。

　　2.2 信息泄露的问题

　　以一个电子商务网站为例，一个订单能够引发一个包含提供给一个供应商、分销商和信用卡公司的XML数据，由于每一方都有不同的安全要求，比如只有信用卡公司有权访问信用卡信息(信用卡信息应该按照PCI的要求加密)，供应商需要知道什么产品及产品在目录的什么地方，分销商需要知道有关产品和发货地址的信息。如果不能保证XML传送的安全性，将泄漏交易过程中的敏感信息。

　　2.3 欺诈问题

　　欺诈主要是指未授权的用户访问授权用户被授权的资源，并以授权用户的名义进行交易，使得真正的授权用户的利益受到损失和破坏。在SOA系统中，强调设备与设备的交互，而大多数IT安全性都是基于人与设备的交互。传统的安全防御对象主要是针对人，而SOA更多地强调了设备与设备的交互，即所谓服务的互操作性，那么如何应对来自合作伙伴或第三方服务交互请求的欺诈威胁(因为大多数情况下，这些请求被人恶意利用和操纵)，将是SOA安全防御的一项重要课题。身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的。未授权用户可以非常轻松地访问Web服务，而Web服务往往不具备跟踪谁在使用它们或者谁被允许使用它们的固有毛病。

　　2.4 其它方面的安全问题

　　SOA整套架构在应用层与表示层的隔离上做得不完美，这会导致在未来阶段新的代理程序很容易寻找和利用SOA的安全漏洞，僵尸网络工具准确找到应用系统中安全漏洞的概率比较大，准确性也比较高。

　　总之，SOA的应用还处于起始阶段，还存在许多的安全隐患。

　　三 基于SOA架构的业务安全对策

　　SOA从本质上说是一种由元数据和XML一类的标准数据结构协议生成的应用程序，从而SOA所面临的安全问题与应用其他任何分布式系统时所遇到的安全问题是相同的，即如何确保机密性(Confidentiality)、完整性(Integrity)和可用性(Availability)。

　　3.1 提高认识和明确责任感

　　针对企业机构中缺乏对安全风险严重性的认识和知识的安全隐患，有两件事情能够缓解这种风险。第一是提高认识，通常采用培训安全知识的方式。不仅仅对开发人员进行培训，对于管理层、架构师、审计师、测试人员和其他人等都进行针对他们需求的培训。第二，安全是每一个人的责任，不仅仅是企业架构师和安全架构师的责任。机构要全力保证企业的安全。建议企业雇用有经验的SOA 安全人员或者雇用一个安全顾问把这个知识传授给机构内部的安全部门。

　　3.2 采用加密和认证等技术防止信息泄露

　　针对信息泄露的问题，需要进行多层次防范措施。采用加密和认证技术，在公共网络上建立安全专用隧道的网络，也就是常说的VPN;其次，网络服务的访问大多数通过HTTP协议，HTTP上实现的安全套接字层 (Security Socket Layer,SSL)也是成熟的安全通讯方式;但是，在上面的电子商务网站例子中，同样的信息要同时发给三个不同的公司，并且不需要任何一家公司登录，所以仅使用SSL是不够的。可以结合使用第三种即针对XML处理专门制定的消息级别的XML加密和处理标准，它把消息转换为一段经过加密的XML，消息仍然是XML格式的，但是使用加密算法将内容隐藏起来了。另外，保证XML传送安全在SOA安全中也非常重要。XML传送的安全包括两个部分：基础设施安全和加密。为了保证基础设施安全，硬件防火墙、安全设备都可以用来保护网络内部和外部的通信，通常这些设备都是SOA系统所必备的。但是，前提是需要对这些硬件防火墙和安全设备进行正确的配置以便保证XML信息在入口和网络界限之间能正常工作。这些XML信息包括数字签名的或者拥有其它安全标记的信息。而加密则是对SOA系统使用的XML文件进行加密。XML文件数字签名和加密有两个World Wide Web Consortium 规范：XML-加密和XML-签名。对于在HTTP连接之上发送的XML文件，则应使用SSL保护文件传送的安全。

　　3.3 采用身份认证和消息的数字签名应对欺诈问题

　　针对欺诈问题，可以使用身份认证和消息的数字签名来解决。身份认证保证授权的用户能够访问被授权的资源。由于在企业级SOA中身份认证不局限于单一安全控制域，而安全断言标记语言(Security Assertion Markup Language，SAML)标准提供了不同安全域之间认证的交互，以一种可为用户调用的Web 服务所接受的方式表达用户的真实性，并且，SAML基于XML的标准，为以标准方式描述安全性信息提供了一个框架。通过一个标准的认证过程，多方可以达成一致，使用一组给定的标准来对一组指定的用户进行身份验证，参加这个过程的安全域组成一个身份联邦(Identity Federation)。接下来，SOAP消息被传递给目的Web服务，并附加上一个SAML断言。但是需要注意SAML断言不依赖于联邦身份验证过程。

　　数字签名用于保证消息真正创建者身份的真实性以及消息在发送系统到接受系统之间传输时未被篡改。数字签名是对身份和消息内容进行惟一的处理得到的一个基于密钥的非常大的数，是一种消息级的安全措施，它结合了数字证书密钥和加密等安全方法。如果消息被改变了，那么惟一的数字签名将不再与密钥和用于创建密钥的原始消息相匹配。为此，数字签名提供了个不可否认性，例如，数字签名可以证明你的供应商收到的电子订单确实是由你发出而且在传输中没有被篡改过。针对企业级SOA，可以使用专门制定的处理XML消息级别的XML数字签名标准。

　　四 总结

　　虽然关于SOA技术的标准已经有很多了，专门针对安全问题而制定的标准却屈指可数。OASIS技术委员会制定了一系列技术标准，WS-Security是迄今为止得到认可的安全性标准集合的总称，包括WS-Security(描述如何将XML加密和XML签名应用于SOAP文档或信息)、WS-Trust(应用WS-Security标准传输密码、数字证书以及SAML断言等安全标识)、WS-SecurityPolicy(对哪些人被允许访问某个服务以及访问方式做出规定，并对认证方式的类型和/或所需要的加密等级做出限制)、WS-Federation(根据WS-SecurityPolicy 中描述的服务规则，应用WS-Trust 中提到的被传输的安全标识，通过Web服务的认证)、WS-SecureConversation( 按照WS-Security标准，实施WS-SecurityPolicy中所描述的策略的方法)等。现在，SOA领域的“物质基础”已尘埃落定，而“上层建筑”仍在建立之中。

　　需要注意的是，就像在IT的其他领域中一样，若想保障基于SOA架构业务的安全性，就需要有大量开销。因为在到达目的地之前，每条消息都必须经过好几个地方，另外证书文件可能会很大，从而给网络造成很大的负担，而且整个过程往往会降低性能。但遗憾的是，为了安全这些开销和负担是必不可少的。

　　此外，如果想保护牵涉多家企业的庞大Web服务网络，每家企业必须就采用的技术、甚至安全策略达成共识，因为如果合作伙伴的员工使用弱密码来访问系统，那么即使要求本企业的员工使用生物特征识别技术和物理令牌也是毫无用处的。