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

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

重建系统是一件非常有趣的事情。一般来说，只有当大家的制度都是第二个制度的时候，才必须重建，也就是制度本身已经很松散了。大家花太多时间在编码的逻辑上，开发越来越慢。不仅有可能我们之前的架构不如设计方案，而且在开发设计的全过程中没有保持原设计方案的一些标准。如果是这样的话，那么这就是一个复杂的全过程。

还有一种情况是，人们找到一种更符合他们当前业务流程的结构。

动态CMS

CMS简介

CMS是内容管理系统的缩写，意思是“内容管理方法系统”。它可以做很多事情，但总的来说就是页面和博客——也就是我们需要设置一些网页，可以用来写我们，联系我，以及他们不断升级的博客或新闻报道，还有其他子系统——一般都是不活跃的。根据这个博客或新闻报道的分类，每个人可以有不同的信息内容，如下图所示:

CMS是政府部门和公司必备的系统。他们有很多信息要发布，他们必须宣传和规划他们的机构。以我相对有限的CMS投放经验(大学阶段)，第一次投放CMS的时候，大部分网页都已经建立好了。有时候这种网页很有可能马上存储到数据库查询，然后我发现这是一个很好的计划，于是很多网页就变成静态的了。然后，在CMS的生命中，就是升级内容。

所以CMS中最核心的一项还是内容，也就是内容。而内容是不断变化的东西。这也是WordPress在CMS中如此受欢迎的原因。这是一个博客系统，但在大多数情况下，你只需要升级内容。另外，不得不说的一个CMS架构是Drupal。对比两者，会发现Drupal更强。一般来说，实力的一个副作用就是复杂。

WordPress、Drupal等系统都属于出版系统，其后台管理可以称为写作系统。

一般来说，CMS具有以下特点:

适用于多个客户。

字符 *** 作-内容管理方法。比如InfoQ的编译后台管理会有这样一个系统，社区编译承担内容的建立，而审批和发布则由其他人来完成。

软件管理方法。比如这里的WordPress和Drupal都很强，基础可以考虑平时的需求。

简单的存储内容。简单来说，它是眼见为实的在线编辑器，但对于开发者来说，Markdown似乎是一个不错的选择。

预先声明。这是一个非常重要的功能，尤其是如果你的系统后台管理没有相应的浏览系统。

子系统。因为属于定制系统，不方便总结。

...

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

CMS架构和Django

说起来我一直是CMS党。关键原因是我可以自由改变网站的内容和结构。一般来说好的CMS都有它的框架图，下图好像是Drupal的控制模块图。

一般来说，会有:

对象关系映射(ObjectRelationMapping)

用户管理

I18n/L10n

模板

我一直在应用一个叫Django的PythonWeb架构，最早是开发设计用来管理奥利弗出版集团旗下的一些网站，主要是新闻报道，也就是CMS(内容管理方法系统)手机软件。这是一个MTV架构——与大多数架构没有太大区别。

级别责任实体模型，即数据信息存储层，解决所有与数据信息相关的事务管理:如何存储，如何认证有效性，包含哪些个人行为以及数据信息之间的关系等。模板，即主表示层解决的是与主表示层相关的决策:如何在网页或其他类型的文本文档中显示信息。主视图，即域模型层存储实体模型和读取适当模板的逻辑。模型和模板之间的桥梁。

架构本身与其他系统没有太大的不同。

但是，如果我们已经有了多个外部控制模块(也就是Django中app的定义)，那么系统的架构就会不一样。

这也是我非常喜欢用这个CMS的原因。我的每个子系统都是以app的形式呈现服务项目——博客是app，sitemap是app，api是APP。系统立刻解耦成一个类似于混合服务项目的框架，即不像微服务框架那样多语言，也不容易出现宏应用的紧耦合问题。

写-发布并分离

每个人的写作和发布系统在某种程度上都是紧密耦合的，当客户浏览量特别大的时候，会让我们的应用越来越慢。有时你不能写甚至不能发布新的项目，如下图所示:

还是知道图片来自马丁·福尔沃的《编刊分离》？

编刊分离是两年前脱钩制度发展的结果。今天，这似乎是很常见的。写的时候是后台管理的。在发布之前，它已经变成了一个静态数据HTML。

已经有足够多的CMS应用了这个特性，而且看起来效果很好。自然，这样的系统会有缓存文件的问题。有了APP，这个发展趋势就更加显著了——每个人都必须展示一个API。是在当前系统中呈现一个新的API还是建立一个新的API。

目前来看，我更倾向于选择后者——毕竟紧密耦合一个系统在中后期会造成足够的不便。而构建一个基于数据库查询的写保护RESTfulAPI并不是一个复杂的全过程，也是有风险的。目前的短板是数据库查询，但似乎数据库查询是大多数系统的短板。大家想到了各种技术来应对这个缺点。

所以我之前尝试过用Node.jsRESTify把博客重新整理成SPA。自然，CMS此时仍在运行。我最终没有因为SEO而选择这个方案，因为我网站的关键总流量来自Google和百度搜索。不过我也在其他网站混过SPA和MPA，里面的功能和应用都很特别，除了第一次加载一个网页会有一些延迟。

除了Node.jsRESTify之外，还使用了PythonFalcon(一种性能优异的RESTful架构)。理论上这个API应该也是可以马上应用到APP上的，可以马上用来生成静态网页。

编译-发布-开发和设计分离:静态数据网站生成

像React这种处理DOM特性的问题就是绕开DOM的漏洞，绕开动态网页特性的问题就是让网址变成静态数据。

越来越多的开发者刚刚开始使用Github页面作为他们的博客，这是一个非常有趣的变化。关键原因是它是完全免费的，大部分可以24x7小时使用——Github发现常见故障的情况下才可以不浏览。

在这类静态数据网站生成器(Github)中，流行以下内容(数据来源:http://segmentfault.com/a/1190000002476681):

哲基尔/奥克托普雷斯.Jekyll和OctoPress是最流行的静态数据博客系统。

Hexo.Hexo是NodeJS写的静态数据博客系统。它的生成速度更快，题目总数的相关性也非常丰富。它是OctoPress的绝佳替代品。

杜父鱼.Sculpin是一个PHP的静态数据网站系统。Hexo和Octopress是专门做博客的，有时候大家的要求不仅仅是博客，还有类似CMS的网页生成要求。Sculpin是一个通用的静态数据网站生成系统，适用于分页查询、分类标签等常见博客。此外，它还可以很好地用于非博客的一般网页生成。

雨果.Hugo是一个用go语言编写的静态数据网站系统。它的生成速度更快，除了博客和非博客内容之外，还展现了相对完整的主题体系。无论是写自己的主题，还是嵌入别人的主题，都比较方便。

一般来说，在这类专用工具中会出现以下内容:

模版

减价是适用的

资料库

像Hexo这样的架构甚至表现出了一键部署的作用。

大家都写好相关代码后，接下来要做的就是生成HTML。就我的博客来说，这是一个非常非常好的制度，但是对于一些公司级的制度，大家的规定更高。以下是胡萝卜选择的框架:

这类似于我们新项目的当前系统架构。作为一个时尚博主，一般来说，你改变博客主题的频率比较低，可能半年一次。如果你经常改变博客的主题，那么你的博客里的文章一定很少。

图中的作者根据名为ContentFull的CMS构建他们的内容，然后生成RESTfulAPI。还有类似的东西，也可以用WordpressRESTful软件。如果做得好，那么我觉得这个API马上就可以应用到app上了。

图中的开发人员必须不断地将更改后的主题或类似的项目推送到版本控制系统，然后当webhook检测到他们的更改后就会出现一个静态网页，然后编译程序进行更新。

最后，根据Netlify的说法，他们一起编译程序，然后部署到工作环境中。除了Netlify，您还可以编写和生成脚本，然后用CI专用工具(如Bamboo和Go)编译程序。

一般来说，工作环境可以应用CDN，比如CloudFront服务项目。与动态网页相比，静态网页非常容易立即部署到CDN，可以立即从本地缓存文件中呈现接近客户的服务项目。另外，马上申请AWSS3静态虚拟主机也是一个非常非常好的选择。

按照Github的写作-出版-开发设计分开

虽然我们已经在新项目上实现了一些基于Github的内容管理方法，但由于找不到一些相关资料，很难揭示其中的关键点。直到我看到“使用git1进行内容管理的增量方法”，我才意识到这似乎已经是一种完美的技术了。好像这项技术最早是在互联网上应用到ThoughtWorks上的。

关于应用这种架构，原文中提到了很多点:

快速启动新项目，而不是学习、培训或装备架构。

大家都信奉的标准，比如TDD，一定要应用。而且和大部分CMS不兼容。

根据服务项目的框架。

方便的语言和特殊的工具

我们都是开发者。

那么，那么，这个开发者做了什么:

内容存储为静态数据文档。

不是所有的内容都是公平的。

导入内容服务项目

应用Github。所有的内容都会提交给一个repo，这个内容可以在大家推送内容的时候自动更新。

允许内容根据内容服务项目进行升级。

应用GithubAPI

因此，我们有一个叫做Hacienda的框架来管理方法的内容，并将其存储为JSON。这代表了什么？

得益于Git的应用，我们可以掌握文档内容的一个版本历史，比WordPress更直观，更容易上手。

开发者修改代码后，可以立即提交，不容易危及编辑器应用网站。编辑器根据在线编辑器添加内容。存储后，内容以JSON的形式出现，并立即提交给Github上相应的代码库。或者CI构建器检测到它们的方法，将会生成一个新的静态网页。此时此刻，我们可以选择一个浏览服务平台，它可以一键部署。然后，好像事情就差不多了。

如果我们有一个应用程序，那么每个人都可以使用内容服务来做这种事情。你甚至可以立即用它建造一个温泉浴场。

如果非要搜索全文，那就越来越简单了。您不必立即与数据库查询交互，我们可以立即加载JSON并构建数据库索引。目前，需要一个简单的Web服务，并且这个服务项目是写保护的。

如果有必要，比如手机上的APP，我们可以根据内容服务建立博客。

重复练习

想到这里，我想起了一个适合学习和训练的情况。

大家建设的关键可以按照特拉维斯CI来进行。唯一有风险的阶段是，每个人似乎都要暴露每个人的关键。