Discuz!NT 系统架构分析 (转)

  前一段时间负责负责论坛的迁移工作，对其架构进行了简单的整理。前几天看到有人说
discuz的介绍很少，因此整理了一下，发布出来。
       也是第一次发表文章，大侠们手下留情。
  

 

Discuz整体架构如下图所示：

 

横向表示 同一层次中涉及的各个模块(项目)

纵向表示 不同层次之间模块的关系，某些关系是如何在各层次中传递(穿越)

         Discuz架构上采用了比较流行的三层架构，即表现层，业务逻辑层，数据访问层来进行设计，并结合自己的情况进行了特殊处理。

表现层：

         表现层即为上图中蓝色虚线表示,主要包括:Web，Services，UI，Control。各项目主要功能为：

UI 定义各种页面基类，提供Ajax访问访问接口。

Control存放Discuz用到的自定义服务器端控件。

Services提供外部访问接口。

 

         Discuz引入了一种模板引擎的机制，来实现表现层的多样化。

主要设计思想为：针对设计人员，提供纯静态页面，并提供了一套约定的语法和标签（具体位置在：templates）。模板制作完成后，要进行模板导入，此时discuz会将静态模板进行解析将其转换成 aspx页面，然后放到aspx/1..n下。如果你打开这下面的文件，会发现前端只是一个字符串拼接的过程。要进行的逻辑判断，都放到了后台代码中。后台代码只有一份，所有的 aspx模板引用同一个后台处理类。由此实现web表现的多样化

 

当用户进行页面浏览时，首先确定显示哪个模板，然后采用地址重写技术，将其转移到实际的处理文件。在web.config配置为

 

 

可见Discuz对所有的请求进行了控制，其代码如下 （以Index.aspx为例）：

 

 

 

 

首先程序会先查找Cookie，找到TemplateId，然后重定向到相应的模板文件。

综上所述：模板+重定向实现了表现层的多样化。

 

业务逻辑层：

         业务逻辑，顾名思义就是处理与业务相关的代码。Discuz采用的也是中小型项目的常用的“贫血模式”，即在业务逻辑层只是进行实体的获取，转发和赋值，几乎没有业务操作。

本该封装在此层的业务代码进行了分散，一部分前移至表现层（比如发帖时的加分操作，附件处理），一部分后移到了存储过程（比如发帖后更新我的发帖列表）。

注：关于贫血模式的论述详见 Martin Fowler的相关著作<企业应用架构模式>等      

 

         在业务层，使用了Discuz缓存。主要是更改了存储体，将其存储在xml中（为啥这么喜欢用xml呢，印象中它是很慢的），调用方法和通常情况下几乎无差别。

个人感觉其业务逻辑层是项目中设计最失败的地方。拿发帖举例,如果我进行设计，我的方案可能会是这样：

时间关系，有时间再写一篇文章。

 

顺便说一句：如果要进行Discuz的整合，主要调用的就是此层的代码。

主要项目为：

Discuz.Forum

Discuz.Space

 

        

数据访问层：

 

Discuz基于商业考虑和版本限制等因素，迄今为止已有多种数据源：access，mysql，sqlserver等。为了实现三种数据库的接口统一，此处使用了接口和抽象类进行规范。

其类库结构如下(调用方以Post为例)：

 

 

 

各个数据库中的PostManage都使用DbHelper进行通用数据库的访问。DbHelper本身并没有指定具体的数据库链接类型，参数类型，而是使用.Net自带的抽象类DbProviderFactory来创建。具体数据库的加载要等其静态属性Provider,Factory调用时，读取配置文件，以反射形式进行初始化。

代码如下：

 

 

 

通过此种形式,可以实现各种数据接口的调用的统一，同时方便数据库类型的拓展。比如要加入Oracle的支持，只需要继承IDbProvider实现OracleProvider，新的PostManage继承IDataProvider重写部分方法即可。

而业务层（Posts）的调用通过IDataProvider接口来进行统一，避免了和数据库类型的耦合，可以在不改变业务层，表现层的代码基础上实现数据库之间的迁移。这正是大型项目所需要的，以接口来实现层与层之间的通讯，将更多的可变因素，扩充点实现配置化。

 

 

其他子模块的介绍

 

1.       配置

对配置的管理，小型项目可以直接使用web.config，中大型项目一般使用自己的配置解决方案。原因是：

1. 中大型项目配置文件过多，直接使用web.config来会造成其体积过大

2. web.config直接使用字符串进行读取不方便，

  试着比较一下：

  ConfigurationManager.AppSetting[“SiteName”];

 SiteInfo.Name

3. 每次都需要进行类型转换

 

 

 Discuz实现了自己的配置类，其类结构如下(以Email为例)

 

 

IConfigInfo为空接口，没有定义任何方法，主要是方便DefaultConfigFileManager传递，方便以后扩充。对配置文件的解析也没有使用.Net自带的接口，而是重新定义了接口，同时使用了xml反序列化实现配置文件的加载和类型转换。

代码见: DefaultConfigFileManager.DeserializeInfo

 

比较疑惑的是这个项目中某些类给出了实现，却没有发现调用。可能是兼容或者扩充问题留下的，谁对这方面了解的，也可以跟帖说下。

这些类有：ConfigProvider，IConfigFileManager

 

2.       数据库表的设计

数据库设计中有两个引人注意的地方：

1.       主题表分离

 

如果由我们来设计主题表和回帖表，通常的做法是如下。

 

 

 

这样在获取主题列表时，直接使用分页算法提取Topics；查看某一帖子时，还需要对Topics，Posts进行jion链接。

此种设计的缺陷为：

1.       Topics表存储Content的内容，其体积将会很大，对大体积表进行分页，性能很慢。

2.       显示Posts内容时将进行join操作，损耗性能

而Discuz的做法是进行如下设计。

 

 

将Topics里的Content拆分到Posts中去，同时Topics的主题帖也作为回帖放置到Posts里面，这样就解决了上面我们提出的两个问题。这是典型的违反数据库设计范式以换取更好性能的示例。

 

2． 对Posts表进行水平拆分

         原来以为每一百万帖子，discuz会自动进行拆分，后来发现在discuz后台能够进行设置，手动进行分表，discuz建议每30-50万帖子进行一次拆分。

         进行拆分后，每个表的体积将会减少，保证了查询的效率

 

 

Discuz的整体架构还有很多其他值得细说的地方，例如插件、扩展等，这些需要感兴趣的人自己一一去研究，在此就不多讲了.

 

Tag标签: Discuz!NT, Discuz, 架构, 大型网站, 系统设计, 论坛

Feedback

#1楼   回复  引用  查看    

2008-06-25 12:40 by Kevan       

写得很好啊。。。。

#2楼   回复  引用  查看    

2008-06-25 12:52 by 金色海洋（jyk）       

1. Topics表存储Content的内容，其体积将会很大，对大体积表进行分页，性能很慢。

请问在分页的时候，要不要显示 Content 字段，如果不用的话，Content 在不在 Topics表里面都没有问题。其实在的话，也只会在用 Content 查询的时候才会有影响，因为 Content 字段的类型是 ntext的，而不是nvarchar的。

2. 显示Posts内容时将进行join操作，损耗性能

这个也不理解，

3. 一般情况下，建立好索引就可以了，不用分表。

#3楼   回复  引用  查看    

2008-06-25 13:02 by 上午的绝缘杯       

不错，学习了。

#4楼   回复  引用  查看    

2008-06-25 13:28 by leonardleonard       

恩，很不错。

#5楼   回复  引用    

2008-06-25 13:34 by hellofox2000[未注册用户]

回复 ：金色海洋（jyk）
请问在分页的时候，要不要显示 Content 字段，如果不用的话，Content 在不在 Topics表里面都没有问题。其实在的话，也只会在用 Content 查询的时候才会有影响，因为 Content 字段的类型是 ntext的，而不是nvarchar的。

中午咨询了一下，确实是。content字段大小不会影响表的扫描

2. 显示Posts内容时将进行join操作，损耗性能
这个也不理解，

如果按照通常的设计，topics,posts表分别存储不同的内容，posts表不会存储
主题帖。而显示帖子详情时，第一楼通常是主题帖，此时就需要join操作。

现在实际上实在post表里存储了主题内容。以数据冗余换取了性能

#6楼   回复  引用    

2008-06-25 13:57 by pwqzc[未注册用户]

难道楼主时Discuz.NT里面的人？
和代震军老大什么关系啊？
还是自己分析写出来的？

#7楼   回复  引用  查看    

2008-06-25 13:58 by Leem       

不错,期待下文.能否Show一下你们整合后的论坛.
官方这块确实交流的不够多,完全是封闭开发,不像是个开源项目.

#8楼   回复  引用  查看    

2008-06-25 14:07 by LuChaoShuai       

http://www.cnblogs.com/daizhj/

#9楼   回复  引用  查看    

2008-06-25 14:47 by 书生多命贱       

"同时Topics的主题帖也作为回帖放置到Posts里面，"
我想问下 Topics的主题帖也作为回帖放置到Posts里面 ，也就是帖子的内容是放在Posts表里的，也就是content字段，那回帖的字段放在Posts里的什么地方呢？也是content里面吗？如果是，怎么区分？谢谢！
如果Content 在不在 Topics表里面都没有问题，那他这个表这样设计，好处在什么地方？

#10楼   回复  引用    

2008-06-25 15:47 by xiaosanaiq[未注册用户]

用时间排序一下是不是可以区分开？

#11楼   回复  引用  查看    

2008-06-25 16:19 by jillzhang       

看了看，没什么新意

#12楼   回复  引用    

2008-06-25 17:33 by rqrqnewage[未注册用户]

2. 显示Posts内容时将进行join操作，损耗性能

显示标题不用join，无论怎么设计，查询回帖表之前都需要查询主题表

#13楼   回复  引用  查看    

2008-06-25 17:44 by 戏水       

韩龙：

您写的很不错。 我们在官方论坛开辟了 Discuz!NT 设计与实现 专版。特别欢迎您这样的文章。 阁下愿意的话，可以同时发布到 http://nt.discuz.net/showforum-48.html 。如果觉得麻烦 ，我愿意代劳。

希望看到您的更多佳作。


谢谢 。

#14楼   回复  引用    

2008-06-25 17:53 by hellofox2000[未注册用户]

回复pwqzc ：
呵呵，和他没什么关系,是自己分析写出的。
也不是discuz的人。
不过一直在这浏览文章，对有些人还是比较熟悉的。

回复Leem：
就是一个数据迁移的过程。
原来我们用的lvbbs，后来转到了discuz!nt

回复戏水：
好的，找时间我发过去

#15楼   回复  引用    

2008-06-25 18:39 by roydux[未注册用户]

@hellofox2000

支持你跟他没关系

#16楼   回复  引用  查看    

2008-06-25 18:44 by 5207       

嗯。支持一下。。我看过论坛的源码，大体都了解，楼主总结了下。本文让我对dnt框架更明了一些。

我原本对.NET了解起因是公司有个.NET项目组使用到了castle的原因，我读过后感觉还可以，WEB应用的MVC模式让我感到有点新奇。听过JAVA比较多，但.NET不太了解。后来我开启了一个论坛，采用了Discuz!NT。在其开源后也读过代码，但并没有深入，毕竟工作不在这一块。最近工作中用到了Web Services和HTTPS，于是想起自己的论坛，因为一个简单的功能在论坛的上不能直接设置，需要编绎程序，所以就跑其官网询问，于是就有了戏水一篇感言。呵呵。说来有趣，没想到博客园对哪篇文章会如此动情，褒贬不一。但今天看到楼主的文章还是高兴。网络是个大平台，人与人勾通也许更应该开放及平和一些。谢谢共享！

#17楼   回复  引用  查看    

2008-06-25 18:47 by 金色海洋（jyk）       

而显示帖子详情时，第一楼通常是主题帖，此时就需要join操作。

主题和回复非得放在一个集合（比如DataTable）里面吗？分成两个集合来存放不就ok了吗？

再说，就算是 join 的话，到底会有多少的性能损失呢？

#18楼   回复  引用    

2008-06-25 21:50 by herofox[未注册用户]

楼主分析的很好，以前看过discuz的代码，没仔细去研究过。今天看了楼主的分析，回头来看看代码，就清晰多。谢谢楼主！不过，想请教一下楼主，如果发帖超过千万的话，如何提高性能呢？就靠分表吗？那不是每次都要还要到数据库去查，对数据库压力不是很大？

#19楼   回复  引用    

2008-06-25 22:39 by hellofox2000[未注册用户]

回复 金色海洋(jyk)：
1. 如果不放在一个集合里，就需要进行两次数据库查询。
来论坛的人几乎都要看帖子，这样论坛总体增加的查询数
为论坛pv数的几分之一，这个增加是很可观的。

2. join会损失多少性能，这个没有做过详细的测试。
有人做过测试的可以发帖说明下 :)


回复 herofox:

如果发帖超过千万, 有几种方法可以解决.

可以通过数据库集群,映射到不同的服务器.这个数据同步要做好点
你可以搜索下 master/slave

数据库分表，这是一种很有效的拆分方式.可以和集群同时使用。

建立历史表，这个也算是分表的一种，某种程度上等同于上面的拆分。
因为很多人只浏览前几页的帖子

还有就是建立前端缓存服务器,比如用squid做反向代理,这样能有效的减少数据库读取
(比如：帖子的前几页几乎是不变的，只是每次回帖，需要更新最后一页),只要缓存更新
策略做好，也是很有效的方式

sohu论坛原来的技术钱宏武做过一个讲座<大流量网站的设计>(是这个名字? -_-|||),
里面讲到他们使用链表来设计，不过比较复杂.

其他的暂时就不知道了，其他有知道的可以说下

#20楼   回复  引用    

2008-06-26 02:44 by 袋式过滤器[未注册用户]

最低配置nt。*

#21楼   回复  引用  查看    

2008-06-26 09:16 by 书生多命贱       

楼主你能回答下我的问题吗？
"同时Topics的主题帖也作为回帖放置到Posts里面，"
我想问下 Topics的主题帖也作为回帖放置到Posts里面 ，也就是帖子的内容是放在Posts表里的，也就是content字段，那回帖的字段放在Posts里的什么地方呢？也是content里面吗？如果是，怎么区分？谢谢！
如果Content 在不在 Topics表里面都没有问题，那他这个表这样设计，好处在什么地方？

#22楼   回复  引用  查看    

2008-06-26 10:55 by 不死小强       

写的不错，学习了

#23楼   回复  引用  查看    

2008-06-26 11:32 by 书生多命贱       

可能我的问题有结果了
区分的话，可能是通过Parentid来区分的。
第二个问题的好处是：可以把 主题表里的内容缓存起来，这样在显示详细帖子的时候就只需查回复表就可以了。
换句话说，如果content内容放在主题表里，肯定就做不了缓存，因为content内容太多，所以在看详细帖子的时候就需要join两个表了！
不知道这样理解对不对！

#24楼   回复  引用    

2008-06-26 12:24 by mysky[未注册用户]

@书生多命贱
主题的内容也是在postsX表中的
判断是否是主题的content,是靠PID来决定的

#25楼   回复  引用    

2008-06-26 12:31 by hellofox2000[未注册用户]

回复： 书生多命贱
理解的很对，呵呵。
我理解就是减少join,还有帖子分页时操作比较容易

#26楼   回复  引用  查看    

2008-06-26 20:13 by airwolf2026       

不错.第一次看到discuz!...的系统分析

#27楼   回复  引用  查看    

2008-11-14 08:47 by Jason Cui       

文章表和回复表在两个表里也不需要join，只是需要两次Select而已。我倒是很想知道显示文章和回复的时候需要显示作者的积分威望和在不在线，这个有什么好的办法？因为如果要求这几个是实时数字的话，就没办法用冗余字段的方式来解决。如果回复表和用户表都达到百万，这个Join就变成不可接受的。而百万级的回复是很容易达到的。

#28楼   回复  引用    

2009-03-17 10:24 by koenemy[未注册用户]

看看ado.net吧，这都是dataset层面的东西，和join没有关系，系统这么设计就完了毁了。

#29楼   回复  引用    

2009-04-03 17:42 by 你错了[未注册用户]

@koenemy
--引用--------------------------------------------------
koenemy: 看看ado.net吧，这都是dataset层面的东西，和join没有关系，系统这么设计就完了毁了。
--------------------------------------------------------
数据库 连接两个表的操作 确实损耗性能，大流量的网站 比如论坛
就应该用数据冗余 换取 性能
这样设计是没错的
你错了