技术栈的前后端分离

[AlexZ33]

前后端分离

• 职责分离
• 架构分离
  • 前端、后端分开开发，各自持续集成，分离上线
  • 前后端架构的协作可以通过配置文件完成
  • 架构，永远不会一成不变，没有最好的，只有最适合的
  • 前后端分离是一种设计理念， 可以把人员职责划分更清晰
  • 更好的共建模式
  • 快速的反应变化

后端MVC时代

端代码越来越复杂

• 无法统一协作模式，代码充满了约定
• JS跟CSS，依赖于后端产出的HTML
• 有的数据來自AJAX，有的数据印在DOM上，有的来自RPC
• 有的业务逻辑在前端，有的在controller层，有的在Model层，更多的是在View层

无法良好的支持跨终端

• 业务逻辑散落在应用中
• 渲染逻辑强依赖后端页面
• 只能用responsive design 硬来

前后端依旧高度耦合

• 前端依赖后端开发环境
• 在服务端view层高度耦合
• 沟通成本高，维护成本高，无法快速响应变化，代码最后是肉山
• 职责不清晰
  • view层谁来维护 ？
    • 前端写demo，后端套页面 （后端需要写html， 前端仍然需要确认后端写的html）
    • 前端写view层， 后端只管数据 (前端需要熟悉后端语言，前端需要了解后端架构)

前后端分离实践

CLIENT - SIDE MV** 时代

• 接口分离，后端提供数据。前端逻辑全在client端
  • model层 ，JavaScript object
  • view 层， JavaScript template

问题

• 各项职责重叠，并且各玩各的

  • Client-side Model 是 Server-side Model 的加工
  • Client-side View 跟 Server-side是 不同层次的东西
  • Client-side的Controller 跟 Sever-side的Controller 各搞各的
  • Client-side的Route 但是 Server-side 可能没有

• 性能问题

  • 渲染，取值都在客户端进行，有性能的问题
  • 需要等待资源到齐才能进行，会有短暂白屏与闪动
  • 在移动设备低速网路的体验奇差无比

• 重用问题

  • 模版无法重用，造成维护上的麻烦与不一致
  • 逻辑无法重用，前端的校验后端仍须在做一次
  • 路由无法重用，前端的路由在后端未必存在

• 跨终端问题

  • 业务太靠前，导致不同端重复实现
  • 逻辑太靠前，造成维护上的不易

• SEO问题

  • 渲染都在客户端，模版无法重用，SEO实现 麻烦

重新定义前后端

传统认知的前后端

• 是依照 工作职责来划分的前后端
• 还是依照 硬体环境划分的前后端？

因為有了NODEJS, 我们有机会从工作职责上, 重新定义前后端的分层

重新定义的前后端

在服务器(JAVA) 与 浏览器(JS)的中间
架了一个中间层(NODEJS)

• 前端熟悉的语言，學習成本低
• 都是JS，可以前后端复用
• 体质适合：事件驱动、非阻塞I/O
• 适合IO密集型业务
• 执行速度也不差

职责划分

示例

淘宝首页优化

需求： 静态资料展示，方便运营管理；更好的承载密集且庞大的流量

方案：

• 页面缓存与定时刷新，返回缓存资料
• NodeJS产出静态页面到CDN，定时刷新

淘宝详情页优化

需求： 单日四亿PV，页面数据来自各个不同接口。为了不影响体验，先产生页面框架后
在发起多个异步请求取数据更新页面
这些多出来的请求带来的影响不小，尤其在无线端

方案：

• 在NodeJS端使用 Bigpiper 技术

• 合并请求，降低负担

• 分批输出，不影响体验

接口性能优化

• 拆分大接口为独立小接口，并发请求

• 串行 => 并行，大幅缩短请求时间

部署优化

• 一台NodeJS对多台JAVA服务器

• 合理的分配服务器带来最大的产出

页面渲染优化

• 前后端共享模版
• 首屏服务器渲染
• 次屏浏览器渲染
• 局部刷新浏览器渲染

单页面应用优化

• 前后端共享路由与模版
• 前端换页，浏览器端渲染
• 直接输入网址，服务器渲染
• SEO问题迎刃而解

可靠性优化

单元测试，页面测试，回归测试，持续集成

其他优化

• 接口服务化
• 代码模块化
• 功能组件化

全栈开发

[AlexZ33]

参考

谈一谈前后端分离的优劣势