從壹開始先後端分離 [.netCore 填坑 ] 三十三║ ⅖ 種方法實現完美跨域

緣起

哈嘍你們週四好，趁着你們在團建的時候花一個下午學點兒東西，也是督促你們學習喲，但願你們看到老張的文章，能夠有一丟丟的學習動力。不過話說過來，該吃的團建仍是要去的，不能學我呀 [ /(ㄒoㄒ)/~~ ]，昨天開始搭建公司的先後端分離項目，糾結是 Iview 仍是 ElementUI ，百思不得其解，都說處女座糾結，我一個巨蟹爲什麼如此，歡迎大佬們給出意見和建議~~~

開發 Vue 的時候，哪種前端樣式框架更好？

鑑於羣裏小夥伴問得最多的問題，這裏找到Top3的其中之一，就是跨域問題（下次說說EFCore），固然這個問題是老生常談的問題了，並且在以前的時候也已經說過了，不知道你們在使用的時候怎麼樣——坑來自於文章《框架之十二 || 三種跨域方式比較》。固然，你們會問了，既然都說過了，爲什麼還要說呢，特別是使用 CORS 來實現跨域，很輕鬆，短短的幾行代碼就搞定了，可是或多或少會遇到這樣的問題，一、把Http和 Https 搞混了，失敗；二、若是是前端端口號不固定，會常常要後端配置端口號，麻煩；三、最重要的一點就是把咱們的接口地址暴漏出去了，不爽；若是你不信，能夠看看我以前本身的一個線上版本  http://vue.blog.azlinli.com/#/，

 

雖然接口數據很正常被獲取，可是接口地址仍是不想暴露出去，欸？！那咋辦，這就是說到了今天說的內容了，你們看我寫的標題應該也能明白，⅖ 種方法—— 前邊的三種方法已經說了，這裏再重溫下：

0、不跨域 —— 先後端寫在一塊兒，別笑，還真的有人已經把Vue 和 .net 整合到一塊兒了，不說明

一、JsonP —— 在JQ中挺好，弊端也有，淺嘗輒止

二、添加請求頭 —— 須要後端來設計，不推薦

三、CORS —— 這個是我在跨域中遇到的神器，優缺點上邊也說了，仍是很不錯的，推薦使用

四、webpack 本地代理 —— dev 環境的一大神器，只需在 webpack 中三行配置，便可代理到本地，只能在本地，大弊端，不過仍推薦使用

五、Nginx 反向代理 —— 完美解決 Build 後生產環境中的跨域問題，配合之後的負載均衡，強烈推薦

由於前三種跨域方法，已經在以前的文章中提到了《框架之十二 || 三種跨域方式比較》 ，這裏就很少說了，今天主要說說 Webpack 的本地代理，和Nginx反向代理實現跨域，徹底不用對後端進行操做；

 最終咱們的 博客項目一 的呈現的效果 http://vueblog.neters.club/：發現以及成功代理到本地了，而且是發佈到服務器版本

 

 

1、基於webpack 的 proxy 代理——開發環境很方便

一、Vue-Cli 3.0 新增全局配置文件 vue.config.js

 vue項目搭建的時候，會有一個全局config配置文件，在 vue-cli 2.0 腳手架中，很明顯的把它放到了 config 的一個文件夾中，是這樣的，咱們在 index.js 中能夠端口號的配置，打包以後路徑的配置，圖片的配置 等等

可是 vue-cli 3.0 腳手架中，去掉了 config 這個文件夾，那咱們如何配置呢，咱們能夠在項目根目錄新建一個 vue.config.js 文件，像以前的不少繁瑣配置，均可以在這個文件裏配置啦。官方說明，vue.config.js 是一個可選的配置文件，若是項目的 (和 package.json 同級的) 根目錄中存在這個文件，那麼它會被 @vue/cli-service 自動加載。你也可使用 package.json 中的 vue 字段，可是注意這種寫法須要你嚴格遵守 JSON 的格式來寫。

 咱們就在根目錄下新建該文件，而後添加內容：

module.exports = { // 基本路徑
  baseUrl: "/", // 輸出文件目錄
  outputDir: "dist", // eslint-loader 是否在保存的時候檢查
  lintOnSave: true, // webpack配置 // see https://github.com/vuejs/vue-cli/blob/dev/docs/webpack.md
  chainWebpack: () => {}, configureWebpack: () => {}, // 生產環境是否生成 sourceMap 文件
  productionSourceMap: true, // css相關配置
 css: { // 是否使用css分離插件 ExtractTextPlugin
    extract: true, // 開啓 CSS source maps?
    sourceMap: false, // css預設器配置項
 loaderOptions: {}, // 啓用 CSS modules for all css / pre-processor files.
    modules: false }, // use thread-loader for babel & TS in production build // enabled by default if the machine has more than 1 cores
  parallel: require("os").cpus().length > 1, // PWA 插件相關配置 // see https://github.com/vuejs/vue-cli/tree/dev/packages/%40vue/cli-plugin-pwa
 pwa: {}, // webpack-dev-server 相關配置
 devServer: { open: true, //配置自動啓動瀏覽器
    host: "127.0.0.1",//主機
    port: 6688, // 端口號自定義
    https: false,//是否開啓https安全協議
    hotOnly: false, // https:{type:Boolean}
    proxy: null, // 設置代理
 before: app => {} }, // 第三方插件配置
 pluginOptions: { // ...
 } };

相應的註釋都有，主要是配置 devServer ，從名字上也能看出來，這個是 dev 開發環境的服務配置，經常使用來配置咱們的端口號 port ，還有一個就是 proxy 的設置代理。

二、配置 proxy 本地代理

 將上邊的 proxy: null 註釋掉，而後修改代理設置：

 proxy: { // 配置多個代理
       "/api": {//定義代理名稱
         target: "http://123.206.33.109:8081",//咱們的接口域名地址
         ws: true, changeOrigin: true,//容許跨域
 pathRewrite: { // 路徑重寫，
           "^/apb": "" // 替換target中的請求地址，（這裏無效，可是能夠自定義處理）
 } } },

這樣，咱們就把接口地址代理到了本地，那代理到本地，如何調用呢，請往下看。

三、修改接口api地址，http.js文件

還記得咱們在 src 文件夾下有一個 api/http.js 文件麼，這個就是配置咱們的 http 請求相關的，其餘的都不變，咱們只須要把域名去掉便可，或者寫上本項目的域名：

// 配置API接口地址
var root1 = "http://localhost:58427/api";//沒有代理的本地api地址
var root2 = "http://123.206.33.109:8081/api/";//沒有代理的服務器api地址
var root = "/api/";//配置 proxy 代理的api地址，也能夠寫成http://localhost:6688/api

其實說白了，就是在項目啓動的時候，在node服務器中，是把全部的   /abi == http://localhost:6688/api 的都指向了 http://123.206.33.109:8081 域名，這樣就實現了跨域

其餘任何都不須要變，接口的使用仍是原來的使用方法，這樣，咱們在本地開發的時候，就能夠獲取到後端api數據了，不用再去 .net core 中設置跨域CORS了，是否是很方便。

四、本地瀏覽效果

 記得咱們修改 vue.config.js 後要重啓下服務，而後就能夠看到項目成功獲取數據，並代理到本地：

 

能夠看到，咱們已經把遠程接口數據 123.206.33.109 成功的代理到了本地 localhost:6688 ，是否是很簡單！

 

五、build 打包發佈 IIS

 那咱們本地開發好了，是否是一切都穩妥了呢，咱們能夠試一試，經過 build 打包，生成 dist 文件夾，而後將文件夾拷貝到服務器，並配置 IIS ，這個很簡單，就和配置普通靜態頁面是同樣的，

咱們發現雖然頁面能夠瀏覽（能夠渲染，證實咱們的 vue 已經生效），可是卻獲取不到數據，這證實咱們上邊的 proxy 代理，只是適用本地dev開發環境中：

截圖

雖然這個本地代理的方法很簡單，特別適合咱們獨立開發，在跨域這一塊，徹底不用和後端作處理，可是如何解決發佈狀態的呢，請繼續往下看。

 

2、基於Nginx 的反向代理——打包發佈一鍵搞定

這篇文章僅僅是如何使用 Nginx 做爲一個反向代理服務器，具體的深刻原理以及負載均衡器等等，我會在之後的微服務系列中說到（不知不覺又給本身玩了一個坑😭）。

一、Nginx的代理工做原理

反向代理（Reverse Proxy）方式是指以代理服務器來接受 Internet上 的鏈接請求，而後將請求轉發給內部網絡上的服務器；並將從服務器上獲得的結果返回給 Internet 上請求鏈接的客戶端，此時代理服務器對外就表現爲一個服務器。

一般的代理服務器，只用於代理內部網絡對 Internet 外部網絡的鏈接請求，客戶機必須指定代理服務器，並將原本要直接發送到 Web 服務器上的 http 請求發送到代理服務器中。不支持外部網絡對內部網絡的鏈接請求，由於內部網絡對外部網絡是不可見的。當一個代理服務器可以代理外部網絡上的主機， 訪問內部網絡時，這種代理服務的方式稱爲反向代理服務。此時代理服務器對外就表現爲一個Web服務器，外部網絡就能夠簡單把它看成一個標準的 Web 服務器 而不須要特定的配置。不一樣之處在於，這個服務器沒有保存任何網頁的真實數據，全部的靜態網頁或者CGI程序，都保存在內部的Web服務器上。所以對反向代 理服務器的攻擊並不會使得網頁信息遭到破壞，這樣就加強了Web服務器的安全性。

總結來講呢，就是咱們經過 nginx 反向代理服務器處理咱們的請求，具體的數據處理仍是交給 IIS，而後獲得處理過的數據之後，咱們再發送給 Internet 請求的客戶端，這樣就不會存在跨域的問題了。

 

二、Nginx 下載與使用

 下載地址：http://nginx.org/en/download.html

 

我選擇下載穩定版 1.14 ，下載好後解壓，而後就看到根目錄下的 Nginx.exe ，直接雙擊便可開啓服務，而後就會在任務管理器查看到已經啓動的 Nginx 代理服務。

由於默認的是80端口，你們的端口應該都已經被佔用，因此咱們須要修改端口

打開 config 文件夾下的 nginx.conf 文件，而後修改端口號

 server { listen 8077; server_name localhost;

這個很簡單，這個時候記得要重啓 Nginx 服務，你能夠採用命令的形式，不過我有時候會發現無效，我通常使用的時候，在任務管理器中把全部的 nginx 進程所有結束，而後雙擊 nginx.exe 開啓。

這個時候咱們直接訪問 localhost:8077 就發現已經啓動成功了，只不過是 nginx 的歡迎頁。

 老張說：這個時候你必定好奇，爲何僅僅配置下，就能訪問該端口呢，不信的話，你能夠在 cmd 中 經過 netstat -an 命令來查看 8077 端口是否被使用

 

發現已經被監聽使用，若是還不相信，你能夠建立一個 IIS 項目，而後配置 8077 端口，發現會報錯，這也就是說明了，8077端口已經被佔用，準確來講是被 Nginx 佔用的，因此，Nginx 和 IIS同樣都是能夠做爲反向代理服務器來使用，從而能夠經過監聽端口來代理咱們的項目的： 

三、將上文打包後的 dist 文件，配置 Nginx 代理

一、將咱們上邊 build 後的 dist 文件，放到我們下載的 nginx 下的 html文件夾

 

二、配置代理

仍是咱們的 config/nginx.conf 文件，打開並配置 本地代理 ，注意註釋是用 # 號，不是 //

 server { listen 8077;#監聽端口，也就是咱們的項目端口 server_name localhost;#服務器主機 location / { root html;#監聽文件夾，默認是nginx下的html文件夾，也能夠自定義物理路徑 E:\\Nginx\\test index index.html index.htm;#默認首次啓動的文件 } 　　　　 #配置本地代理規則 location /api {#名字取一個 api rewrite ^.+apb/?(.*)$ /$1 break; #路徑重寫機制（無用，可是你也能夠本身定義，對路由進行變化） include uwsgi_params; proxy_pass http://123.206.33.109:8081; #api接口的域名地址
        }

 

四、本地以及服務器發佈預覽

 這個時候，你再訪問 localhost:8077 就能看到咱們的項目內容了，訪問頁面也能看到咱們的數據了，代理成功！ 

 

 

這個時候僅僅是本地，那服務器行不行呢，咱們只須要將咱們的 nginx 文件夾拷貝到服務器，而且雙擊 nginx.exe 啓動代理服務，而後就能夠啦！

是否是很簡單，只須要把http.js 的baseurl 修改一下，徹底不用修改咱們任何的調用接口地址，也不用修改後端，就能夠實現跨域。

 相關代理，包括 nginx 文件夾，我已經放到 git 上，你們能夠本身看一看。

 

五、刷新後出現 404

若是使用Ngxin 部署，可能會出現刷新的時候，404 的問題，有複雜的，也有簡單的辦法，複雜的之後補充，這裏先說下簡單的：

就是直接在 dist 中，複製 index.html ，而後重命名一個新文件 404.html ，這兩個文件是如出一轍的：

 

 

 

 

3、結語

 本篇文章是接着上一篇跨域文章的下篇，經過這 5 種方法，很好的實現了跨域問題，不只僅是在 Vue 項目中，其餘任何均可以這麼使用，完美的解決了問題，與 CORS 相比，Nginx 更有前端主動權，各有利弊，我更傾向於 Nginx 代理，由於之後會涉及到負載均衡的使用，好啦，明天說說 EFCore 的使用吧（注：這是個人一個坑，原本想寫一篇文章，可是發現比較簡單，你們看看官網就知道，或者看個人第二個DDD系列中，用到了這個EFCore，若是想了解，能夠直接看源代碼和相關文章，很簡單的都是https://github.com/anjoy8/ChristDDD）。

4、Github

https://github.com/anjoy8/Blog.Vue