记一个后台管理UI项目的架构演进

去年年初，自己独自承担了公司一个嵌入式设备的后台管理界面的项目。整个项目经过了一年多的维护和改进，笔者感慨万千，遂成此文。

虽说项目规模不大，但却是实打实地经历了几次工程架构的演变。接下来请让我一一道来。

初始

刚开始，由于项目紧急，我并没有想太多，直接先用最熟悉的而且环境较容易搭建（公司设备系统问题）的 PHP 写起来。当然，当时公司还有一个要求是：全部代码加起来不能多于一兆（受限于存储容量）。

由于业务简单，我只用了一个页面来实现，前端导航都是用纯 CSS 来实现的。而且实际交付的时候，代码就只有两个文件：一个 CSS 文件、一个 PHP 文件（视图与业务混杂）。

如此简陋紧凑的架构并不能支撑很久，很快就有客户表示了更多的需求。公司的项目经理那边也已经表示这个项目会一直运作发展。

所以整个项目的架构亟需进化。

MVC

由于需要加入更多的功能，为了方便开发与维护，当时笔者第一时间就想到使用 MVC 框架。

主要有三个原因：

1. URL重载，统一路由管理
2. 视图与模型分离，降低耦合性，提高可重用性。
3. 具体落实开发流程和代码规范

但是，受制于设备计算能力和存储容量，应该尽可能以轻量作为出发点进行选型和设计。

选型

一说到 PHP MVC 框架，第一时间就会想到 Laravel 和 ThinkPHP。但很明显，设备完全支撑不了这类庞大的框架。还有，这类框架提供了大量功能，而实际上，其中的一大部分对于这个项目来说都不需要，比如数据库操作、消息队列、缓存等。

所以，让我们把目光投向到微框架。社区中最有名的微框架大概是 Lumen 与 Slim，它们的最大的特点是短小精悍。然而，它们对于这个项目来说，依然是太大了（Lumen 超过 10 MB，Slim 加上模板引擎接近 700 KB）。

最后，笔者找到了 Flight：一个微型、可拓展的 PHP 框架。

当然，除了体积小（200 KB 以内）之外，选用 Flight 还有其他原因：

1. 现代风格的路由声明（跟上面那些框架一样）
2. 可拓展，请看：Extending
3. 全局 Collection，可作 configuration 以及简单的缓存
4. 自带简单够用的模板渲染功能

重新设计

这方面笔者就不叙述太多，设计思想都大同小异。直接给出大概的目录结构，相信大家都有所了解。

|-app 主要的项目代码
    |-model 模型文件
    |-view  视图文件
    |-Controller.php  控制器
    |-routes.php  路由
    |-Utils.php  工具函数库（比如表单验证）
|-flight php框架
|-static 存放静态资源
|-index.php 项目入口文件（模块加载与启动）

业务组件化

很快就迎来了业务高速发展的时期。

架构模式：分割

网站越大，功能越复杂，服务和数据处理的种类也就越多。利用纵向分割模式，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。—— 选自《大型网站架构设计》

在业务越来越复杂、功能越来越多的情况下，该项目就亟需将其进行业务上的分割。而这样有利于提高开发效率和降低维护难度。

而笔者这个项目进行分割还有另外一个目的：满足不同客户的需求。

一旦业务功能解耦分割，就意味着我们可以按照需求重新组合起来。

可插拔式设计

顾名思义，一个业务组件的圆缺不会对系统的运行产生任何影响。这样不仅能为满足不同的需求提供重要的基础，还能大大提高打包（组合）效率。

笔者对此主要做了三件事：

1. 规范组件声明，并使用 composer 进行管理与打包
2. 各项业务组件模型（尽量最小化）、路由独立
3. 导航基于业务组件动态生成

前后端分离

渲染的问题越来越突出。

痛点与契机

其实，在这之前，一个问题经常出现：后端在某个页面上需要加载很多数据的时候，就会出现页面加载缓慢甚至白屏的问题。

当时，是这样解决的：后端渲染时候，减少或者不做数据调取或者运算，等到浏览器页面加载完成之后，利用 AJAX 的方式再获取数据，最终完成渲染。

因此，后端响应 AJAX 的数据请求 API 逐渐多了起来。不得不说，这为前后端分离提供了契机。

除此之外，当时还有其他痛点困扰着笔者：

• 为了提高复用性，模板设计的粒度越来越少，模板文件不断增多。后端如果要渲染一个页面，最多需要调用 10 个模板，导致了 IO 频率大大增大，渲染效率大大减低
• 前端利用 JS 实现数据加载和响应用户 UI 操作的代码越来越多，而且复用性极低

以上就是进行前后端分离的原因。

遗憾

在打算对该项目进行前后端分离的时候，笔者由于某些原因，离开了这个项目所属的公司。

不过，笔者如果还开发这个项目的话，会做以下几件事情：

1. 前端使用 MVVM 框架 Vue.js 进行重构
2. 把后端大部分渲染逻辑转移到前端，后端专注于响应数据请求
3. 前端也一样进行组件化管理
4. 重写用户认证功能

总结

以上就是这个后台项目架构演进的经历。经过了一年多的开发，笔者真真切切地感受到：好的架构是演进出来的，需要因地制宜。

笔者能力不足、认识不够，许多观点可能不够准确，还请大家帮忙指正。