- 简单架构
- 缓存与读写分离
- 动静分离
- 集群化高可用架构
- 业务拆分与分布式
- SOA
- 微服务
参考
可称之为 Web 1.0 时代,非常适合创业型小项目,不分前后端,经常 3-5 人搞定所有开发。
页面由 JSP、PHP 等工程师在服务端生成,浏览器负责展现。
基本上是服务端给什么浏览器就展现什么,展现的控制在 Web Server 层。
* 典型问题:
Service 越来越多,调用关系变复杂,前端搭建本地环境不再是一件简单的事
JSP 等代码的可维护性越来越差。
为了降低复杂度,以后端为出发点,有了 Web Server 层的架构升级,
比如 Structs、Spring MVC 等,这是后端的 MVC 时代。
* 问题:
前端开发重度依赖开发环境
前后端职责依旧纠缠不清
历史滚滚往前,2004 年 Gmail 像风一样的女子来到人间,很快 2005 年 Ajax 正式提出,加上 CDN 开始大量用于静态资源存储,
于是出现了 JavaScript 王者归来的 SPA (Single Page Application 单页面应用)时代。
* 挑战:
前后端接口的约定
前端开发的复杂度控制
为了降低前端开发复杂度,除了 Backbone,还有大量框架涌现,比如 EmberJS、KnockoutJS、AngularJS 等等。
这些框架总的原则是先按类型分层,比如 Templates、Controllers、Models,然后再在层内做切分
前后端职责很清晰
前端开发的复杂度可控
部署相对独立,产品体验可以快速改进
代码不能复用
全异步,对 SEO 不利
性能并非最佳,特别是移动互联网环境下
SPA 不能满足所有需求,依旧存在大量多页面应用
随着 Node.js 的兴起,JavaScript 开始有能力运行在服务端。
通过 Node,Web Server 层也是 JavaScript 代码,这意味着部分代码可前后复用,
需要 SEO 的场景可以在服务端同步渲染,由于异步请求太多导致的性能问题也可以通过服务端来缓解。
前一种模式的不足,通过这种模式几乎都能完美解决掉。
与 JSP 模式相比,全栈模式看起来是一种回归,
也的确是一种向原始开发模式的回归,不过是一种螺旋上升式的回归。
1. Front-end UI layer 处理浏览器层的展现逻辑
2. Back-end UI layer 处理路由、模板、数据获取、cookie 等。
1. 需要前端对服务端编程有更进一步的认识。
2. Node 层与 Java 层的高效通信。
Node 模式下,都在服务器端,RESTful HTTP 通信未必高效,通过 SOAP 等方式通信更高效。一切需要在验证中前行。
3. 对部署、运维层面的熟练了解,需要更多知识点和实操经验。
4. 大量历史遗留问题如何过渡。这可能是最大最大的阻力。
随着前端渲染引擎的发展,新兴的Angular,React,Vue等的出现,真正地实现了前后端分离解耦。
前端专注于UI,负责View和Controller层,后端专注于业务/数据处理,负责Model层,
两端通过设计好的REST API进行交互。
1. 让前后端的职责更清晰,分工更合理高效
2. 计算量转移,原本由服务器执行的渲染任务转移给了客户端,这在大量用户访问的时候大大减轻后端的压力
通过 Node,Web Server 层也是 JavaScript 代码
这意味着部分代码可前后复用,需要 SEO 的场景可以在服务端同步渲染,
由于异步请求太多导致的性能问题也可以通过服务端来缓解,结合了前两种模式的优点。