Repractise架构篇一：CMS的重构与演进

重构系统是一项非常具有挑战性的事情。通常来说，在我们的系统是第二个系统的时候才需要重构，即这个系统本身已经很臃肿。我们花费了太量的时间在代码间的逻辑，开发新的功能变得越来越慢。这不仅仅可能只是因为我们之前的架构没有设计好，而且在我们开发的过程中没有保持着原先设计时的一些原则。如果是这样的情况，那么这就是一个复杂的过程。

还有一种情况是我们发现了一种更符合我们当前业务的框架。

动态CMS

CMS简介

CMS是Content Management System的缩写，意为"内容管理系统".它可以做很多的事情，但是总的来说就是Page和Blog——即我们要创建一些页面可以用于写一些About US、Contact Me，以及持续更新的博客或者新闻，以及其他子系统——通常更新不活跃。通过对这些博客或者新闻进行分类，我们就可以有不同的信息内容，如下图：

CMS是政府和企业都需要的系统，他们有很多的信息需要公开，并且需要对其组织进行宣传。在我有限的CMS交付经验里（大学时期），一般第一次交付CMS的时候，已经创建了大部分页面。有时候这些页面可能直接存储在数据库中，后来发现这不是一个好的方案，于是很多页面变成了静态页面。随后，在CMS的生命周期里就是更新内容。

因而，CMS中起其主导的东西还是Content，即内容。而内容是一些持续可变的东西。这也就是为什么wordPress这么流行于CMS界，它是一个博客系统，但是多数时候我们只需要更新内容。除此不得不提及的一个CMS框架是Drupal，两者一对比会发现Drupal比较强大。通常来说，强大的一个负作用就是——复杂。

WordPress和Drupal这一类的系统都属于发布系统，而其后台可以称为编辑系统。

一般来说CMS有下面的特点：

• 支持多用户。
• 角色控制-内容管理。如InfoQ的编辑后台就会有这样的机制，社区编辑负责创建内容，而审核发布则是另外的人做的。
• 插件管理。如WordPress和Drupal在这一方面就很强大，基本可以满足日常的需要。
• 快捷简便地存储内容。简单地来说就是所见即所得编辑器，但是对于开发者来说，Markdown似乎是好的选择。
• 预发布。这是一个很重要的特性，特别是如果你的系统后台没有相对应的预览机制。
• 子系统。由于这属于定制化的系统，并不方便进行总结。
• ...

CMS一直就是这样一个紧耦合的系统。

CMS架构与Django

说起来，我一直是一个CMS党。主要原因还在于我可以随心所欲地去修改网站的内容，修改网站的架构。好的CMS总的来说都有其架构图，下图似乎是Drupal的模块图

一般来说，其底层都会有：

• ORM
• User Management
• I18n / L10n
• Templates

我一直在使用一个名为Django的Python Web框架，它最初是被开发来用于管理劳伦斯出版集团旗下的一些以新闻内容为主的网站的，即是CMS（内容管理系统）软件。它是一个MTV框架——与多数的框架并没有太大的区别。

层次职责 模型（Model），即数据存取层 处理与数据相关的所有事务：如何存取、如何验证有效性、包含哪些行为以及数据之间的关系等。 模板(Template)，即表现层 处理与表现相关的决定： 如何在页面或其他类型文档中进行显示。 视图（View），即业务逻辑层 存取模型及调取恰当模板的相关逻辑。模型与模板之间的桥梁。

从框架本身来上看它和别的系统没有太大的区别。

但是如果我们已经有多外模块（即Django中app的概念），那么系统的架构就有所不同了。

这就是为何我喜欢用这个CMS的原因了，我的每个子系统都以APP的形式提供服务——博客是一个app，sitemap是一个app，api是一个app。系统直接解耦为类似于混合服务的架构，即不像微服务一样多语言化，又不会有宏应用的紧耦合问题。

编辑-发布分离

我们的编辑和发布系统在某种意义上紧耦合在一起了，当用户访问量特别大的时候，这样会让我们的应用变得特定慢。有时候编辑甚至发布不了新的东西，如下图引示:

或者你认识出了上图是源自Martin Folwer的编辑-发布分离

编辑-发布分离是几年前解耦复杂系统游来开来带来的一个成果。今天这个似乎已经很常见了，编辑的时候是在后台进行的，等到发布的时候已经变成了一个静态的HTML。

已经有足够多的CMS支持这样的特性，运行起来似乎特别不错，当然这样的系统也会有缓存的问题。有了APP这后，这个趋势就更加明显了——人们需要提供一个API。到底是在现有的系统里提供一个新的API，还是创建一个新的API。

这时候，我更愿意选择后者——毕竟紧耦合一个系统总会在后期带来足够多的麻烦。而且基于数据库构建一个只读的RESTful API并不是一个复杂的过程，而且也危险。这时候的瓶颈就是数据库，但是似乎数据库都是多数系统的瓶颈。人们想出了各种各样的技术来解决这个瓶颈。

于是之前我试着用Node.js + RESTify将我的博客重构成了一个SPA，当然这个时候CMS还在运行着。出于SEO的原因我并没有在最后采用这个方案，因为我网站的主要流量来源是Google和是百度。但是我在另外的网站里混合了SPA与MPA，其中的性能与应用是相当的，除了第一次加载页面的时候会带来一些延时。

除了Node.js + RESTify，也试了试Python + Falcon（一个高性能的RESTful框架）。这个API理论上也应该可以给APP直接使用，并且可以直接拿来生成静态页面。