精华内容
参与话题
问答
  • 作为服务器,必须具有并发处理能力,同时还必须能减小资源消耗,及时回收资源,容错性好,运行稳定等等。因此,一个良好的架构是这些特性...通讯协议都是状态的。它们总体上都用了同一个架构,有一些小区别。 ...

    作为服务器,必须具有并发处理能力,同时还必须能减小资源消耗,及时回收资源,容错性好,运行稳定等等。因此,一个良好的架构是这些特性得以实现的基本保证。

    本人因公司业务需求,做了两个服务程序,一个是UDP协议,一个是TCP协议。通讯协议都是无状态的。它们总体上都用了同一个架构,有一些小区别。

     

                                                                     接收Socket 

                                                                            |
                                                                            | 

                                                                       数据缓存
                                                          (提高性能;暂存数据包碎片) 

                                                                            |
                                                                            |  

                                                                        控制器
                             (根据需要创建线程,线程与事务处理器对应,也就是说,线程方法就是事务处理器的唯一public方法。

                                 返回值是事务处理器的状态。当状态为“完成”时, 结束线程,销毁事务处理器,回收资源。)

                                                                            |
                                                                            | 
                                    -------------------------------------------------------------
                                    |                      |                |                    |                       |  

                              事务处理器1      事务处理器2     事务处理器3    事务处理器……     事务处理n  
                             (处理具体的事务。数据由控制器传入,每次处理结束返回状态给控制器,由控制器来决定下一步工作。) 

     

           其实,稍微分析一下就会发现,这个架构思想采用了IOCP思想的一部分,它没有像IOCP那样在线程池中一直运行着几个线程,仍然采取不断地创建、销毁线程的方式,因此性能不如IOCP高,但结构却简单明了,实现起来也容易。实践证明,对于并发量不是特别大(一万个以上)、数据量也不是特别大的情况,还是完全能够胜任的。 

    转载于:https://www.cnblogs.com/niumodawang/archive/2012/02/24/2367018.html

    展开全文
  • 游戏服务端架构发展史(中)

    千次阅读 2017-02-23 12:01:47
    《游戏服务端发展史》转载请著名出处:http://www.skywind.me/blog/archives/1301 类型4:第三代游戏服务器 2007 从魔兽世界开始无缝世界地图已经深入人心,比较以往游戏玩家走个几步还需要切换场景,每次切换...

    《游戏服务端发展史》转载请著名出处:http://www.skywind.me/blog/archives/1301

    类型4:第三代游戏服务器 2007

    从魔兽世界开始无缝世界地图已经深入人心,比较以往游戏玩家走个几步还需要切换场景,每次切换就要等待 LOADING个几十秒是一件十分破坏游戏体验的事情。于是对于 2005年以后的大型 MMORPG来说,无缝地图已成为一个标准配置。比较以往按照地图来切割游戏而言,无缝世界并不存在一块地图上面的人有且只由一台服务器处理了:

    image

    每台 Node服务器用来管理一块地图区域,由 NodeMaster(NM)来为他们提供总体管理。更高层次的 World则提供大陆级别的管理服务。这里省略若干细节服务器,比如传统数据库前端,登录服务器,日志和监控等,统统用 ADMIN概括。在这样的结构下,玩家从一块区域走向另外一块区域需要简单处理一下:

    image

    玩家1完全由节点A控制,玩家3完全由节点B控制。而处在两个节点边缘的2号玩家,则同时由A和B提供服务。玩家2从A移动到B的过程中,会同时向A请求左边的情况,并向B请求右边的情况。但是此时玩家2还是属于A管理。直到玩家2彻底离开AB边界很远,才彻底交由B管理。按照这样的逻辑将世界地图分割为一块一块的区域,交由不同的 Node去管理。

    对于一个 Node所负责的区域,地理上没必要连接在一起,比如大陆的四周边缘部分和高山部分的区块人比较少,可以统一交给一个Node去管理,而这些区块在地理上并没有联系在一起的必要性。一个 Node到底管理哪些区块,可以根据游戏实时运行的负载情况,定时维护的时候进行更改 NodeMaster 上面的配置。

    于是碰到第一个问题是很多 Node服务器需要和玩家进行通信,需要问管理服务器特定UID为多少的玩家到底在哪台 Gate上,以前按场景切割的服务器这个问题不大,问了一次以后就可以缓存起来了,但是现在服务器种类增加不少,玩家又会飘来飘去,按UID查找玩家比较麻烦;另外一方面 GATE需要动态根据坐标计算和哪些 Node通信,导致逻辑越来越厚,于是把:“用户对象”从负责连接管理的 GATE中切割出来势在必行于是有了下面的模型:

    image

    网关服务器再次退回到精简的网络转发功能,而用户逻辑则由按照 UID划分的 OBJ服务器来承担,GATE是按照网络接入时的负载来分布,而 OBJ则是按照资源的编号(UID)来分布,这样和一个用户通信直接根据 UID计算出 OBJ服务器编号发送数据即可。而新独立出来的 OBJ则提供了更多高层次的服务:

    • 对象移动:管理具体玩家在不同的 Node所管辖的区域之间的移动,并同需要的 Node进行沟通。
    • 数据广播:Node可以给每个用户设置若干 TAG,然后通知 Object Master 按照TAG广播。
    • 对象消息:通用消息推送,给某个用户发送数据,直接告诉 OBJ,不需要直接和 GATE打交道。
    • 好友聊天:角色之间聊天直接走 OBJ/OBJ MASTER。

    整个服务器主体分为三层以后,NODE专注场景,OBJ专注玩家对象,GATE专注网络。这样的模型在无缝场景服务器中得到广泛的应用。但是随着时间的推移,负载问题也越来越明显,做个活动,远来不活跃的区域变得十分活跃,靠每周维护来调整还是比较笨重的,于是有了动态负载均衡。

    动态负载均衡有两种方法,第一种是按照负载,由 Node Master 定时动态移动修改一下各个 Node的边界,而不同的玩家对象按照先前的方法从一台 Node上迁移到另外一台 Node上:

    image

    图11 动态负载均衡

    这样 Node Master定时查找地图上的热点区域,计算新的场景切割方式,然后告诉其他服务器开始调整,具体处理方式还是和上面对象跨越边界移动的方法一样。

    但是上面这种方式实现相对复杂一些,于是人们设计出了更为简单直接的一种新方法:

    image

    图12 基于网格的动态负载均衡

    还是将地图按照标准尺寸均匀切割成静态的网格,每个格子由一个具体的Node负责,但是根据负载情况,能够实时的迁移到其他 Node上。在迁移分为三个阶段:准备,切换,完成。三个状态由Node Master负责维护。准备阶段新的 Node开始同步老 Node上面该网格的数据,完成后告诉NM;NM确认OK后同时通知新旧 Node完成切换。完成切换后,如果 Obj服务器还在和老的 Node进行通信,老的 Node将会对它进行纠正,得到纠正的 OBJ将修正自己的状态,和新的 Node进行通信。

    很多无缝动态负载均衡的服务端宣称自己支持无限的人数,但不意味着 MMORPG游戏的人数上限真的可以无限扩充,因为这样的体系会受制于网络带宽和客户端性能。带宽决定了同一个区域最大广播上限,而客户端性能决定了同一个屏幕到底可以绘制多少个角色。

    从无缝地图引入了分布式对象模型开始,已经完全脱离 MUDOS体系,成为一种新的服务端模型。又由于动态负载均衡的引入,让无缝服务器如虎添翼,容纳着超过上一代游戏服务器数倍的人数上限,并提供了更好的游戏体验,我们称其为第三代游戏服务端架构。网游以大型多人角色扮演为开端,RPG网游在相当长的时间里一度占据90%以上,使得基于 MMORPG的服务端架构得到了蓬勃的发展,然而随着玩家对RPG的疲惫,各种非MMORPG 游戏如雨后春笋般的出现在人们眼前,受到市场的欢迎。

     

    类型5:战网游戏服务器

    经典战网服务端和 RPG游戏有两个区别:RPG是分区分服的,北京区的用户和广州区的用户老死不相往来。而战网,虽然每局游戏一般都是 8人以内,但全国只有一套服务器,所有的玩家都可以在一起游戏,而玩家和玩家之使用 P2P的方式连接在一起,组成一局游戏:

    image

    玩家通过 Match Making 服务器使用:创建、加入、自动匹配、邀请 等方式组成一局游戏。服务器会选择一个人做 Host,其他人 P2P连接到做主的玩家上来。STUN是帮助玩家之间建立 P2P的牵引服务器,而由于 P2P联通情况大概只有 75%,实在联不通的玩家会通过 Forward进行转发。

    大量的连接对战,体育竞技游戏采用类似的结构。P2P有网状模型(所有玩家互相连接),和星状模型(所有玩家连接一个主玩家)。复杂的游戏状态在网状模型下难以形成一致,因此星状P2P模型经受住了历史的考验。除去游戏数据,支持语音的战网系统也会将所有人的语音数据发送到做主的那个玩家机器上,通过混音去重再编码的方式返回给所有用户。

    战网类游戏,以竞技、体育、动作等类型的游戏为主,较慢节奏的 RPG(包括ARPG)有本质上的区别,而激烈的游戏过程必然带来到较 RPG复杂的多的同步策略,这样的同步机制往往带来的是很多游戏结果由客户端直接计算得出,那在到处都是破解的今天,如何保证游戏结果的公正呢?

    主要方法就是投票法,所有客户端都会独立计算,然后传递给服务器。如果结果相同就更新记录,如果结果不一致,会采取类似投票的方式确定最终结果。同时记录本剧游戏的所有输入,在可能的情况下,找另外闲散的游戏客户端验算整局游戏是否为该结果。并且记录经常有作弊嫌疑的用户,供运营人员封号时参考。

    类型6:休闲游戏服务器

    休闲游戏同战网服务器类似,都是全区架构,不同的是有房间服务器,还有具体的游戏服务器,游戏主体不再以玩家 P2P进行,而是连接到专门的游戏服务器处理:

    image

    和战网一样的全区架构,用户数据不能象分区的 RPG那样一次性load到内存,然后在内存里面直接修改。全区架构下,为了应对一个用户同时玩几个游戏,用户数据需要区分基本数据和不同的游戏数据,而游戏数据又需要区分积分数据、和文档数据。胜平负之类的积分可以直接提交增量修改,而更为普遍的文档类数据则需要提供读写令牌,写令牌只有一块,读令牌有很多块。同帐号同一个游戏同时在两台电脑上玩时,最先开始的那个游戏获得写令牌,可以操作任意的用户数据。而后开始的那个游戏除了可以提交胜平负积分的增量改变外,对用户数据采用只读的方式,保证游戏能运行下去,但是会提示用户,游戏数据锁定。

     

    类型7:现代动作网游

    从早期的韩国动作游戏开始,传统的战网动作类游戏和 RPG游戏开始尝试融合。单纯的动作游戏玩家容易疲倦,留存也没有 RPG那么高;而单纯 RPG战斗却又慢节奏的乏味,无法满足很多玩家激烈对抗的期望,于是二者开始融合成为新一代的:动作 + 城镇 模式。玩家在城镇中聚集,然后以开副本的方式几个人出去以动作游戏的玩法来完成各种 RPG任务。本质就是一套 RPG服务端+副本服务端。由于每次副本时人物可以控制在8人以内,因此可以获得更为实时的游戏体验,让玩家玩的更加爽快。

    说了那么多的游戏服务器类型,其实也差不多了,剩下的类型大家拼凑一下其实也就是这个样子而已。游戏服务端经历了那么多结构上的变迁,内部开发模式是否依然不变?究竟是继续延续传统的开发方式?还是有了更多突破性的方法?经历那么多次架构变迁,后面是否有共通的逻辑?未来的发展还会存在哪些困难?游戏服务端开发如何达到最终的彼岸?请看下节:技术的演进。

     

    展开全文
  • 导语:汽车之家移动主App服务端架构经历了从外包的架构概念,到流量激增后的架构调整、重构等。本文主要介绍了其主App服务端架构演进历程中面临的主要挑战、解决思路和实施过程。 随着移动互联网时代的到来,移动...

    声明:本文为《程序员》原创文章,未经允许不得转载,更多精彩文章请订阅2016年程序员:http://dingyue.programmer.com.cn/
    导语:汽车之家移动主App服务端架构经历了从外包的无架构概念,到流量激增后的架构调整、重构等。本文主要介绍了其主App服务端架构演进历程中面临的主要挑战、解决思路和实施过程。

    随着移动互联网时代的到来,移动技术也随之飞速发展。如今,App已然成为绝大多数互联网企业用来获取用户的核心渠道。以往以PC为主要承载平台的各业务线,源源不断集成加入到移动项目中来,原本以产品为中心快速迭代的单一开发模式,已经无法应对这汹涌爆炸式的业务接入和高速增长。同时伴随着用户量的增长,流量的持续暴增,系统架构面临的一系列挑战和转型。怎么构建出高可靠、高扩展、低成本、多快好省系统体系架构已成为业界乐而不厌的长谈话题。

    发展

    2010年-2012年

    2010年移动端刚刚兴起,公司组建了移动团队(刚开始就几个人)带领着一家外包公司做了第一版。当时业务十分简单,即把PC端的论坛文章等直接搬App端进行展示,服务端也是ALL IN ONE的结构,也没有架构的概念(如图1),虽然系统耦合严重、但流量低也不见明显的问题。

    图片描述

    图1 服务体系结构

    2013年-2014年

    2013年公司上市,业务扩展,移动端流量开始增长,特别是2014年。

    2014年末流量较年初增长了2.5倍。而原来的这种ALL-IN-ONE体系结构的弊端日益凸显,服务端经常由于高峰期的访问压力宕机。这种高耦合的结构常常由于某一个接口的超限流量导致其他接口也不能正常访问。

    而随着业务的不断扩张,应用的不断迭代导致应用的体积不断增大,项目越来越臃肿,冗余增加,维护成本水涨船高……老架构力不从心。

    面对日益严重的服务压力,公司开始组建自己的移动研发团队(C#+SQL Sever),服务端程序进行了第一次重构。

    图片描述

    图2 服务体系结构

    服务端程序进行对应用分层(接口层API、业务逻辑层Service、数据访问层DAO)、分割(根据App端的各个模块把原来的ALL-IN-ONE的结构分割成不同服务)、做动静分离CDN加速、读写分离、集群负载。同时公司运维部根据我们的业务特点研发自己的CDN服务、二级缓存SCS服务对应用做进一步加速,经过这次改造,暂时缓解了服务端的压力。

    2014年-至今

    我2015年初加入汽车之家,当时移动端面临的问题如下:

    • 请求量更大,应该说是流量暴增的时代:2015年9月,汽车之家移动端日均独立用户总访问量较2014年9月同比增加约73.0%。2016年初移动端PV实现亿级。

    • 依赖资源多: 依赖Redis、DB、RPC、HTTP、MongDB、MQ、数十个业务。

    • 垂直业务耦合严重:如帖子、文章最终页和评论系统这种垂直耦合业务常常出现评论系统挂掉导致帖子或文章最终不能访问的情况。

    • 运营推广活动多:为了增加用户粘度,提高用户活跃度,各个业务方和我们自己的运营推广活动大量增加。

    • 发版快:每月固定两次发版,多版本并存。

    • 微软技术体系:微软收费服务都需要大把白花花的银子,且高质量的.NET工程师越来越难招,生态圈不太景气。

    为了应对流量的暴涨,服务的高可用性和团队变大,所有开发人员集中针对同一个系统的严重冲突,App端进行插件化改造。服务端2015年初也开始了二次重构计划,进行了一次脱胎换骨的转型,全面拥抱Java,主要的技术改变有:

    Windows→Linux、SQL Server→MySQL、IIS→Tomcat、C#→Java。

    重构

    需求方面主要有这几点:文章、帖子的评论这种垂直业务不能挂掉;业务爆发能够快速实现;依赖(多业务方、多资源)解耦,故障时绝对不允许相互影响。

    解决方案分为以下几步:

    • 分解。首先是团队:根据App插件化的划分,对服务端团队研发人员进行分组,各小组只负责自己的模块,每月固定的两次迭代,各小组服务独立上线互不影响。其次是服务结构,包括水平扩展:多集群、多机房部署提高并发能力和容灾能力;垂直拆分:垂直业务进一步拆分,依赖解耦;业务分片:按功能特点分开部署,如活动、秒杀、推送等物理隔离;水平拆分:服务分层,功能和非功能分开,基础核心服务非核心服务分开。

    • 业务服务化,相互独立,如咨询、论坛、广告等。

    • 无状态设计。调用链路无单点、无状态服务,可线性扩容(尽可能不要把状态数据保存到本机、接口调用做到幂等性)。

    • 可复用。复用的粒度是业务逻辑的抽象服务,不是服务实现的细节、服务引用只依赖服务抽象。

    • 资源分层。Redis、DB、MQ 主从设计,多机房部署、保障高可用。

    • 松耦合、自保护、防雪崩。跨业务调用尽可能异步解耦,必须同步调用时设置超时、队列大小、线程池大小、相对稳定的基础服务与易变流程的服务分层;线程池保护,超出服务器最大线程时DROP请求(Nginx、Tomcat)。Redis、DB、MQ、Turbo(RPC)、HttpClient等在后端资源出问题时可以自动降级请求调用、发送异常报警。

    • 服务隔离可自理。服务可降级、可限流、可开关、可监控、白名单机制。

    • 各个服务独立部署互不影响,服务异常自动熔断,根据各个服务特点走相应的降级策略。基础服务下沉可复用基础服务自治、相互独立、基础服务要求尽量精简可水平扩展、物理隔离保证稳定(如用户中心、产品库)。

    • 分清核心业务。核心业务服务尽量精简,利于稳定(运行时优先保证主流程顺利完成、辅助流程采用异步:如日志上报)。

    图片描述

    图3 单服务结构

    实现

    • 单服务的体系结构

    App端请求经过接入层(CDN、LVS、NG/SCS),通过接口控制层的设置校验(CDN配置、反劫持配置、日志服务配置、安全校验……)调用API层发布的REST接口,通过参数校验后调用业务逻辑层的业务实现。同时业务逻辑层通过数据接口层(SourceInterface源接口服务、DbUtils数据库分开分表组件、AIS4J异步请求组件、Trubo RPC服务)调用资源层的资源服务来完成本次业务的数据组装,完成本次业务的调用。

    配置方面,一个基于zookeeper的配置服务(配置服务用于系统的各种开关的实时配置如:源接口的限流熔断阈值等);Monitor:监控服务实时查看系统异常、流量;Trace:系统跟踪服务;Log:(日志服务)。

    • RPC-Trubo体系结构

    图片描述

    图 4 Turbo(RPC框架)结构

    为了应对服务化作服务自理,2015年底我们全面启用公司的RPC服务Trubo
    框架特点主要有:多语言服务端发布,支持C#和Java;高效透明的RPC调用,多协议支持;基于ZooKeeper的注册中心,用于服务发现;客户端软负载和容错机制;使用Spark进行服务监控与跟踪Trace分析;整合Locker(Docker调度平台),实现服务部署自动化。

    服务发现与RPC稳定性和容错方面,主要是双机房部署ZooKeeper集群,主力机房5个节点(Leader/Follower集群),其他机房2个节点(Observer节点),保证性能和稳定性;Trubo客户端服务端添加守护线程,定时校验本地缓存和ZooKeeper的数据一致性;Trubo客户端会将缓存的服务信息持久化到本地,即使ZooKeeper挂掉或者重启也不影响正常调用;嵌入Trace客户端上报收集分布式跟踪日志。

    • 异步请求组件AIS4J

    图片描述

    图5 异步请求组件AIS4JJ

    为了解决接口和资源依赖问题(源站或Redis、DB等资源层挂掉导致我们服务不可用的高风险),同时也为了请求响应时间受到源站依赖问题,我们封装了异步请求组件AIS4J。同时嵌入我们的熔断限流组件来对源站进行解耦。

    引入AIS4J后大大缓解了对外部资源的依赖,提高了服务的可用性,但同时也带来了一些问题。公司要求对缓存内容时间限定在10分钟以内,原来的时间被平均分配到了CDN和我们的二级缓存SCS上,现在加入这个组件为了满足10分钟的要求必须把原来的10分钟拆分到AIS4J上,这就需要增大系统接口的回源率(10%左右)。这个时间就要对请求时间和系统压力上做一个权衡。

    服务监测

    就目前阶段来说,服务分解封装应对一段时间的流量增长已没太大问题。但为了保证服务的高可用、系统的扩容预估、故障的实时定位……就必须有一套完善的监测报警系统。

    图片描述

    图6 Trace架构

    图7是系统调用追踪服务,通过对程序Java的Instrumentation和配置系统对系统程序进行埋点跟踪,再通过Spark对跟踪日志进行实时分析展现。

    图片描述

    图7 监控报表

    图片描述

    图8 Trace实现

    Trace实现

    Trace ID标识唯一调用树,Transaction ID标识唯一次调用,一次Trace调用会产生四条日志,Trace调用树可以由Turbo、本地调用、HTTP或其他调用方式组成,Trace客户端是独立的,Turbo单向依赖Trace。

    图片描述

    图9 服务调用链图

    同时我们在APP端的请求头中埋入Req ID,通过Req ID和Trace ID的对接记录一次请求过程(CDN、SCS、后端服务、RPC/HttpClient调用)每一步的时间消耗。

    图片描述

    图10 debug模式信息展示

    为了更快的定位稳定,我们在程序中预设了Debug模式,在内网环境中只要拿到请求的URL开启Debug模式就可以快速的调出系统调用资源链和每一步的程序调用消耗时间。

    报警实现

    通过Spark对日志记录的分析结果,会实时对接到我们的报警系统上,实现对程序异常的实时报警。报警系统通过短信、邮件方式发生,内容中包含请求的Trace ID超链到报表系统实现对异常问题的实时查看定位。

    作者简介:汤泉,2015年加入汽车之家,参与到移动主软件服务端的架构设计与开发。
    责编:钱曙光(qianshg@csdn.net)
    本文为《程序员》原创文章,未经允许不得转载,更多精彩文章请订阅2016年程序员:http://dingyue.programmer.com.cn/


    2016年4月22日-23日,由CSDN重磅打造的SDCC 2016数据库&架构技术峰会将在深圳举行,目前18位讲师和议题已全部确认。两场峰会大牛讲师来自百度、腾讯、阿里、京东、小米、唯品会、滴滴出行、携程等知名互联网公司,共同探讨高可用/高并发/高稳定/高流量的系统架构设计、秒杀系统架构、搜索架构、中小企业架构之道、数据平台系统演进历程和技术剖析、传统数据库与分布式数据库选型/备份/恢复原理及优化实践、大数据应用实战等领域的热点话题与技术。【目前限时6折,点击这里抢票

    展开全文
  • nodejs服务端MVC架构介绍

    千次阅读 2019-10-21 23:49:40
    以nodejs数据管理系统为例,本文章代码仅为服务端演示代码,单独复制粘贴可能效果。因为MVC并不是一门技术,而是一种项目架构思想 index.js:负责接收请求 router.js:负责将请求分发给C层 controller.js:C层负责...

    nodejs服务端MVC架构介绍

    MVC架构本质:确定每一个js文件的职责
    以nodejs数据管理系统为例,本文章代码仅为服务端演示代码,单独复制粘贴可能无效果。因为MVC并不是一门技术,而是一种项目架构思想

    • index.js:负责接收请求
    • router.js:负责将请求分发给C层
    • controller.js:C层负责处理业务逻辑(V与M之间的沟通)
    • views:V层:负责展示页面
    • model: M层:负责处理数据(增删改查)

    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述

    /* 路由模块:只负责分发网络请求给C层,不处理 */
    //导入C层
    const controller = require('./controller.js');
    
    //1.导入express模块
    const express = require('express');
    //2.创建路由
    var app = express();
    
    
    //路由分发
    //Express支持链式语法
    app.get('/',controller.showHeroList)
    .get('/heroList',controller.getHeroList)
    .post('/heroAdd',controller.doHeroAdd)
    .get('/heroInfo',controller.getHeroInfo)
    .get('/heroDelete',controller.doHeroDelete);
    
    
    //3.导出路由模块
    module.exports = app;
    
    /* C层:负责业务逻辑处理:M与C层之间的沟通 */
    
    //M层:操作数据库增删改查
    const hero = require('./model/hero.js');
    
    module.exports = {
        showHeroList: (req, res) => {
            //服务端重定向到view/heroList.html
            res.writeHead(302, {
                'Location': 'views/heroList.html'
            });
            res.end();
        },
        getHeroList: (req, res) => {
            //1.展示首页列表数据
            hero.find((err, jsonData) => {
                console.log(jsonData);
                if (err) {
                    throw err;
                } else {
                    res.end(jsonData);
                };
    
            });
        },
        doHeroAdd: (req, res) => {
            //完成解析之后,将得到的数据存入json文件
            hero.add(req.body, (err) => {
                if (err) {
                    //服务端不能直接返回js对象,因为服务器是给所有客户端使用,需要返回json对象
                    res.end(JSON.stringify({
                        err_code: 100,
                        err_msg: err.err_msg
                    }));
                } else {
                    res.end(JSON.stringify({
                        err_code: 0,
                        err_msg: 'success'
                    }));
                }
            });
        },
        getHeroInfo: (req, res) => {
            var heroID = req.query.id;
            //处理
            hero.find(heroID, (err, data) => {
                if (err) {
                    throw err;
                } else {
                    res.end(data);
                };
            });
        },
        doHeroDelete: (req, res) => {
            //(1)获取请求参数
            let heroID = req.query.id;
            //(2)处理请求
            hero.delete(heroID, (err) => {
                if (err) {
                    throw (err);
                } else {
                    //服务端重定向刷新首页
                    res.writeHead(302, {
                        'Location': 'views/heroList.html'
                    });
                    res.end();
                }
            });
        }
    }
    
    展开全文
  • Java EJB中有、状态SessionBean的两个例子 两个例子,状态SessionBean可会话Bean必须实现SessionBean,获取系统属性,初始化JNDI,取得Home对象的引用,创建EJB对象,计算利息等;在有状态SessionBean中,用...
  • APP和服务端-架构设计(二)

    千次阅读 2017-05-07 11:20:30
    现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息。实现上,大部分
  • java 面试题 总结

    2009-09-16 08:45:34
    但通常情况下,由于Java Bean是被容器所创建(如Tomcat)的,所以Java Bean应具有一个参的构造器,另外,通常Java Bean还要实现Serializable接口用于实现Bean的持久性。Java Bean实际上相当于微软COM模型中的本地...
  • 服务端接口设计,App架构设计

    千次阅读 2016-09-20 15:02:58
    安全机制的设计:现在大部分的App接口的设计都是采用RESTful,而RESTful的设计的原则是客户端与服务端的交互是状态的.也就是说,如果要做用户校验,那么每次请求都要带上验证信息.那么一般实现为token:1.用户用密码...
  • 一、众所周知,在大厅+子游戏模式中,...中央集群式的优点就是架构简单,每个进程只需要维护与中心服的连接就行。中心服还能够实时监测各进程状态,并向所有节点广播。 中央集群式的缺点就是这个中心服单点。中心服...
  • 现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息。实现上,大部分都采用token...
  • JAVA上百实例源码以及开源项目

    千次下载 热门讨论 2016-01-03 17:37:40
     Tcp服务端与客户端的JAVA实例源代码,一个简单的Java TCP服务器端程序,别外还有一个客户端的程序,两者互相配合可以开发出超多的网络程序,这是最基础的部分。 递归遍历矩阵 1个目标文件,简单! 多人聊天室 3...
  • WebApi服务端开发框架全部开源,购买既授权使用,程序功能限制。开源软件最大的优势是使用者可以自定义软件架构、修改框架核心类库、定制软件开发模板来提高开发效率,满足不同项目需求。 一次性付款一次性交付...
  • 服务器架构的重要意义服务器架构的重要意义 对于 服务器(Serverless)架构,什么时候该用,什么时候不该用呢? 如果将如今互联网体验中最方便实用的那一部分去掉,那么留下来的基本就是 客户端-服务端(client-...
  • 【译者的话】这篇文章介绍了服务器架构与传统架构相比的优势,与此同时,也指出了服务器架构并非适用于所有的应用,但了解这种架构模式对于开发者或者企业来说都是大有裨益的。 【3 天烧脑式基于Docker的CI/CD...
  • (经常被问到承载上限,kbengine底层架构被设计为多进程分布式动态负载均衡方案, 理论上只需要不断扩展硬件就能够不断增加承载上限,单台机器的承载上限取决于游戏逻辑本身的复杂度。) 官方主页:...
  • NIO高级编程与Netty入门 一、NIO同步阻塞IO&NIO非阻塞IO IO(BIO)与NIO的区别:其本质就是阻塞IO和非阻塞IO的区别。...我们所用的IO都是同步阻塞式IO也叫BIO ...阻塞:应用在获取网络数据的时候,如果网络...

空空如也

1 2 3 4 5 ... 20
收藏数 565
精华内容 226
关键字:

无服务端架构