前后端分离的开发模型和架构演进

其实对于很多团队和公司来说，前后端分离的出发点是有些问题的。如果业务没有梳理清楚，就要大一统的方案，显然这个方案是需要反复迭代，这个迭代的代价尚可忽略，但是对于流程的改动影响范围是很大的。所以解决问题也需要聚焦，优先解决见效快，对当前工作有显著改善的部分。

一个系统如果从零到一，基本会是一个如下的大体架构方式：

所以在这里我们的目标很简单，系统像个车轮能够运转起来，至于系统的高可用和性能，这个在目前来看不是紧急优先的，而前后端分离的事情现在是无法支持的。

第二阶段是一个基础的重构，看起来是一种割肉的感觉。 因为我们要对重逻辑做裁剪，否则前后端分离无从谈起。所以在此我提出一个基本的概念，那就是本地前端。这个本地前端是一种面向功能的实现，没有考虑更多的体验和互动性，后端逻辑和前端逻辑要华清界限，最直接的界限就是全部API化，后端逻辑全部提供为API的服务形式，和本地前端的交互还是通过类似MTV的方式来实现，但是view层里面不存在核心的逻辑了，只负责跳转和数据转发。

到了这个阶段，其实系统已经有了一些良好的基础，那么我们就可以考虑接入一个大而全的平台了，这里的前端就是平台前端，这个平台前端可以是统一规划的技术栈或者是全新的系统，这里对接的代价很低，一来已经存在一个基本原型，只能比它更好，二来之前的对接都是API,我们可以在完全不改动已有逻辑的情况下做平台前端的对接。

这个阶段，你可以理解为混合跑的阶段，绝对不会因为某个技术而隔掉其他技术的命。

接下来才开始有意思，那就是后端逻辑的垂直拆分。我们可以根据通用和业务逻辑来拆分为多个逻辑层。比如权限是通用的逻辑，日志是通用的逻辑，安装部署和特有的逻辑。

其实到了这里，我们的目标还不够明显，显然很多工作还是需要明确，首先这么做的意义是什么，我们可以在代码层等来隔离，但是逻辑间的调用和关联还是没有完全降低，怎么改进，一个思路就是模块化，比如我要建设自己的业务系统，权限管理每次都得重新建设，实在是麻烦，如果能够类似docker的模板容器化这个工作，我们的业务逻辑就是一种类似插件的方式，那么服务的可配置和管理型会大大增强。

所以到了这个阶段之后，逻辑的部分还是API来交互，在高可用方面我们就可以考虑一些接口服务，比如RESTful API来完善了。

至于后续的接口服务的高可用等等，这个就是一套完整的框架和系统来支撑了。前端也可以把平台前端统一化了。