跨域問題，解決之道

跨域問題，在平常開發過程當中，是一個很是熟悉的名詞。今天的話題，結合我以前的項目場景，討論下《跨域問題，解決之道》。

原文地址：跨域問題，解決之道
博客地址：blog.720ui.com/

跨域是什麼

跨域問題，是因爲JavaScript出於安全方面的考慮，不容許跨域調用其餘頁面的對象。換句話說，只有JavaScript存在跨域問題。

什麼狀況下會出現跨域

不一樣源訪問，就算是跨域了喲。那什麼纔算同源呢？通常來講，同源，即同一來源，包括主機名、協議和端口號。
例如，

• blog.720ui.com 和 docs.720ui.com ，是不一樣的二級域名，存在跨域問題。
• blog.720ui.com 和 blog.720ui.com , 是不一樣的協議，存在跨域問題
• blog.720ui.com 和 blog.720ui.com:4000 , 是不一樣的端口號，存在跨域問題。
• blog.720ui.com/java/ 和 blog.720ui.com/about/, 雖然文件夾不一樣，可是是相同域名下，因此不存在跨域問題。

跨域問題廣泛麼

在如今先後端分離，微服務化以後，每每咱們就存在許多不一樣的域名，這種狀況下，就存在很是廣泛的跨域問題。所以，跨域問題，在平常開發過程當中，是一個很是熟悉的名詞。那麼，咱們是如何去解決跨域問題呢？

解決之道

咱們是如何去解決跨域問題呢？來吧，咱們進入正題。

方案一，JSONP（廢棄）

很早很早以前，我有個項目曾經使用過JSONP處理跨域問題。簡單的理解，jsonp是帶有回調函數callback的json，它是一個很棒的方案，可用於解決主流瀏覽器的跨域數據訪問的問題。可是，JSONP方案的侷限性在於，JSONP只能實現GET請求。隨着如今RESTful的興起，JSONP顯得力不從心了。由於，RESTful不只有GET，還存在POST、PUT、PATCH、DELETE。

方案二，CORS（經常使用）

CORS 全稱爲 Cross Origin Resource Sharing（跨域資源共享）。整個CORS通訊過程，都是瀏覽器自動完成，不須要用戶參與。對於開發者來講，CORS通訊與同源的AJAX通訊沒有差異，代碼徹底同樣。瀏覽器一旦發現AJAX請求跨源，就會自動添加一些附加的頭信息，但用戶不會有感受。所以，實現CORS通訊的關鍵是服務端。服務端只需添加相關響應頭信息，便可實現客戶端發出 AJAX 跨域請求。

值得注意的是，瀏覽器必須先以 OPTIONS 請求方式發送一個預請求，從而獲知服務器端對跨源請求所支持 HTTP 方法。在確認服務器容許該跨源請求的狀況下，以實際的 HTTP 請求方法發送那個真正的請求。

咱們絕大多數項目採起這個方案，實現細節，再也不擴展，若是有疑問，能夠關注公衆號私信，或者評論留言喲。

可是，不幸的是，CORS不支持IE八、IE9，若是產品再也不考慮兼容IE低版本的話，能夠忽略，可是若是產品須要兼容目前國內還存在大量低版本的IE市場（百分之二十多），那麼這個須要慎重考慮咯。

附圖，留念。

方案三，搭建中間轉發層（經常使用）

跨域問題的核心是什麼？不一樣源訪問。是啊，若是咱們轉換成同源請求，就不存在這個問題啦。

所以，咱們以前有個項目，經過搭建中間層，固然能夠是java，也能夠是node.js，經過將服務端的請求進行轉發，換句話說，就是dispatcher了一層，那麼前端請求的地址，就被轉發了，因此很好的解決跨域問題。

固然，若是對性能有考量的產品，就須要慎重選擇這個方案咯，由於多了一層中間轉發，不論是網絡開銷，仍是性能負載都是有必定的影響。

方案四，Nginx反向代理（經常使用）

首先，產品須要搭建一箇中轉nginx服務器，用於轉發請求。固然，咱們都是基於Nginx做爲反向代理，因此固然是水到渠成。

那麼，Nginx的思路，就是經過Nginx解析URL地址的時候進行判斷，將請求轉發的具體的服務器上。

說個思路，可能有點暈，我畫個圖，你們就理解了。

當用戶請求xx.720ui.com/server1的時候，Nginx會將請求轉發給Server1這個服務器上的具體應用，從而達到跨域的目的。

總結

跨域問題，在平常開發過程當中，是一個很是熟悉的名詞。咱們在開發過程當中，或多或少都與它打過交道，所以，今天的話題，結合我以前的項目場景，以及JSONP、CORS、中間轉發層、Nginx反向代理四個方案進行總結，討論下《跨域問題，解決之道》。

（完）

更多精彩文章，盡在「服務端思惟」微信公衆號！