衡量一个产品的成败，往往不同的角度理解是不一样的。从开发者的角度来看，判断一个产品是否成功，我们往往首先判断产品是否满足用户的需求。对于有性能扩展需求的产品，还需要考虑其是否具有高性能，是否方便后期扩展；对于有代码整洁度的开发者来说，还要看代码编写是否规范等等。今天我们先来了解一下这款产品的架构是如何设计的，然后再说说它的服务器的功能。首先简单说明一下架构中的重点考虑：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)：为了防止恶意连接到反向代理服务器，负载均衡服务器为每个网吧生成一个时间敏感的会话。(3)：接收反向代理服务器发来的消息，对网吧账号和session进行认证。2：日志服务器：(1)：记录所有服务器的日志信息。(2)：对所有日志进行关联分析，提取Error级别的日志，并将此类日志存入数据库。3：监控服务器：（1）：监控所有服务器的运行情况，自动运行异常和宕机的服务器程序，并向相关负责人发送短信告警。(2)：定期从Error日志数据库中提取相关日志，将信息汇总后以短信（邮件）的形式发送给相关负责人。
