衡量一个产品的成败，往往所站的角度不同理解也就不同。站在一个开发人员的角度来看，判断一个产品是否成功，往往首先判断这款产品是否满足用户的需求。对于有性能扩展要求的产品，则还要考虑其是否具有较高的性能、是否便于后期扩展；对于具有代码洁癖的开发者来说，则还要看代码编写是否规范等等。
今天我们先来了解一下这款产品的架构是如何设计的，再说说它的各服务器的功能。
首先我简单说明一下架构中需要重点考虑的几点：
1：网吧断网时的处理：架构设计中要考虑到网吧和中心服务器断网的情况，所以简单的按照MMO游戏的设计方式是不可行的（这种情况虽不常见，但是经常会由于网络不稳定而出现，有时也会因为一些其它原因而导致，例如某地区曾出现一整年断网情况），所以架构设计时需要处理：当网吧服务器和中心服务器断开后，网吧要能进行正常的业务处理；同时，当网吧服务器和中心服务器重新建立连接以后，需要将网吧在断线时间段内所处理的所有数据重新的发送到中心服务器上，并进行继续处理。
2：网吧业务连续性：对于网吧业务来说会存在一定的业务连续性，例如网吧的业务一定是先上机，后下机。这种业务如果处理顺序错乱，后果不堪设想。
3：网吧数据不准确：由于可能出现网吧网管勾结外部人员修改网吧营业数据的情况，因此网吧本地的数据不存在可信性（这里的数据指的是诸如营业流水等数据），需要中心服务器记录网吧所有的营业情况，并以重新计算得到的数据为准。
4：网吧数据产生的时段性：去过网吧的人都知道，网吧在一天之中业务数据产生的时间并非都是均匀的，例如在晚上10点以后到第二天7点左右（各网吧情况不同而定）一般是很少产生业务数据的，因为这段时间属于通宵包机时间；而在早晨8-9点属于网吧清场开业时间，这段时间会有数据大量产生。同时在周末的时候网吧也会出现业务数据产生的高峰期。基于以上的情况，架构的设计要能处理网吧业务数据瞬间变高的情况。
以上4点是系统设计时所要重点考虑的，尤其是第一点（是不是觉得考虑得很周到？但我要剧透的是，这种面面俱到的考虑其实是华丽丽的自虐。这个问题我以后会详说）。
我设计的架构图是这样的：
在这个架构中每个核心服务器的功能概要说明：
1：网关服务器：
（1）：用来接收大量的并发网吧服务端连接请求。
（2）：接收网吧服务端的业务请求后，根据请求类型进行分析，并将请求发送给相应的后端业务处理服务器。
（3）：接收后端业务处理服务器返回的业务处理数据，并将此数据转发给相应的网吧服务端。
2：帐号服务器：
（1）：对网吧的帐号信息进行合法性验证。
3：上报服务器：
（1）：接收网吧业务中需要上报的业务（例如：用户上机、下机、加钱、积分转换等等）进行业务逻辑处理。
（2）：由于网吧业务存在前后逻辑关系，因此在处理的时候需要对网吧上传的业务进行顺序性处理。
4：同步服务器：
（1）：检测网吧服务端相关数据是否和中心数据库中的一致（费率数据、会员数据、营业流水等等），对于不一致的数据，采用同步方式强行让网吧数据和中心数据库数据一致。
外围服务器功能概要说明：
1：负载均衡服务器：
（1）：针对网吧帐号、所在区域等等信息对网吧应该连接的反向代理服务器的IP和端口进行指定。
（2）：为了防止恶意连接反向代理服务器，负载均衡服务器为每一个网吧生成具有一定时效性的session。
（3）：接收反向代理服务器的消息，对网吧帐号和session进行认证。
2：日志服务器：
（1）：记录所有服务器的日志信息。
（2）：对所有日志进行相关分析，提取出Error级别的日志，并将此类日志保存在数据库中。
3：监控服务器：
（1）：监控所有服务器的运行情况，对于出现异常而宕掉的服务器程序进行自动运行，并向相关负责人发送短信报警。
（2）：定时从Error日志数据库中提取相关日志，并将信息进行汇总后以短信（邮件）的方式发送给相关责任人。
对一个“失败”项目的审视—架构