说说前后端分离
- 如何理解前后端分离？
- 怎么去做前后端分离？
考察技术关注点的层级，不要从某个具体技术去分析。
不知其所以然，容易为了前后端分离而前后端分离。
第一阶段—后端时代
后端开发占据话语权，往往也是项目和技术的核心团队。其实这也是为什么我观察到身边的很多人都是去做后端开发，大学课堂也主要教 JAVA，教后端，前端只是教 js 基础语法，canvas 做游戏。不会涉及 React，Webpack 这些工程化的东西吧。
前端开发人员没有话语权，人员分散，甚至没有专业前端，是由后端兼任的，比如 JSP。
JSP 就是一门典型的前后端耦合的开发技术，那当然我们可以肯定，在那个年代，JSP 在 Web 化不是很明显，页面不是很复杂的时候确实发挥了巨大的作用，我们当然不能说去歧视一门技术。
但是，随着大家对于体验这件事情越来越重视，我们希望能提供给用户（这个用户既包括 2C 的消费者，也包括 2B 的企业）更好的体验，也随着比如网速越来越快，交互方式越来越多元化（文字，视频，AR，VR）；另一个呢，就是服务 Web 化，很多服务需要一个可交互的管理方式，所以页面变得复杂起来。
所以类似 JSP 这种模板语言，那也包括 JQuery 等等，已经无法适应这样的需求了。
其实究其本质，还是因为前端用工程化、模块化和可复用的思维来做。
因为前端还没有像后端有很多工程化开发框架，比如 Spring。
所以，不够规范，就会导致各种各样的合作不协调的问题，比如前端内部不协调，前端后端的不协调。这样会产生团队一个很大的交流的内耗，效率低。
那怎么解决呢，既然有耦合，那就解耦合。很自然，前后端分离。
前后端分离更是一个工程化的...考量和项目管理的问题，至于后来的 Vue，React 是其工程化的一个具体实现。
那我个人感觉，软件工程领域，高内聚低耦合经常都很有效。
第二阶段—前后端分离
那么前端开发要专注的东西非常多，HTML，CSS，JS，各种复制粘贴。所以下一个目标就是所谓工程化。
所以也推动了像 Vue，React，Angular 这种前端工程化、组件化开发框架的出现。所以我们看到比如 Ant Design，就非常方便，一个个组件开箱即用，提高了前端人员开发的效率。
而且随着 Node 出现，不仅带来了 npm 这种包管理器，极大地促进了前端生态圈的繁荣，还有 webpack 等等，也让前端人员可以涉及后端的领域，演变为大前端。
回来看，前后端分离仅仅是开发分离吗，当然不是。
软件开发包含设计、开发、测试、部署、维护等等，都要做到较为彻底的分离。
设计
这里是指系统设计，而不是 UI 设计～～
后端架构设计很好理解，什么数据库，中间件，缓存之类的，很自然需要考虑容量、性能、可维护、可拓展，易迭代等等目标。
那前端呢，作为一个软件，也一样要考虑这些的嘛。
但是前后端分离之后，新多出来一个什么东西，那就是前后端接口设计。
前后端是两批人，需要分工合作，所以这就需要我们在设计的时候就制定好接口的规范。我在做笔记分享平台的时候，后端接口就是我同学写的，而我是做架构的，接口设计这一块想到了，但是没有做成完善的文档，只是写了一下接口的地址和它的一个作用。我觉得有啥需求马上说一下，改一下就好了，结果后来遇到很多的矛盾，比如接口的临时修改等等。导致接口不停的修改。其实做接口设计也是一个捋清业务需求到完成代码实现的一个过程。
那在大型系统设计的时候做好完善的接口设计，数据可以通过 Mock 来模拟，前后端独立开发，后端不用说，前端通过 React 等，配合数据也可以很好地独立驱动页面来开发，这样前后端就不容易相互甩锅，避免扯皮和内耗，也可以相对独立地安排工期，不会因为进度相互扯后腿。
开发
开发方面刚才也提过一点，这里我还想补充的就是，前后端分离、通过接口交互，还有两个好处：
- 不用纠结于技术栈。不管你前端是 Vue，React，还是什么，后端呢，不管你是 Go，Node，Spring，只要实现了一套接口，根据接口开发就可以。
- 前端多端开发能力。后端实现一套接口，前端有多端可以共用，比如 PC 端，移动端 H5，小程序都可以用。
测试
前后端独立测试。得益于接口设计和 Mock，前端可以独立测试页面性能、跳转、UI 等等，而不用等后端真的把这些接口都提供了才开始联调测试。
当然前后端联调的过程也是会有的，往往在整个项目开发基本完毕之后。
部署
前后端可独立部署。
如果前后端不分离，静态资源是由后端驱动的，这意味着项目部署=后端部署。前端要改东西发新版本也要求着后端人员。
那分离之后就不一样了，前后端可以独立部署，独立发版本，互相透明。
当然，前端独立出来之后，慢慢地也有自己的 CI/CD 系统，总之是变得越来越规范，越来越自动化。
- 并行开发，提高效率，缩短周期；
- 快速定位问题；
- 部署动静分离，另一个，前端可以部署 CDN
维护
发现 bug，可以快速定位是谁的问题，不会出现互相踢皮球的现象。页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题，全部由前端工程师来负责。接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。双方互不干扰，前端与后端是相亲相爱的一家人。
在高并发情况下，我可以同时水平扩展前后端服务器，比如淘宝的一个首页就需要 2000+台前端服务器做集群来抗住日均多少亿+的日均 pv。（去参加阿里的技术峰会，听他们说他们的 web 容器都是自己写的，就算他单实例抗 10 万 http 并发，2000 台是 2 亿 http 并发，并且他们还可以根据预知洪峰来无限拓展，很恐怖，就一个首页。。。）
前后端分离的弊端
任何技术都是有利弊的。
回到我们开头的问题，不知其所以然，容易为了前后端分离而前后端分离。
我们上面说了这么多，估计你也看出来了，前后端分离是需要成本的。
而且会带来附加的问题，比如 SEO 优化。当然现在大前端也可以自己做服务端渲染。
所以还是要匹配需求，匹配成本（人员成本，时间成本）。
那当然，随着我们工具的发展，其实前后端分离的成本啊，越来越低了。
总结一下，前后端分离和技术没太大关系，主要是工程考量的问题，而后来出现的一系列技术正是解决前后端分离之后的出现的问题。
分离之后—扛住高并发
举例子，高并发。
分离之后-前端基建
业务无限增长，但是人不是。
可视化管理，可视化部署。
参考
https://juejin.im/post/5b71302351882560ea4afbb8
https://juejin.im/post/5e74b6dfe51d452704118d6b
https://www.bilibili.com/video/BV1f7411L7By