《从零构建先后分离web项目》探究 - 深刻聊聊先后分离架构

探究 ：深刻聊聊先后分离架构

先后分离，一直是一个至关泛泛的问题，先后分离到底好很差？没有绝对的对，没有绝对的错，业界就这个问题已经激烈的探讨几年了.出现讨论的点在于：分离固然是好的,可是以什么样的服务须要进行先后拆分？拆分到什么粒度？先后端如何配合？

截图时间: 2018-08-30 - Github

咱们随意在 Github 输入先后分离关键字，看下搜索的结果: 1K 的库 11k 的 Issues 足以说明先后分离的趋势，能够想象激烈程度，业界比较有名的讨论：Web 先后端分离的意义大吗？，值得一提的是：前排对于这个问题讨论比较深入的大部分都是全栈工程师。由于全栈对全局的了解相对比单纯作前端、后端全局观念更强一些，考虑的问题更多一些。

筛简历引起的思考和分析

后端职位的怪圈

在公司的简历库随手截几个局部的图，近两年面试过不少的 1-3 年 java 开发者，在筛选简历和面试过程当中，也发现了几个问题：至关多一部分 javaer 技术栈上老是多了那么个 HTML ajax jquery bootstrap easyUi ，看起来很唐突，若是面试提到了前端技术栈，基本没有能答的很好的，甚至有的人连 原型链 都不知道。这也是大部分人对全栈的误解，其实我是不太感冒这样的简历的，由于没有什么亮点，技术栈不是写的越多越好，总结起来：他们对前端的掌握很基础，勉强能胜任一些业务上的工做。那为何这么多人都掌握一些前端技术呢？我分析可能有三点：

思考缘由：

• 培训机构的兴起，机械化的教学
• 求职者自身的兴趣
• 一些公司的技术栈不全，对技术没有追求，大部分用的几年前的架构，先后业务耦合很大，市场缺口大

分析

由于我也维护过几个月的敏感项目，深有体会，只写服务端的人是没法胜任这项工做的，
若是多数的 开发者 这样的简历，能够推测：如今的 IT 行业中先后端糅杂一块儿的架构仍是存在、而且有一个量级，这致使他们不得不寻找一些懂得一点前端技术的人来开发项目，减小沟通的成本，加快项目的进度，这也就催生了不少所谓的 web 开发培训机构。

你问我当年维护的开心吗？一会告诉你。

什么是先后分离

先后端分离并非什么新鲜事，处处都是先后端分离的实践。然而一些历史项目在从一体化 Web 设计转向先后端分离的架构时，不可避免的会遇到各类各样的问题。因为层出不穷的问题，甚至会有团队质疑，一体化好好的，为何要搞先后端分离？说到底，仍是技术和思惟方式没转变过来。

一体化模式其实在上一开篇：纵观历史演变 中已经提到过了，不在赘述。

先后分离看起来应该是这样的：

先后分离就是在架构层次上 构建项目或对现有的项目 客户端 服务端 分离开，减小先后端代码的耦合度，你们一致认同的先后端分离的例子就是SPA(Single-page application) ，全部用到的展示数据都是后端经过 JSON 但不只限于 JSON 的方式提供的，前端只管展示,提供更好更绚的交互，后端只管提供更健壮的高可用服务。

千万不要有先写项目，写完再重构的想法，项目初期能一步到位最好，何须再去重构，而后不得已抛弃一些已经写完的组件、库浪费人力呢？

先后分离解决了什么问题

每一个人各尽其职

好的开发者是可与不可求的，若寻找一个 优秀的 full_stack 更是难，从校招进行培养也不太实际，招一个能力通常的程序员，技术驱动性比较差，甚至拖慢产品迭代。分离开来咱们就能够专一于 前端、 服务端 领域去寻找专业的人才。

解耦

前端后端代码大量耦合代码看起来是这样的：

看看简单例子吧：

//(node端处理)
if (is_weixin()) {
init([
'api',
'image',
'xxx',
'...',
], function () {
<%- doSomeGloble %>
});
} else {

}
//接收node端一些数据
let blogs = <%- blogs %>;

let users = <%- users %>;

这还不是 JAVA 模板 而是相对轻量、优雅的 NODE 的 EJS 渲染的，这还好，我见过更使人难受的代码，常常为了一个问题要回头看 N 多代码，这里就不写了。

那么先后分离如何让它们解耦变得更清晰？后面会结合服务端统一补充。

什么项目不适合先后分离

blog、文档

你说你搭建一个博客、 API 文档系统 这种小项目，一我的就能够开发。搞了一个先后分离，须要分离部署。又增长了 SEO 的复杂度，增长了开发的周期、增长了用户部署的难度，何须呢？固然，若是只是技术实践的一种学习方式，仍是欢迎的。

先后分离带来的问题，如何解决？

沟通成本问题

前端妹子：哥，获取所有博客调哪一个接口？

哦，昨天不是发你文件了吗

前端妹子：我找不到了😭

哦，等下吃晚饭发你啊

---

前端妹子：哥，产品提出根据手机壳自动换主题的需求，你有接口吗？

... 我看看...应该...没有！可能须要 Python 的老哥支持！你去找他要吧

---

前端妹子：哥，你根据 TAG 获取博客的接口写完了没？接口是啥？我好渲染数据啊

没等等......

---

这显然是不规范的，咱们指望的是前端后端先约定一个接口协议，后端没完成时，前端本身 mock 测试数据，前端找不到接口的时候，直接查看 API ，根据这个接口协议咱们先后端统一编程，那么咱们如何处理呢？

如何下降沟通成本？
后端数据服务化，走统一的 REST 接口规范输出，下降先后端接口定义的沟通成本。避免“口头说明”的方式。

什么是 RESTful API ？
因此RESTful API就是REST风格的API。 那么在什么场景下使用RESTful API呢？在当今的互联网应用的前端展现媒介很丰富。有手机、有平板电脑还有PC以及其余的展现媒介。那么这些前端接收到的用户请求统一由一个后台来处理并返回给不一样的前端确定是最科学和最经济的方式，RESTful API就是一套协议来规范多种形式的前端和同一个后台的交互方式。

我一般用 swagger + mock 平台生成标准的 RESTful API，同时也支持扩展多个编程语言例如： Go Python

SEO 问题

以 vue + webpack 的 SPA 为例，没有了后端模板返回的 HTML，前端渲染并不被搜索引擎的爬虫接纳。在往后实战 SEO 以前先通俗渲染呗爬虫识别的区别：

seo 本质是一个服务器向另外一个服务器发起请求，解析请求内容。但通常来讲搜索引擎是不回去执行请求到的 js 的。也就是说，若是一个单页应用，html 在服务器端尚未渲染部分数据数据，在浏览器才渲染出数据，而搜索引擎请求到的 html 是没有渲染数据的。 这样就很不利于内容被搜索引擎搜索到。 因此服务端渲染就是尽可能在服务器发送到浏览器前 页面上就是有数据的。

以博客为例简单聊聊:

• 静态服务

<div>我是正文1</div>
<div>我是正文2</div>
<div>我是正文3</div>

爬虫直接抓到 html 解析 - 生成索引

• 传统后端渲染

@RequestMapping("/index") 
    public String index(HttpServletRequest request,HttpServletResponse   response){ 
        return "welcome"; 
    }

这里就比较有意思了，好比咱们打开的网址是:

http://host:port/index
实际充当 Controller 的是 服务端，服务端直接返回渲染好的网页给你，爬虫拿到的也是同样，因此 SEO 没啥太大的问题。

• 先后分离 SPA

let blogs = [];

this.axios.get('/index, {})
                .then(res => {
                 blogs = res.data;    
                })
                .catch(err => {
                    console.error(err);
                });
                
             <!--前端模板渲染dom-->   
 <div  v-for="(item, index) in blogs" :key="item">

一样咱们输入
http://host:port/index

注意：SPA 一般有本身的路由策略，这也就是前端 MVC MVVM 中的 第一个 M

一个典型的 SPA 站点

咱们输入网址先到了这个页面，而后再去异步请求服务器，再由前端页面渲染，又是单页面服务若是咱们不作任何处理，那么你将被各大搜索引擎抛弃。

如何解决？

只要作 SEO 的产品就要作服务端渲染,若是你对 SEO 需求有，但要求并不高，仅部分页面、能够曲线救国

nodejs 出现以前有两种解决方式，一是作一动一静两套页面，服务器判断请求来自蜘蛛就呈现静态页，不然呈现动态页；二是服务器架设虚拟浏览器软件，请求过来了先让虚拟浏览器跑一遍，再将获得的静态页面返回给客户端。这两种方式在大型项目上都有性能问题。

有了 nodejs 后主流作法是先后端同构方案，即一套代码在浏览器端和 node 端均可以运行，从而能够先在 node 端请求数据渲染模板，而后将渲染结果返回给浏览器最终呈现。感兴趣能够看看
Vue 的SSR方案
Angular 的SSR方案

如何更细致的研究 SEO 之后再说

跨域

因为采用先后端分离部署，天然不在一个端口，不在一个端口必然跨域，不过这对如今的技术手段来讲彻底不是问题

开发模式
为了更快更好的开发，dev 下通常采用 node 作代理层，解决跨域，几乎无障碍开发，并且能够轻松切换环境。

部署模式
部署通常不依托 node 进行部署，一般咱们发布到 HTTP 服务器，与服务端进行通讯，一般使用 nginx 进行正向代理。

总结

我认为近几年，先后分离是一种趋势，它的诸多问题正在逐步获得解决，逐渐被你们接受。它确实使咱们的架构变得更加清晰，若是你还在犹豫，为何不大胆跟我走出第一步呢？

讲了两章概念我都已经忍不住想要立刻带你们实践了🤓🤓🤓

关于我

• 目前在写《从零构建先后分离项目》系列，修正和补充以此为准
• 不断更新的 项目实践地址
• 彩蛋：提早预览下一章传送门 🤓

往期文章

《从零构建先后分离 WEB 项目》 序 - 开源的意义

《从零构建先后分离web项目》：开篇 - 纵观WEB历史演变

《从零构建先后分离web项目》探究 - 深刻聊聊先后分离架构