手机之家新系统介绍及架构分享

手机之家新系统介绍及架构分享 IMOBILE TEAM 2009.03.29

手机之家首页

一）手机之家新系统介绍 1) 关于手机之家 2) 新系统概览二）软件架构分享 1) 架构演变与发展 2) DAL 设计概览 3) 持续改进三） Q & A 目录

手机之家新系统介绍

关于手机之家手机之家是一个旨在提供全方位的手机相关服务的资讯类网站。在 7 年的时间里，手机之家从无到有，已经发展成为极具人气、最受关注的手机产品资讯网站。目前已有的一些统计数据： a. 1000w+ 用户 b. 3000w+ 帖子 c. 1.1TB+ 附件 d. 780w+ Page View/ 每天 e. 5~10w 在线用户 /15 分钟

新系统概览 (1)‏ a. 从头设计、全部重写 b. 100% 采用开源软件 c. 自行开发： Web 层： MVC 框架 , 模板引擎 , JS 框架 ... 基础组件：简单的 glue, Monkey(Java NIO 框架 ), JMCL ... 中间件： DAL(Data Access Layer), JMCD, Session, Tools, 小文件存储系统 , 基于 Lucene 的搜索系统 ... d. 混合编程： PHP+JAVA e. 操作系统： centos5; 数据库： MySQL5; Web Server: Nginx

新系统概览 (3)‏ Logic MySQL Model MySQL MySQL DAL 中间件 Ctrl View Web

软件架构分享

架构演变与发展 - 老系统的问题

a) 由于系统分层比较模糊，导致问题极难排查，到底是哪个层面出现了错误

？是页面相关的地方、访问数据的地方，还是处理逻辑的地方？

b) 由于 web server 可以直接访问 db server ，在高峰阶段，并发量比较

大，导致 db server 经常 down 掉。

c) 数据表结构设计不当，导致无法很简单地 ( 甚至不可能 ) 进行竖直和水平

方向的伸缩。

没有设计！

HTTP MySQL MC 数据访问层表现层逻辑层 FastCGI MySQL 架构演变与发展 - 纯 PHP 分层方案 (1)‏ R W

架构演变与发展 - 纯 PHP 分层方案 (2)‏ 方案 (1) 解决了之前所说的问题。但是： a) 开发一个功能，要写很多代码，而且有大部份代码是相当乏味的，重复性极高，千篇一律，特别是数据访问层代码。 b) 程序员自己控制缓存。这使得： <1> 缓存代码渗透到业务逻辑的每一个角落，造成代码维护成本上升。 <2> 程序员根据自己的喜好来控制缓存的 KEY 和 VALUE ，造成缓存混乱。 <3> 程序员既要负责业务逻辑的编写，还要负责缓存管理，造成编程复杂度提高、开发效率低下。这些问题，迫使我们寻找其它的解决方案。。。

架构演变与发展 - 改进缓存 (1)‏ 我们对数据库记录的缓存的访问做了一定的抽象处理，开发出了 cache 处理器。所有的数据访问都经过 cache 处理器。这样，系统代替程序员接管了缓存的存取访问。缓存的 KEY 和 VALUE 由系统处理，从而避免了冲突和混乱。 cache 处理器的引入减少了 40% 的数据访问层代码！最重要的是，我们采用了 Namespace 的方法使得缓存能自动清除了。

HTTP MySQL MC 表现层逻辑层 FastCGI 架构演变与发展 - 改进缓存 (2)‏ R W cache 处理器数据访问层 cache 处理器 NS 处理器 php fcgi + SQLite 实现

架构演变与发展 - 改进缓存 (3)‏ 但是问题又来了，此时，系统响应速度变得很慢。原因在于，我们 Namespace 是借助 PHP fcgi 进程 +SQLite 来实现的。这促使我们对采用纯 PHP 方案的可行性产生了质疑。。。

架构演变与发展 - PHP+JAVA, 提升性能 (1)‏ memcached 不支持 namespace ，也不支持遍历。所以，我们基于之前开发的 monkey(java nio 框架 ) 实现了一个支持 namespace 遍历功能的内存缓存程序 – jmcd 。我们采用了简单高效的 STP 协议。

架构演变与发展 - PHP+JAVA, 提升性能 (2)‏ HTTP MySQL MC 表现层逻辑层 FastCGI R W cache 处理器数据访问层 cache 处理器 NS 处理器基于 JMCL 实现

架构演变与发展 - PHP+JAVA, 提升性能 (3)‏ 我们改进了 Session 的实现方式：在 monkey 和 jmcl 的基础上开发出 session server 。这次响应时间提升了 80 毫秒以上！这基本上达到了性能预期：平均每个页面响应时间低于 20 毫秒。

架构演变与发展 - DA 引入 , DAL 产生 (1)‏ cache 处理器在缓存的存取方面有了很大的进步，但是由于接口众多，使用起来不太方面。而且还是要编写大量的重复代码。为此，我们重构了这部份代码，吸收了其它框架的优点，开发出了 Data Accessor( 简称 DA) 。

架构演变与发展 - DA 引入 , DAL 产生 (2)‏ HTTP MySQL MC 表现层逻辑层 R/W DA JMCD 存储 NS 、 Id List 、聚合运算结果

架构演变与发展 - DA 引入 , DAL 产生 (3)‏ DA 标准化了调用接口，简化了编程，使程序员在业务逻辑层面不再关心缓存与切库分表，极大地提高了生产力 ( 代码量继续减少，易用性提高 ) 。但是它仍然有很多不足。 DA 直接和数据库打交道，在这一点上，可以说是又回到了起点。不过，从逻辑上来说， DA 已经是之后构想的 Data Access Layer 的雏形，经过 4 个月的运行测试，现在，我们把［原 DA ］称为 DAL1.0 ，而把［原 DA ］中包含的客户端程序仍然称为 DA 。

架构演变与发展 - DAL2.0(1)‏ DAL1.0 有很多不足，要弥补这些不足，必须从根本上进行重新设计。如果说 DAL1.0 是为易用性而设计，那么 DAL2.0 就是为性能、可用性等等而设计。。。

架构演变与发展 - DAL2.0(2)‏ HTTP MySQL DAL Server 表现层逻辑层 SCGI DA CACHE JDBC Oracle ??? JDBC JDBC

DAL 设计概览 - 关于分库切表 1) 垂直切分：按功能分。分到不同的数据库或服务器。 2) 水平切分：对数据进行水平分割。 a. 最好分到同一个数据库。 b. 一种已经证明是切实可行的方案：主表＋辅表。 c. 有 3 种类型：主表不打散、主表打散无辅表、主表打散有辅表。 d. 但对程序员来说， TA 看到的只是一张表，不妨称之为虚表 ( 逻辑表 )‏ ，这张虚表实际上可能是由 N 张实表 ( 物理表 ) 组成的。

DAL 设计概览 - 关于缓存 1) 缓存很重要。 2) 但不应该紧耦合于业务逻辑。 3) 慎用 XC/APC 缓存，一般情况下， mc/jmc 这种远程缓存已经够用了。 4) 缓存的最佳实践：缓存单个条目，根据 id list(unique key list) 找列表。 5) 缓存能自动清理就自动清理，不能自动清理的想办法自动清理。

DAL 设计概览 - 目标 1) 程序员不再关心 ( 尽量少关心 ) 分库切表问题，经 DBA 配置，由 DAL 处理。 2) 程序员不再关心缓存的存取与清理问题，由 DAL 处理。

DAL 设计概览 - DA 用法示例 (1)‏ 1) 增： DataAccessor::insert()‏ ->table('imobile.post.db_post')‏ ->data(array('post_id'=>1, ...))‏ ->dup()‏ ->execute(); 2) 删： DataAccessor::delete()‏ ->table('imobile.post.db_post')‏ ->where('post_id', 'IN', array(1, 2, 3))‏ ->limit(2)‏ ->execute();

DAL 设计概览 - DA 用法示例 (2)‏ 3) 改： DataAccessor::update()‏ ->table('imobile.post.db_post')‏ ->data(array('level'=>0))‏ ->where('user_id', '<', 1000)‏ ->limit(100)‏ ->execute(); 4) 查： DataAccessor::select()‏ ->table('imobile.post.db_post')‏ ->columns('post_id')‏ ->where(array('thread_id'=>1, 'forum_id'=>2))‏ ->getPage();

DAL 设计概览 - DAL Server2.0 设计目标 1) 提升性能 : a. 连接池 b. 并行查询、合并结果 c. 更好的缓存处理 ( 过期策略可配置、缓存提供者可配置等等 )‏ 2) 提高可用性 : a. 多个 DAL 实例 (1 available + n candidates)‏ b. 引入单数据库事务 3) 其它：更智能的 where 分析，表的状态监控， DAL 更具可扩展性。。。

DAL 设计概览 - DAL Server2.0 的可扩展设计 DAL Server2.0 总体上设计成 (core + plugins) 的形式。 core 负责一些不可插件化 ( 或难以插件化 ) 的组件， plugins 则是那些可插化的组件。如配置处理、查询分析，选路策略，数据处理等等就是属于 core 的内容。而 CacheProvider, ConnectionProvider... 就是一些可插件化的例子。

DAL 设计概览 - DAL Server2.0 示意图 Monkey query executor routing strategy query parser cache provider result merger cache MySQL conn provider DAL Server2.0 config manager result encoder dal handler

DAL 设计概览 - 扩展 DAL 概念 (1) 访问数据，可以是访问数据库中的数据，也可以是 MC/JMCD 当中的数据，那为什么不可以是 lucene 索引中的数据？

DAL 设计概览 - 扩展 DAL 概念 (2) 5) 搜： DataAccessor::search()‏ ->index('imobile.thread.db_thread')‏ ->fields('title')‏ ->key(' 三星 ') ->where(array('forum_id'=>2)) ->andWhere('date', 'BETWEEN', array(20090305, 20090310))‏ ->getPage();

DAL 设计概览 - 扩展 DAL 概念 (3) HTTP 表现层逻辑层 SCGI DA Search Server SCGI 原 DAL Server Data Access Layer MySQL Lucene 索引

持续改进 1) 很多轮子已成通用轮子。 2) 不断完善已有轮子。 3) 还会有新轮子出现：如，在表现层引入 Widget ，更好的存储系统 ...

Q&A

The End Thanks:)‏