一个坑

项目架构思路讨论

这篇文章不是什么技术分享,而是对现有项目的一些思路的整理。如果搞新项目的同僚可以一起讨论和借鉴。

先说下我现在的项目情况:
项目规模中等,以一个用户中心为核心(主项目),分支多个功能模块(子项目),如返利模块,分享模块,微博模块,CMS模块等等。项目需要有很好的纵向扩展能力,因为后期会继续增加各种功能模块,并且各个模块之间可以灵活调用数据。如微博模块可以调用分享模块里的数据等等。开发语言已PHP为主,PYTHON参与部分cron脚本,后期要考虑JAVA或C#的加入。

所以这里有3个难点:第一个就是可扩展,第二个就是项目模块之间的数据调用,第三个就是不同语言之间的协作。

这里要注意的是,这个是个中型项目,由好几个子项目组成。每个项目都要当做一个独立的项目来管理,如,有独立的web服务器,独立的数据库。
当然有人问,为什么不能都搞一起,数据量大了搞分布式,图片分布式,数据库分布式,文件分布式,都有很好的解决方案。但是,从我这些年来的项目经验来看,永远都是根据业务拆分项目来的合理,利于开发和维护。一般都项目拆分之后,单个项目数据量庞大到单台或几台服务器无法支持的时候,再考虑分布式的解决方案。

项目中的问题:
一开始,项目不是很庞大,所以只有一个项目,4台服务器,所有的PHP,JS,CSS都在一台WEB服务器上。数据库配置一主一从。开发人员2PHP 2前端 1运维。因为项目初期,流量不高,此配置足以满足需求。这个也是一个简单项目的基本配置。

之后,由于项目扩张。增加了几个子项目,慢慢感觉项目开始臃肿,代码难以维护。试过重构(把多余的重复的代码精简,清晰化各个模块),分离(把JS代码尽可能的分离维护),缓存(增加Memcache和Redis),优化(优化模型层,服务层)。同时,机器加到20多台(为了搞分布式和采集),开发人员也上升到5PHP 3前端 2运维,还是起不到好的效果。比如多个项目平行开发。经常由于一个项目延工,引起另一个项目拖延的恶性循环。由于数据量和图片量的提升,又尝试MFS,MYSQL Cluster,都不尽如人意。

MFS的问题:6台机器(可能是由于机器不够多,或者机器内存不够),图片读取还是不错的。但是大批量的图片写入就不太吃得消了(采集)。

MYSQL Cluster的问题:同样也是6台机器,刚刚配好,开始使用就发现一个问题,联表查询稍微多点的数据就会非常慢。最后的决策是尽量不使用的联表查询,当然,这大大增加了开发成本。中间还有很多其他的问题,都是Cluster的限制,比如事务,表的存储引擎冲突等等。

最后,索性就全部推倒从头来过。

1、项目重新规划,保留了必要的项目,重新确立了以用户中心为核心项目,其他项目为扩展的开发方向。设立项目经理,管理整个项目的开发以及产品之间的沟通协调。设立测试员,对项目上线以及上线之前的版本测试。

2、服务器重新架构。重新架了Mysql主从,1主2从,并设立DBA工程师管理数库,保障数据库的稳定和安全。彻底放弃MYSQL Cluster和MFS。把多出来的服务器,用在了负载均衡和Cache服务器上。所有的线上服务统统配备备用服务器。重新整理了各个服务器上的服务,比如把非线上环境的服务和线上必须的服务区分开。讨论和整理事故预案、事故评级和处罚制度。主要的目的都是增加服务器的可靠性。

3、项目架构重新整理。主要是为了解决前面说的3个难点。引入了XML-RPC服务的概念。

QQ截图20130523222638

 

如上图:

RPC相当于一个中间的业务层,主要负责的是数据的操作,像数据缓存,分表数据聚合,大数据处理等都可以放在这里实现。而前端项目只需要考虑如何把数据表现在视图层就行。

RPC的出现,很好的解决了以上的三个难点。同时彻底轻量级前端项目,所有的程序员都可以根据能力水平,分配对应的工作,只需规范文档,就能很好的处理合作开发。当然,换成现在比较流行了RESTful也是可以的。RPC项目如果庞大,同样也可以分成多个RPC项目。RPC分项目尽量是根据DB业务来分。

目前项目改造还在试验阶段,中间难免会碰到很多问题,比如RPC的可靠性,是否增加了开发成本等等。但总体来说,比之前的开发要顺畅多了。