首先自我介绍一下，本人男，中年码农一枚，现就职于某夕阳外企，常自吹自擂为架构师、系统分析师。

我在Drupal方面的经验，在目前认识的Drupal界中，属于比较另类的，我在不会PHP的情况下，由系统优化开始，然后学会一点Drupal，最后又被迫深入一点点学习了PHP的入门知识，基本属于倒置的一个情况。

另外多次在圈子中反驳关于Drupal开发方面的一些误解，这里重申一下：

• Drupal 不适合团队开发：我从接触Drupal到现在，最小团队四五条枪，最大团队几十号人，因为本人前端一无所知，所以没有团队力量压根走不通，因此，这条是百分百的谬论。
• Drupal不好做大项目：我亲身经历的Drupal项目，最小标的也有200多万，所以呢，这条也是缺乏调研的结论。

下面讲讲我职业生涯中的一些非主流Drupal项目，各位看官，有钱的捧个玉厂，没钱的捧个砖厂。

第一次接触Drupal大概是在08年，当时正作为架构师之一参与一个电商项目的启动，CTO大人受上海某高人点化，选择了Drupal作为电商的基础平台。而我当时对PHP一无所知兼毫无兴趣，又不能做闲人，因此很不常规的选择了性能优化作为职责，为了表现的不太闲，又把Drupal Module从A看到了Z，总算在满腹牢骚的情况下，对Drupal，对CMS，对LAMP有了个大概的认识。

系统的结构到目前看来也是比较少见的混搭方式。

• 后端使用了Web Logic + J2EE + 小型机的高大上配置，用于处理订单，库存以及支付等事务性操作。
• 前端使用Drupal + Ubercart + Service的方式。因为当时的需求中，对商品的定制过程有相当高的要求，所以当时的团队果断黑掉了Ubercart，对购物车做了诸多手脚，如果没记错的话，电信运营商电商网站的选套餐、选号界面是从我们开始的。

当时的团队充满奇思妙想，因此又很冒险的采用了Adobe Flex作为运营界面，加上和Java通信的需求，Drupal也就很自然的使用了Service这一神器。

于是不甘寂寞的我，参与了一个半截RPC开源项目，利用这个项目实现了Service的一个协议Module，打通从Drupal到Java后端，到Flex前端的远端调用渠道。

后期在性能瓶颈暴露以后，又采用了奇葩的Tokyo Tyrant作为日志容器，开发了一个新的Log系统，系统性能获得巨大提升，这也是我多次提出的Drupal性能三原罪：日志、会话和Cache的来由。

至此，以Drupal为业务核心和沟通纽带，以Java为关键数据核心的一套电商系统成功上线。

这个是我和Drupal第一次并不亲密的接触，让我对Drupal这东西有了一点点认识，也意识到他可能作为项目主干的潜力；而接下来的一个项目，则是一次Drupal救火的成功经验，让我知道了Drupal小团队可能展现的爆发力。