十二/090
关于drupal架构的思考
自从drupalchina推荐我的blog后，很多drupal的开发者和我讨论drupal的性能，drupal的缺陷，大有感触。
很多人都说drupal站点不适合扩展，或者简单的做到数据库和代码分离后就茫然了。最近参考了很多软件和web架构的书，反过来对drupal这个系统做了一些关于架构扩展的思考。
以自己现有水平来看，drupal的瓶颈似乎在PHP代码执行层面。网上说使用APC加速可以大大加强drupal的性能，自己还没有手动进行测试，所以没有发言权。但目前在自己使用过程中，还是看到drupal一些小尴尬。
drupal的缓存系统比较简单，只是对匿名用户（因为匿名用户访问页面变更比较少）进行页面缓存，并且是以数据库的形式进行缓存。直接序列化页面到cache_page表中，这种性能可想而知，如果对百万级的访问量来说，db将会是个噩梦。
drupal用apache的rewrite模块实现了简洁链接，伪静态页面是提高了SEO效果，但是针对生成静态页面来说，还是比较困难的。另外，drupal的代码可以更加精简，否则为了强大的扩展性损失大幅性能也是不可取的。
有人说代码和架构扩展没有关系（忘记哪位大牛说的），其实我不是很赞同这句话，代码和数据库刚开始的设计决定或者制约了很多后面需要扩展的条件，比如水平划分数据库表的时候，最好是选取primary key，但是这个字段最好不是auto_increment的（道理很容易想到），再比如数据库抽象层的代码如果做memcache缓存，好修改吗？
很多时候，代码级别制约扩展性的很大一个因素就是联合查询，因为在做垂直划分数据库的时候，分离的都是一些关联性不大，并且不会牵扯到联合查询的库表，但drupal很多地方都使用的inner join（几乎每个模块都能看到）。当用户并发数越来越大，服务器最大的压力来源于数据库，这时，有些朋友就说了”负载均衡“啊。
没有那么简单，首先我们考虑基于重定向的负载均衡，多做几个后端服务器，使用RR或者简单随即抽取机制来轮流使用服务器，drupal和其他站点不同的一点小小特性就是唯一入口index.php，也就是说在这个文件我们可以写入一些代码，实现重定向的负载均衡，这点是比较合适的。或者您为了避免不是真正的压力平衡，可以使用DNS负载均衡，这样下来，稍微大点的数据量我们勉强顶得住了。
从水平划分的方面来看，首先最大的表应该是drupal的node表，nid字段是primary key,并且auto_increment的，这就很难进行分表存储。另外就算使用了一些别的算法，分N个表出来存储node，问题是如果使那些众多的node相关操作代码使用不会出问题？
另外一种做法就是使用ngnix的反向代理功能，很多java的开发者叫分布式。就算后端服务器性能差异，我们还是可以通过配置文件来决定权重，能者多得的方式，让每个机器发挥到极限。还可以考虑的方式就是使用apache加载我们定义的lua脚本，匹配select和insert，update，delete等字符串，用来区分属于何种sql查询，进一步实现读写分离。不过在机器之间的数据同步也是个麻烦的事情，我没有在运维方面有多少经验，最多就是使用过rsync。
分析种种情景，使用drupal的用户不要担心，只要我们想的到，可扩展的办法还是很多的。性能决定在你自己手里。