介绍laravel+vue前后端分离之服务器端配置

前言

前后端分离一直是laravel学习绕不开的话题。前期我们可以通过基于laravel优秀的框架（比如laravel-admin,dcat-admin），快速构建一个不需要太多前端代码的后台管理系统。但是到了后期，随着项目量级的增加，我们还需要诸如中台（可以简单理解为面向用户的管理后台）、前端网站等业务,如果还使用上述的框架，可能就显得力不从心。并且在实际开发中会遇到这样的问题：

• 公司有前端和后端工程师，前端工程师采用vue开发，而作为phper的我们采用laravel去开发。那么问题就来了，我们不可能让前端工程师也采用laravel-mix，在laravel框架下开发，这样很不友好。
  

• 原来的模式耦合度很高，不管是维护还是扩展都相当困难，所以减少模块间的耦合度，对于后续的维护和扩展都是相当有帮助的。
  

概念明晰

那么这个时候，我们都会想到前后端分离。
那么什么是前后端分离呢？具体的定义今天我们不讨论，有兴趣可以查看这些文章：到底什么是前后端分离？，前后端分离实践有感
明白了基本概念和思路后，我们就应该开始干事情了。但是在开始之前，就要思考当前项目适不适合前后端分离？什么样的项目适合前后端分离？因为如果项目不适合的话，那么前后端分离无疑是会加重工作量，例如只是纯后台管理系统开发，加上接口访问，项目访问量也不大，那么laravel-admin这样的模式完全能够胜任。
到这里会有一个误区，那就是前端代码和后端代码分开开发就是前后端分离（这里貌似和上面说的有点矛盾）。所谓的前后端分离不仅是为了解耦，为了方便后续维护和扩展，本质上是：前端项目与后端项目是两个项目，需要独立部署。两个不同的工程，两个不同的代码库，不同的开发人员。前后端工程师需要约定交互接口，实现并行开发，开发结束后需要进行独立部署，前端通过http请求调用后端的restful api。前端只需要关注页面的样式与动态数据的解析&渲染，而后端专注于具体业务逻辑（来源：为什么要前后端分离？前后端分离的好处和坏处是什么？）。
所以假设，我们的前后端本地开发已经完成，我们需要放到线上环境去测试，那么我们如何去服务器进行部署和配置呢？

相关教程推荐：《laravel教程》

开始

例如我们完成的项目是这样的：
前端使用vue，后端使用laravel+jwt+dingo构建了api接口，以及使用了laravel-admin作为后端管理系统。
按照传统配置后端的方法，只配置后台管理系统，我们一键安装lnmp后，nginx配置一下，root直接指向项目的public目录，或者干脆用宝塔面板，几分钟以后就好了。这个对于我们讲武德的程序员来说叫做“点到为止”。后端直接用域名+/admin就可以使用了。
可是现在有了vue，需要把主域名shop.test 给前端用，我们会说尤老师，牛老师，刘老师你不讲武德，尤老师说对不起，我就要用。
于是就有两种方法可以达到使用的效果：

尝试

1、分别部署，采用不同域名

前端域名是：vue.shop.test
后端域名是shop.test/admin
接口域名是shop.test/api
我只要在前端项目的nginx下，根目录指向目标文件夹就行，例如：

server{
    listen 80;
    server_name vue.shop.test;#域名
    index index.php index.html index.htm default.php default.htm default.html;
    root /www/wwwroot/vue.shop.test/dist;#根目录    ...}

反向代理到接口地址：

#意思就是只要含有"api"的请求，都转发到接口地址去请求
location /api    {
        add_header 'Access-Control-Allow-Origin' '*';
        proxy_pass http://shop.test/api;
    }

后端项目配置跨域：

location / {  
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
    add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';}

保存访问前端：vue.shop.test, 可以正常访问。

2、分别部署，采用相同域名、不同端口

这个就相对简单很多，不需要第二个域名，效率也高的多。
例如，我的后端项目位于/www/wwwroot/test_adimin，前端项目是/www/wwwroot/test_vue，我们只需要在nginx配置里再配置监听另外一个端口就可以：

server{
    listen 80;
    server_name shop.test;
    index index.php index.html index.htm default.php default.htm default.html;
    root /www/wwwroot/test_adimin/public;
    ...}server{
    listen 8080;
    server_name shop.test:8080;
    index index.php index.html index.htm default.php default.htm default.html;
    root /www/wwwroot/test_vue/dist;
    location / {
        try_files $uri $uri/ @router;#需要指向下面的@router否则会出现vue的路由在nginx中刷新出现404
        index  index.html index.htm;
        # try_files $uri $uri/ /index.html;
    }
    #这里要写，不然会报：
    #We’re sorry but XXX doesn’t work properly without JavaScript enabled
    #网上说的把history改为hash就可以，那个不行，不适用于现在的情况。
    location /api    {
        add_header 'Access-Control-Allow-Origin' '*';
        proxy_pass http://shop.test/api;
    }
    ...}

配置成功保存，访问shop.test:8080 速度杠杠的。

总结

优点

1.前后端开发人员各司其职，各自部署，相互不干涉，提高开发效率。
2.能够实现解耦，使得业务更加清晰，减少业务复杂程度。

缺点

1.增加开发、部署难度；
2.提高了对接和沟通成本；
3.不是所有的项目都适合前后端分离，需要框架设计者、开发者自己去判断