论文部分内容阅读
摘 要：drupal系统目录下模块可以放在很多目录下，drupal会按照一定的次序扫描所有的符合规范的目录下的模块。但是并不意味着可以随意放置模块，比如系统的modules目录下放的都是核心自带的模块，为了以后的升级方便，则不应该将模块放在/modules目录里面，本文就drupal的模块放置问题做出了详细的阐述分析。
关键词：多站点；单站点；目录组织；drupal
中图分类号：TP311.52
1 多站点模式
假设建站方式是以Drupal多站点方式运作的，通过多个网站共享一套Drupal代码，这时我们的第三方模块一般都放在/sites/all/modules目录。而其他模块则分网站放到/sites/网站名/modules目录下，如果你的自定义模块想要跨多站共享的话，也需要放到/sites/all/modules里，这时为了区分，你需要在/sites/all/modules目录里建子目录，例如contrib代表第三方模块目录，custom代表自定义共享模块目录。
当然Drupal多站点其实还有一种不共享代码，只共享数据库的情况，但这与本文要讨论的主题无关，就不做过多说明了。
2 单站点模式
单站点模式是最常见的情况，主要就是要用一套Drupal代码建一个站，如果是一个比较大型的网站，需要使用的模块众多，则就需要做一些规划了，在实际开发过程中，可以通过以下分析具体实现。（下文的目录都放在/sites/all/modules目录下，以保证/sites目录下的站点目录干净清爽）
contrib
毫无疑问，这个目录是放置第三方模块的。
custom_contrib
放置的也是第三方模块，但是有一点点与实际的需求不符，又没有提供足够的钩子做扩展，所以实现就需要硬编码了，放在这个目录可以提醒哪些模块是被修改过的，升级时要多加小心，不要遗漏之前打过的补丁。
custom
用于存放自定义模块。
features
存放我们经过规划从后台导出的一批features，每个feature一般是要围绕一个功能特性进行打包，不过如何规划features每个人可能有不同的理解，只要能有清晰的思路，并且以后便于维护即可。
development
存放所有开发相关，而与网站业务逻辑无关的模块，比如devel， schema等，这些模块也不一定是只能在本地使用，但一般是不建议在生产服务器启用的，将这些模块放在一起，对生产服务器的问题排查和优化有一定的帮助。
localhost
这是一个特殊的目录，里面存放的是不放入版本控制的模块，可以是第三方模块，也可以是自定义模块，实际操作时可以在里面继续细分一些子目录，但localhost目录则需要根据版本控制软件设置目录的ignore属性，这样不管里面放了多少代码都不会因为误操作上传到代码库。
3 第三方模块
之所以有第三方模块放到localhost是因为在团队开发过程中，不能任意的提交模块到版本库，而有些开发相关的模块对本地开发又很有帮助，所以可以将版本库里没有，但对实现有用，对其它未必有用的第三方模块，主要是开发相关的模块，放到localhost下，以提高本地开发调试效率。
4 自定义模块
自定义模块放到localhost当然也是不希望代码被上传到版本库，但有这样的自定义模块的意义当然也是为了本地开发效率的提高，这也是一些开发相关的模块，但大多数情况下，都是对业务逻辑和数据做一些CRUD，比如一键插入删除测试数据，比如一键删除近期测试用户等等，这对本地开发效率有极大的提升，或者可以保证本地数据库的精简。
not_in_use
这个目录里的模块来自于custom目录，因为一些自定义的模块可能因为某些原因，比如需求变更，模块功能不再需要，这时如果封装良好的话，需要把模块禁用掉，但由于自定义代码里包含许多业务逻辑，删除肯定不是一个好办法，以后可能需要把这个功能拿回来重新使用，或者需要参考里面的代码，所以实际会需要把这样的模块放到一个单独的目录，从而哪些模块正在被使用，哪些模块目前已经不用了，就是一目了然的了。
5 Drupal模块的存储性能
众所周知，drupal的核心部分是node，也是数据库性能的关键之处，随着内容的不断增长，node数据集就会变得较为庞大，尤其是当drupal包含多种内容类型，也就是多种nodetype，Node的存储问题就变得尤为严重，Drupal6和Drupal7基本差不多，随着网站的数据增长，都会遇到类似的问题。同时，有些模块，也会以把一些其他内容扩展到node的存储中，如content_profile， 把profile存储到node中，taxonomy_node把一个term也存储到node中等等。
这样的结果就是node数据会不断的增长，变得巨大而不易维护和管理，数据存储的性能问题会逐渐成为整个网站的瓶颈。
多站点的模式是把每一种类型的node单独存储，这样，与把所有node都存储在一个中心的情况相比，存储的压力会大大减小，从而提高网站的水平扩展性，解决了单站点的drupal性能问题。
一般来说，不要用content_profile等模块，假如有1万用户，如果一个用户有5个profile，那么就会给node表增加5万条数据，如果是一个以用户为中心的网站，那么用户的profile就会很大，并且content_profile的查询效率比较低，至少需要关联3个表的查询。如果把每种nodetype单独存储，那content_profile也算是一种node类型，也很好的解决了content_profile模块的使用问题。
具体方式是首先把用户独立出来，做一个user站点。这个站点可以使用content_profile，可以把所有的用户信息都存储在node中。
接下来，可以把所有数据较大的node类型分开到不同站点中，比如story站，比如page站，这些站点通过drupal的multiple站点的架构共享user站的用户信息，如user表，role表等。
6 总结
从以上目录划分可以看出，就是在通过多放几个子目录让代码结构，主要是模块结构，变得更有条例，在实际项目中，由于业务逻辑的不同，绝对相信大家有需要新建除了上文提到目录以外的其他目录，而且根据项目大小的不同，以上的目录建议也不是都必须存在的，大家可以根据实际情况进行调整。
总之由于网站一般都需要长期维护，而随着时间的推移很多项目相关的信息你可能都有所遗忘，因此我们开发过程中总要想一些办法让今后项目可以比较容易的理解和维护，从小的方面是代码符合规范，注释良好，代码精炼易懂，从大的方面就是项目的目录结构，技术架构，文档，任务管理等等。
参考文献：
[1]张志刚.用Drupal多站点架构来解决Drupal存储的性能问题[J].计算机研究与发展，2012.
[2]邱晖.漫谈Drupal性能优化[J].计算机工程与应用，2013.
[3]彭波.Varnish构建高负载Drupal网站[J].电脑知识与技术，2012.
[4]李贝.DRUPAL系统A/BTEST解决方案[J].电子世界，2012.
作者简介：陈浩（1979.9-），男，广州人，讲师，实验师，硕士，主要从事计算机网络技术的研究与应用。
关键词：多站点；单站点；目录组织；drupal
中图分类号：TP311.52
1 多站点模式
假设建站方式是以Drupal多站点方式运作的，通过多个网站共享一套Drupal代码，这时我们的第三方模块一般都放在/sites/all/modules目录。而其他模块则分网站放到/sites/网站名/modules目录下，如果你的自定义模块想要跨多站共享的话，也需要放到/sites/all/modules里，这时为了区分，你需要在/sites/all/modules目录里建子目录，例如contrib代表第三方模块目录，custom代表自定义共享模块目录。
当然Drupal多站点其实还有一种不共享代码，只共享数据库的情况，但这与本文要讨论的主题无关，就不做过多说明了。
2 单站点模式
单站点模式是最常见的情况，主要就是要用一套Drupal代码建一个站，如果是一个比较大型的网站，需要使用的模块众多，则就需要做一些规划了，在实际开发过程中，可以通过以下分析具体实现。（下文的目录都放在/sites/all/modules目录下，以保证/sites目录下的站点目录干净清爽）
contrib
毫无疑问，这个目录是放置第三方模块的。
custom_contrib
放置的也是第三方模块，但是有一点点与实际的需求不符，又没有提供足够的钩子做扩展，所以实现就需要硬编码了，放在这个目录可以提醒哪些模块是被修改过的，升级时要多加小心，不要遗漏之前打过的补丁。
custom
用于存放自定义模块。
features
存放我们经过规划从后台导出的一批features，每个feature一般是要围绕一个功能特性进行打包，不过如何规划features每个人可能有不同的理解，只要能有清晰的思路，并且以后便于维护即可。
development
存放所有开发相关，而与网站业务逻辑无关的模块，比如devel， schema等，这些模块也不一定是只能在本地使用，但一般是不建议在生产服务器启用的，将这些模块放在一起，对生产服务器的问题排查和优化有一定的帮助。
localhost
这是一个特殊的目录，里面存放的是不放入版本控制的模块，可以是第三方模块，也可以是自定义模块，实际操作时可以在里面继续细分一些子目录，但localhost目录则需要根据版本控制软件设置目录的ignore属性，这样不管里面放了多少代码都不会因为误操作上传到代码库。
3 第三方模块
之所以有第三方模块放到localhost是因为在团队开发过程中，不能任意的提交模块到版本库，而有些开发相关的模块对本地开发又很有帮助，所以可以将版本库里没有，但对实现有用，对其它未必有用的第三方模块，主要是开发相关的模块，放到localhost下，以提高本地开发调试效率。
4 自定义模块
自定义模块放到localhost当然也是不希望代码被上传到版本库，但有这样的自定义模块的意义当然也是为了本地开发效率的提高，这也是一些开发相关的模块，但大多数情况下，都是对业务逻辑和数据做一些CRUD，比如一键插入删除测试数据，比如一键删除近期测试用户等等，这对本地开发效率有极大的提升，或者可以保证本地数据库的精简。
not_in_use
这个目录里的模块来自于custom目录，因为一些自定义的模块可能因为某些原因，比如需求变更，模块功能不再需要，这时如果封装良好的话，需要把模块禁用掉，但由于自定义代码里包含许多业务逻辑，删除肯定不是一个好办法，以后可能需要把这个功能拿回来重新使用，或者需要参考里面的代码，所以实际会需要把这样的模块放到一个单独的目录，从而哪些模块正在被使用，哪些模块目前已经不用了，就是一目了然的了。
5 Drupal模块的存储性能
众所周知，drupal的核心部分是node，也是数据库性能的关键之处，随着内容的不断增长，node数据集就会变得较为庞大，尤其是当drupal包含多种内容类型，也就是多种nodetype，Node的存储问题就变得尤为严重，Drupal6和Drupal7基本差不多，随着网站的数据增长，都会遇到类似的问题。同时，有些模块，也会以把一些其他内容扩展到node的存储中，如content_profile， 把profile存储到node中，taxonomy_node把一个term也存储到node中等等。
这样的结果就是node数据会不断的增长，变得巨大而不易维护和管理，数据存储的性能问题会逐渐成为整个网站的瓶颈。
多站点的模式是把每一种类型的node单独存储，这样，与把所有node都存储在一个中心的情况相比，存储的压力会大大减小，从而提高网站的水平扩展性，解决了单站点的drupal性能问题。
一般来说，不要用content_profile等模块，假如有1万用户，如果一个用户有5个profile，那么就会给node表增加5万条数据，如果是一个以用户为中心的网站，那么用户的profile就会很大，并且content_profile的查询效率比较低，至少需要关联3个表的查询。如果把每种nodetype单独存储，那content_profile也算是一种node类型，也很好的解决了content_profile模块的使用问题。
具体方式是首先把用户独立出来，做一个user站点。这个站点可以使用content_profile，可以把所有的用户信息都存储在node中。
接下来，可以把所有数据较大的node类型分开到不同站点中，比如story站，比如page站，这些站点通过drupal的multiple站点的架构共享user站的用户信息，如user表，role表等。
6 总结
从以上目录划分可以看出，就是在通过多放几个子目录让代码结构，主要是模块结构，变得更有条例，在实际项目中，由于业务逻辑的不同，绝对相信大家有需要新建除了上文提到目录以外的其他目录，而且根据项目大小的不同，以上的目录建议也不是都必须存在的，大家可以根据实际情况进行调整。
总之由于网站一般都需要长期维护，而随着时间的推移很多项目相关的信息你可能都有所遗忘，因此我们开发过程中总要想一些办法让今后项目可以比较容易的理解和维护，从小的方面是代码符合规范，注释良好，代码精炼易懂，从大的方面就是项目的目录结构，技术架构，文档，任务管理等等。
参考文献：
[1]张志刚.用Drupal多站点架构来解决Drupal存储的性能问题[J].计算机研究与发展，2012.
[2]邱晖.漫谈Drupal性能优化[J].计算机工程与应用，2013.
[3]彭波.Varnish构建高负载Drupal网站[J].电脑知识与技术，2012.
[4]李贝.DRUPAL系统A/BTEST解决方案[J].电子世界，2012.
作者简介：陈浩（1979.9-），男，广州人，讲师，实验师，硕士，主要从事计算机网络技术的研究与应用。