这是我发在 https://github.com/hduhelp/backend_guide 为社团部员的学习文档，基本都是来自我自己以前开发的经验和理解，如有不正欢迎指出。

（ 这个系列文档够我水好几篇文章

前后端分离网络知识

概念与历史

这是 Web 项目开发中必需的一种思想。

下面是一些网络上的文章

https://cloud.tencent.com/developer/article/1520380

https://www.infoq.cn/article/mnftt4ubk5pql3jpnt6m

我对前后端分离的理解就是页面和接口的分离。在以前 asp jsp 等不分离的状态下，后端一人扛起页面渲染和数据库交互等责任，前端和后端的耦合度极高，导致开发效率低下。

后来随着 ajax 等技术的出现，前端请求接口越来越方便，为了解耦前端和后端，发展到了后端提供接口，前端渲染页面，也就是前后端分离。

比如 golang 的 HTML 模板渲染就是一种前后端不分离的形式，渲染页面时直接输出 HTML 代码而不是通过接口去解耦。

前后端分离不是一门技术，而是工程领域中的一个经验和实践，随着前后端各自的技术发展，这个趋势是自然形成的。

虽然前后端分离有一定的缺点，但是依旧利大于弊，这种思想应当在实践中贯彻和理解。

优点

  1. 节省流量。

分离时服务端和客户端只传输数据，不分离时传输整个 HTML 。

  1. 解耦公司内的前后端职位，提高开发效率。

不再是前后端岗位揉成一团，而是以接口为桥梁各司其职。

  1. 局部性能提升。

通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。

  1. 部署体验提高。

前端的代码有问题只需要改动前端再上线，后端有问题只需改动后端，不会一个小改动导致整个项目重新上线。

缺点

  1. 前端的代码量增大，招聘门槛变高。

但对于前端和后端却是好事，一方面前端从以往后端的“附属品”逐渐拥有话语权，另一方面前端的门槛提高有助于降低后端的心智负担，不至于对接的前端都是阿猫阿狗。

  1. 网站SEO效果变差。

前端 DOM 动态渲染导致对搜索引擎的友好度降低，不过这可以通过 SSR 解决。

  1. 文档重要性提升。

因为要按照接口去编写代码，前后端对接的接口文档显得十分重要，所以项目最好的方式是前后端先共同商议文档，而后再各自编写代码。但是由于大部分人并不喜欢写文档，所以对接有时显得混乱。

前后端交互

协议

Web 项目大部分使用 HTTP 协议，毕竟是跑在浏览器上的，HTTP 支持最好

像 APP 或 桌面应用也可以采用 RPC 协议远程调用，RPC 相对 HTTP 的开销更小

协议不是交互的重点，主要根据项目的设计和框架走

序列化格式

序列化通俗的讲就是把代码中复杂或者简单的结构体转化为可传输的二进制或文本

反序列化即把可传输的二进制和文本变为代码中的结构体

常见序列化如下，这些格式在：(助手项目中大多采用 JSON 和 Protobuf)

常用于前后端数据传输，体积小、可读性好。由于大部分情况下不支持注释，很少用做配置文件。

常用于程序的配置文件，支持注释，可读性好。但是语法的缩进敏感对新手不太友好，经常写出错误语法。

Github 创始人与前 CEO 提出的格式，比较新的一种格式。通常用作程序的配置文件，对新手比较友好，但是写多层嵌套的时候可读性会变得很差。

需要使用 .proto 文件定义结构。速度快体积小，但是因为用二进制表示，可读性较差，常用于微服务中 RPC调用，有时也用于 Web 传输。当然目前 Protobuf 的应用范畴已经不局限于序列化了，也用于微服务的 service 定义等等。

类似 Protobuf ，但是因为没有一个好爹所以干不过 Protobuf

  • ......

等待补充

其他

不要有一把锤子，看什么都是钉子

在Web项目开发前应当预估项目规模、技术栈等等需求再去决定开发模式，而不是无脑前后端分离。在一些开发时间紧的项目里，PHP (不分离)显然是比 Golang (分离) 更好的选择。当然，在时间允许的情况下，尽量采取前后端分离的开发模式，这在后续团队规模扩大、项目复杂度变高后会体现出非常大的优势。

最后修改：2021 年 10 月 14 日 08 : 31 PM
© 允许规范转载