今天整理文档时找到这份2009年底写就的优化思路，只是当笔记的整理编写。用来指引今年的工作方向，但最终没有深化落实执行下去就离开了旧东家，实在可惜。
1. 概述
基于JAVA版本的游戏圈子平台于2008年8月18日正式上线运行，期间经历过多次改版及进行过一些架构调整。经过这一年半左右的时间积累，业务架构趋向清晰化，产品接口也趋向复杂化多样化，有必要在现阶段进行一次技术架构的优化及结合业务变化做出一些架构构想，便于下一阶段平台建设时作为指导思想进行架构调整。同时，整理该份文档，有利于我们清晰现存的体系架构及面临的风险。
2. 优化的目的
为什么要做优化? 不外乎如下几种原因：- 节省资源，服务器、网络资源
- 消除或者减少系统瓶颈
- 提升用户体验
此外，或许也有炫技的因素在内，为了优化而优化，当然这是不可取的做法。
3. 一些数据
- * M注册用户，约*万个活跃用户(基于200912的唯一用户登录游戏数据推算)
- 1M综合浏览量/月
- MySQL数据库稳定运行了211天，共792M次数据库查询请求，43.292 qps/天
- 数据库读写比例是：r 74%/w 26%
- 数据库峰值416个连接
- 有9台PC服务器在运行
- 其中6台提供线上服务，3台提供运维支撑
- 2G memcached deamon
4. 平台架构
现在游戏圈子平台主要使用JAVA和RUBY作为主要的开发语言实现。并且在部分产品上使用一些脚本语言来进行系统的维护支持，如：Lua、perl、php、python等。JAVA部分包含旧有的遗留产品和平台的核心服务接口，如：论坛、支付中心、游戏登录和支付接口、后台服务进程等等。JAVA应用分为WebApp和独立运行的应用程序。WebApp运行在Resin 3.1.6应用服务器上，JVM配置2GB的最大可分配内存。
RUBY部分包含一些前端服务页面，现在只要有三个应用使用RUBY实现：帐号中心，个人管理中心，所有产品运营活动。RUBY运行于Lighttpd+FastCGI基于TCP/IP监听模式，每个应用同时开启5个backends进程进行处理，每个进程各稳定占用45 - 60mb内存不等，共3个应用，约占总内存 50 * 3 * 5 = 750mb
数据库使用MySQL 5.0.51b-log版本，运行在一主两从的复制模式。其中一台从机未有效利用，只能当备份库使用，存在资源浪费；另一台从机用来进行OSS数据分析查询使用。主库配置使用mysql 4GB内存的例子配置文件修改配置。
其中三台IBM的机器因挂接的磁盘柜只支持Red Hat,所以操作系统使用Red Hat Enterprise AS 4，内核是Linux 2.6.9-67。其他机器统一安装CentOS 5.2，内核是Linux 2.6.18-92.e15。
5. 找寻瓶颈在哪
如果我们需要系统优化，我们应该能够找到性能瓶颈，但现在系统的瓶颈还没有出现，是否不需要优化呢？系统的瓶颈会在何方呢？如果系统有完善的监控分析系统的话，可以从统计数据和图形上看到大致的系统瓶颈所在。但是如果系统没有这些数据，按照一般的逻辑思路分析，将服务器细分为静态服务器，动态服务器，数据库服务器，业务逻辑服务器。分别针对这些服务器的带宽、内存使用、CPU使用率、磁盘IO进行基本分析。如对于动态服务器而言，其CPU的使用率一般情况下是其瓶颈；而对于静态文件服务器，由于其逻辑简单，但又需要传输大量文件，其出口的带宽、磁盘IO就很有可能是其瓶颈；数据库服务器则CPU和磁盘IO都可能瓶颈…我们需要根据这些数据结合经验来判断系统的负载是否达到瓶颈或接近瓶颈的预警判断。这些数据基于操作系统本身已经可以获取，而不需要我们去开发很复杂的应用监控。但系统本身产出的性能数据是不保存的，更理想的是，我们应该将利用一些开源软件组建一套更好的监控工具。
幸运的是，我们已经有一套现在看起来还非常不错的监控工具在运行着。而瓶颈通常还存在下面的问题：单点服务。
6. 寻找服务单点故障(Single Point of Failure)与高可用性（High availability）
系统是否需要负载均衡，是否需要避免单点？如何避免单点提高可用性是一个持续的课题。单点故障从基础的硬件层，操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。以上各个环节任何有一处出了毛病就造成部分或整体网络、服务受到影响，最简单的解决方法就是做冗余设备和服务，其次再进一点，做层次化便于隔离问题。隔离问题有助于我们发现单点，解决单点。
而可用性并不是一个模糊概念，实际上它能用数学方法来精确地表示。简单地讲，一个高可用性系统就是一个用户能随时使用的系统，例如当用户需要在早上8点到下午5点启用该系统时，该系统就应该在这段时间内保证良好的可用状态，其余的时间可以用来进行定期维修保养。可用性常被定义为实际的服务时间和要求的服务时间的比值，常用百分比表示。许多现代化系统需要一天24小时、一年365天连续不间断运转(有时也称为7×24或365×24)。一个可用性为99.9%的365×24系统一年的平均故障时间为8.76小时(525分钟)，而要想让系统的中断时间在一年中只有3分钟的话，系统必须有99.999%的可用性。
7. 系统架构的发展方向
- MySQL版本升级，打入性能优化补丁
- 高可用性架构设计
- 寻找并解决单点故障防患
- RUBY优化，安装RUBY企业级补丁
- 完善服务点监控，建立服务成功率KPI
- 思考应用整合，接口整合，建立企业级系统架构服务
- 服务器应用清理调整，运维服务器与生产服务器分开
- 平台向分布式系统过渡
所以必须持之以恒的去探讨我们的架构，监控我们的系统，随时解决各种问题
8. 未来三个月目标
- 优先MySQL
- MySQL 5.1已经发布了多个稳定版本，可以考虑升级,以获取性能20%的提升。
- Google为MySQL编写的开源性能优先补丁，经众多网站使用确实能为系统带来稳定性和高效率。
- 参考MySQL 5.1手册，调整优先参数
- 优先Ruby
- 打入Ruby Enterprise Edition补丁。
- 生产与运维环境分离
- 开发评估设计系统应用架构，消除应用单点，高可用性设计方案
- 登录接口(Socket/WebServices)
- 网站平台前外服务(Web)
- 内部应用系统总线架构(SOA)
- 数据库读写分离架构
- 运维评估网络设备单点及服务高可用性方案
- 产品策划上从注重UI过渡到UE，应该给使用者一种「当然，应该这样」的感觉