目录：

• 一、什么是前后端分离？
• 二、为什么要前后端分离？
  • 2.1 清晰前后端职责
  • 2.2 提高开发效率
  • 2.3 前端能做更多，后端能更专一
• 三、基于Node.js做前后端分离
  • 3.1 为什么选择Node.js而不继续用PHP？
    • 3.1.1 招聘成本
    • 3.1.2 学习成本
    • 3.1.3 开发成本
    • 3.1.4 服务器性能
  • 3.2 基于Egg.js框架开发（编码）
  • 3.3 我们还缺什么？
    • 3.3.1 前端开发者
    • 3.3.2 适合我们的框架和项目脚手架
    • 3.3.3 构建/部署服务
    • 3.3.4 严谨的git工作流
    • 3.3.5 风险监控和日志采集
• 四、关于React Isomrophic
• 参考

一、什么是前后端分离？

大部分人认同开发微信小程序或SPA(WEB单页应用)是实现“前后端分离”的。所有业务数据都是“后端应用”通过HTTP接口提供给“前端应用”。一个“完整的应用”被物理隔离为两个独立的应用，并由擅长的开发者负责，从而实现职责分离：

前端开发者：负责 View 和 Controller 层。
后端开发者：只负责 Model 层，业务处理/数据等。

“前后端分离”是强调“职责分离”，上面应用分离的例子是为了方便理解接受，可以不应用分离。通常应用分离能大量减少不小心的越界行为。

前后端分离后的样子：

framework.jpg

二、为什么要前后端分离？

根据上图，只有“web网站”和“React Isomorphic”两种形态应用没有自然物理隔离前端和后端。我们存在很多没有前后端分离的web网站应用（这也是痛苦的根源），而React Isomorphic应用是前后端分离流行后的开发模式（代替web网站应用）。

2.1 清晰前后端职责

分离前：前端开发者提供静态页面，后端开发者完成 Controller 和 View 层代码。但前端开发者经常会插一脚修改 Controller 和 View 层代码。

分离后：面向用户的 Controller 和 View 层都由前端开发者做；后端开发者只需复杂 Model 层，提供业务数据接口。

前后端分离后基本不需要相互修改对方代码。

2.2 提高开发效率

分离前：前端和后端沟通/约定页面模板的每个字段、字段值的格式、适合模板的数据结构。

分离后：前段和后端沟通需要的 Model 接口。

前后端分离能明显减少沟通成本；约定的内容也少很多，减少大量联调时间。

2.3 前端能做更多，后端能更专一

前端可以服务端开发，而且可以不再局限WEB开发，同一套API，前端可以实现SPA、微信小程序、支付宝小程序等。

后端能更专一API开发，不用为UI要求的时间格式、模板布局要求的数据结构发愁。

三、基于Node.js做前后端分离

目前存在很多web网站应用，我们正在用PHP实践前后端分离。前端同事对PHP不熟悉，成本比较高，所以最终会考虑使用Node.js实践前后端分离。

这里只讨论web网站和React Isomorphic应用，因为其他形态的应用已经物理分离了前后端。

React Isomorphic应用比web网站应用更“先进”，而且Node.js生态已有成熟的方案，所以新项目也会更倾向选择React Isomorphic应用。

www&isomorphic.jpg

3.1 为什么选择Node.js而不继续用PHP？

3.1.1 招聘成本

招会Node.js的前端比招会PHP的前端容易。

3.1.2 学习成本

前端学习PHP语言。语法学习成本不高，但熟悉度还是要时间成本的。

3.1.3 开发成本

开发过程频繁切换语言。经常会在PHP中写JS语法，这点比较烦。

3.1.4 服务器性能

在自己服务器测试两种场景。

服务器配置：

• 腾讯云服务器（Ubuntu 16.04.1 LTS）
• CPU: 2核
• 内存：4GB
• 带宽：2M

Node.js环境：

• Node.js版本：v8.12.0(Alinode v3.12.0)
• 框架：Egg.js
• worker进程数：2

PHP环境：

• PHP版本：7.2.10
• 框架：Lumen
• php-fpm最大子进程数：5

两种场景测试代码：

场景一，直接输出字符串，不做任何IO和计算。

PHP效率比Node.js高

Node.js:

// egg-4 async function test(ctx) { ctx.body = '<h1>goddess.daifee.com</h1><p>Egg程序</p>'; } 

egg-4.png

PHP:

// php-4 $router->get('/test', function () use ($router) { return '<h1>goddess-php.daifee.com</h1><p>这是PHP服务</p>'; }); 

php-4.png

场景二，模拟200ms的网络请求。

Node.js效率比PHP高。相对“场景一”PHP效率下降明显，Node.js不明显。

Node.js:

// egg-4—test2 async function test2(ctx) { const start = Date.now(); await new Promise(resolve => { setTimeout(() => { resolve(true); }, 200); }); const offset = Date.now() - start; ctx.body = `<h1>goddess.daifee.com</h1><p>Egg程序 ${offset}</p>`; } 

egg-4-test2.png

PHP:

// ./WeTest_[php-4—test2]_20181014172129.pdf $router->get('/test2', function () use ($router) { $start = microtime(true); usleep(200000); $offset = microtime(true) - $start; return "<h1>goddess-php.daifee.com</h1><p>这是PHP服务 {$offset}</p>"; }); 

php-4-test2.png

3.2 基于Egg.js框架开发（编码）

下面用Egg.js框架开发一个页面为例（浏览器端开发模式不需要改变）。

开发一个新页面（用户主页页），只需要下面4个步骤：

1. 模板：创建模板文件。

<!-- app/views/user.ejs --> 这里是 ejs 模板 

2. 数据接口：几行代码封装数据接口。

// app/service/user.js const { Service } = require('egg');module.exports = class UserService extends Service { async get(userId) { const url = `https://api.gateway.com/xxx/${userId}`; // http请求/ajax const response = await this.app.curl(url); return response; } } 

3. 控制器：过滤/验证用户输入、验证权限、调用数据接口、渲染模板。

// app/controller/user.js const BaseController = require('./base-controller');module.exports = class UserController extends BaseController { async profile() { const { params, service } = this.ctx; // 只有自己才能访问自己主页。不是自己就抛出 403 异常 this.assertUser(params.userId); user = await service.user.get(params.userId);await this.render('user', {user: user}); } } 

4. 路由：一行代码声明路由。

// app/router.js module.exports = app => { const { router, controller, middleware } = app; const { authorize } = middleware; const { user } = controller;// 已登录用户才能访问 router.get('/users/:userId', authorize.user, user.profile); } 

只负责 Controller 和 View 层的Node.js服务端开发非常简单。一个企业应用除了开发，还有其他环节需要做好。

3.3 我们还缺什么？

前端开发者可以在服务端写 Controller 和 View 层代码，但整个生产环节还缺什么？

3.3.1 前端开发者

既然前端开发者需要做更多，能做更多，所以工作量增加。所以缺前端开发者。

• 同一个项目，编码的工作量增加了。
• 前端同事需要关注、分析、协助维护Node.js服务器。
• 肯定会有更多的xxx小程序需求。

3.3.2 适合我们的框架和项目脚手架

• 确定了web网站应用使用Egg框架，还需为不同业务场景的项目创建拿来即用的脚手架。
• 未确定React Isomorphic应用的框架。我体验过next.js，是一个不错的选择。

3.3.3 构建/部署服务

目前还没有Node.js项目的构建/部署服务。

基本需求：

1. 构建：开发者只需关注源码，“构建服务”自动构建项目。
2. 发布：支持选择git tag构建，部署到“生产环境”。
3. 发布：支持选择git branch构建，部署到“测试环境”。
4. 回滚：支持指定版本回滚。
5. 重启：支持重启Node.js服务器。
6. 发布：允许测试人员发布“测试版本”。

3.3.4 严谨的git工作流

需要依据“构建/部署服务”定制严谨的git工作流。

3.3.5 风险监控和日志采集

• 风险监控可以考虑Alinode。
  • 完全免费
  • 支持性能监控、安全提醒、故障排查、性能优化等
  • 支持手动下载性能数据
• 日志采集接入大数据团队的服务？

关于React Isomrophic

当时用React全家桶做了一个SPA Demo项目，然后用next.js框架再做一个React Isomorphic版。发现可以复用（copy）98%的代码，然后花一点时间将 React Router 替换为 next.js 自带的 Router 即可

基于 next.js 框架 React Isomorphic 应用与 SPA 的开发体验差不多。

毕竟一套代码运行于两个不同环境，React Isomorphic 还是带来了一些坑：

1. 需要意识到哪些代码在2个环境都执行，哪些代码只在其中一个环境执行。
2. 立即执行的代码在2个环境都执行。
3. React组件生命周期的代码只在Browser环境执行。
4. Component.getInitialProps()方法在2个环境都执行。
5. 小心使用运行环境的“接口”
6. next.js自带Router，与“其他Router”肯定存在差异。
7. 某些组件需要用唯一自增ID或随机数，这种做法会使服务端于客户端存在差异。
8. “服务端”与“客户端”基本只能用cookie共享“状态”，要珍惜cookie资源。

参考

1. http://taobaofed.org/blog/2014/04/05/practice-of-separation-of-front-end-from-back-end/
2. https://segmentfault.com/a/1190000009329474
3. https://github.com/lifesinger/blog/issues/184
4. https://tech.youzan.com/gateway/

本页内容由塔灯网络科技有限公司通过网络收集编辑所得，所有资料仅供用户学习参考，本站不拥有所有权，如您认为本网页中由涉嫌抄袭的内容，请及时与我们联系，并提供相关证据，工作人员会在5工作日内联系您，一经查实，本站立刻删除侵权内容。本文链接:https://www.dengtar.com/17425.html