运维开发三年之痒

       在某个风和日丽的早上，老大找到了正在写脚本的小伟。

拿到了需求后，只会写python的小伟找到了一个合用的web框架tornado，大笔一挥画下了架构图。

用nginx做反向代理处理请求，tornado处理数据生成页面，这样只要在tornado里写好数据处理和模板就行了，只要会学点html就可以了，妙啊。小伟这么想着，开始了紧赶慢赶的开发。一周后就提交了测试Demo。

小伟先问了下自己写web的同学，知道了有ajax这样的使用js去请求&刷新页面的操作。于是花了一天看了看jquery使用指南，将tornado的响应分为了页面和接口。再找到网上最多人用的bootstrap主题，引入后让页面好看了许多。然后又学习了《如何防sql注入》，花了两天手写了一份orm。一番操作之后，小伟心满意足地画下了架构图v2.0：

一个月后，云服务项目准时上线，好评一片。

小伟想，这个框架我比较熟，让小红去写上手比较快的模板，我来做数据处理，应该能够加快工期吧。于是小伟将需求划分为模板和数据处理，开始开发。然而事情并不能像想象一样一帆风顺。

在延迟了三次工期，经历了无数次的争吵之后，集成各种基础功能的管理后台总算上线了。

过了一年，小伟已经将这一套开发模式烂熟于心了。又是一个风和日丽的早上，老大又找到了小伟。

读完需求的小伟发现这次的模块复杂度比上次高了不止一个层级，一想到之后四个人为了页面和接口吵得不可开交的场面，痛定思痛，决心要抛弃之前的模式，重新寻找解决方案。于是找到了最近流行的概念 前后端分离 。前端只负责浏览器端，后端只负责服务器端，页面在浏览器中渲染。

通读了google前三页的前后端分离相关资料之后，小伟觉得这种前后端解耦就是解决web开发的银弹，既能将前后端完全分离，又能提升性能，还可以降低之后维护的成本，只需要将之前的框架做一些小小的调整。满心欢喜的小伟画下了架构图v3.0：

用户请求到nginx，经由不同路由转发，数据请求则转发到tornado处理，html、css、js等静态文件在dist目录存放。在前端工程化的熏陶下，小伟看了下三大框架angular/react/vue，又研究了webpack/gulp/fis，探究了javascript的超集TypeScript，对比了N个前端最佳实践，最终选定了dva作为前端的脚手架。（注：dva是一个开源的脚手架，整合了redux、react-router、redux-saga等工具，在重前端的复杂项目中可以很好地管理数据流）

由于分工明确，两个月后，新管理系统已经完成了前后端联调测试，成功上线。

拓展阅读

小伟附上架构图v4.0：

后记

本文并不是一篇技术类的文章，只是从我们团队技术演变以及业务变更的角度，做了一些记录。 前后端分离的确能够解决很多开发中的痛点，比如职责不清，前端无法处理复杂逻辑，业务组件无法复用，但是也不能够盲目推崇前后端分离的做法。毕竟技术没有最好的，只有最合适的。