14 微服務電商【黑馬樂優商城】：day06-使用nginx反向代理並掌握cors解決跨域

時間 2019-11-09

標籤微服黑馬樂優商城 day06 day 使用 nginx 反向代理掌握 cors 解決欄目 Nginx 简体版

原文原文鏈接

本項目的筆記和資料的Download，請點擊這一句話自行獲取。javascript

day01-springboot（理論篇）；day01-springboot（實踐篇）css

day02-springcloud（理論篇一) ；day02-springcloud(理論篇二) ；day02-springcloud(理論篇三) ；day02-springcloud(理論篇四) ；html

day03-springcloud(Hystix，Feign) ；day03-springcloud(Zuul網關）vue

day04-項目搭建（一）； day04-項目搭建（二）； day04-ES6語法入門java

day05-Vue入門學習node

day06-瞭解vue-router和webpack的使用； day06-初識Vuetify框架UI框架和使用域名訪問本地項目； day06-使用nginx反向代理並掌握cors解決跨域 webpack

14 微服務電商【黑馬樂優商城】：day06-使用nginx反向代理並掌握cors解決跨域

# 0.學習目標

- 使用資料搭建後臺系統
- 會使用nginx進行反向代理
- 實現商品分類查詢功能
- 掌握cors解決跨域
- 實現品牌查詢功能nginx

4.4.nginx解決端口問題

域名問題解決了，可是如今要訪問後臺頁面，還得本身加上端口：http://manage.taotao.com:9001web

這就不夠優雅了。咱們但願的是直接域名訪問：http://manage.taotao.com。這種狀況下端口默認是80，如何才能把請求轉移到9001端口呢？ajax

這裏就要用到反向代理工具：Nginx

4.4.1.什麼是Nginx

nginx能夠做爲web服務器，但更多的時候，咱們把它做爲網關，由於它具有網關必備的功能：

反向代理
負載均衡
動態路由
請求過濾

4.4.2.nginx做爲web服務器

Web服務器分2類：

web應用服務器，如：
- tomcat
- resin
- jetty
web服務器，如：
- Apache 服務器
- Nginx
- IIS

區分：web服務器不能解析jsp等頁面，只能處理js、css、html等靜態資源。
併發：web服務器的併發能力遠高於web應用服務器。

4.4.3.nginx做爲反向代理

什麼是反向代理？

代理：經過客戶機的配置，實現讓一臺服務器(代理服務器)代理客戶機，客戶的全部請求都交給代理服務器處理。
反向代理：用一臺服務器，代理真實服務器，用戶訪問時，再也不是訪問真實服務器，而是代理服務器。

nginx能夠當作反向代理服務器來使用：

咱們須要提早在nginx中配置好反向代理的規則，不一樣的請求，交給不一樣的真實服務器處理
當請求到達nginx，nginx會根據已經定義的規則進行請求的轉發，從而實現路由功能

利用反向代理，就能夠解決咱們前面所說的端口問題，如圖

4.4.4.安裝和使用

安裝

安裝很是簡單，把課前資料提供的nginx直接解壓便可，綠色免安裝！

咱們在本地安裝一臺nginx：

解壓後，目錄結構：

conf：配置目錄
contrib：第三方依賴
html：默認的靜態資源目錄
logs：日誌目錄
nginx.exe：啓動程序

反向代理配置

示例：

nginx中的每一個server就是一個反向代理配置，能夠有多個server

完整配置：

#user  nobody;
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;

    keepalive_timeout  65;

    gzip  on;
    server {
        listen       80;
        server_name  manage.leyou.com;

        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        location / {
            proxy_pass http://127.0.0.1:9001;
            proxy_connect_timeout 600;
            proxy_read_timeout 600;
        }
    }
    server {
        listen       80;
        server_name  api.leyou.com;

        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        location / {
            proxy_pass http://127.0.0.1:10010;
            proxy_connect_timeout 600;
            proxy_read_timeout 600;
        }
    }
}

View Code 二級域名 Nginx反向代理

使用

nginx能夠經過命令行來啓動，操做命令：

啓動：start nginx.exe
中止：nginx.exe -s stop
從新加載：nginx.exe -s reload

啓動過程會閃爍一下，啓動成功後，任務管理器中會有兩個nginx進程。

4.5.測試

啓動nginx，而後用域名訪問後臺管理系統：

如今實現了域名訪問網站了，中間的流程是怎樣的呢？

瀏覽器準備發起請求，訪問http://mamage.leyou.com，但須要進行域名解析
優先進行本地域名解析，由於咱們修改了hosts，因此解析成功，獲得地址：127.0.0.1
請求被髮往解析獲得的ip，而且默認使用80端口：http://127.0.0.1:80

本機的nginx一直監聽80端口，所以捕獲這個請求
nginx中配置了反向代理規則，將manage.leyou.com代理到127.0.0.1:9001，所以請求被轉發
後臺系統的webpack server監聽的端口是9001，獲得請求並處理，完成後將響應返回到nginx
nginx將獲得的結果返回到瀏覽器

5.實現商品分類查詢

商城的核心天然是商品，而商品多了之後，確定要進行分類，而且不一樣的商品會有不一樣的品牌信息，其關係如圖所示：

一個商品分類下有不少商品
一個商品分類下有不少品牌
而一個品牌，可能屬於不一樣的分類
一個品牌下也會有不少商品

所以，咱們須要依次去完成：商品分類、品牌、商品的開發。

5.1.導入數據

首先導入課前資料提供的sql：

咱們先看商品分類表：

由於商品分類會有層級關係，所以這裏咱們加入了parent_id字段，對本表中的其它分類進行自關聯。

5.2.頁面實現

5.2.1.頁面分析

首先咱們看下要實現的效果：

商品分類之間是會有層級關係的，採用樹結構去展現是最直觀的方式。

一塊兒來看頁面，對應的是/pages/item/Category.vue：

頁面模板：

<template>
  <v-card>
      <v-flex xs12 sm10>
        <v-tree url="/item/category/list"
                :treeData="treeData"
                :isEdit="isEdit"
                @handleAdd="handleAdd"
                @handleEdit="handleEdit"
                @handleDelete="handleDelete"
                @handleClick="handleClick"
        />
      </v-flex>
  </v-card>
</template>

View Code

v-card：卡片，是vuetify中提供的組件，提供一個懸浮效果的面板，通常用來展現一組數據。

v-flex：佈局容器，用來控制響應式佈局。與BootStrap的柵格系統相似，整個屏幕被分爲12格。咱們能夠控制所佔的格數來控制寬度：

本例中，咱們用sm10控制在小屏幕及以上時，顯示寬度爲10格
v-tree：樹組件。Vuetify並無提供樹組件，這個是咱們本身編寫的自定義組件：

裏面涉及一些vue的高級用法，你們暫時不要關注其源碼，會用便可。

5.2.2.樹組件的用法

也可參考課前資料中的：《自定義Vue組件的用法.md》

這裏我貼出樹組件的用法指南。

屬性列表：

屬性名稱	說明	數據類型	默認值
url	用來加載數據的地址，即延遲加載	String	-
isEdit	是否開啓樹的編輯功能	boolean	false
treeData	整顆樹數據，這樣就不用遠程加載了	Array	-

這裏推薦使用url進行延遲加載，每當點擊父節點時，就會發起請求，根據父節點id查詢子節點信息。

當有treeData屬性時，就不會觸發url加載

遠程請求返回的結果格式：

[
    { 
        "id": 74,
        "name": "手機",
        "parentId": 0,
        "isParent": true,
        "sort": 2
    },
     { 
        "id": 75,
        "name": "家用電器",
        "parentId": 0,
        "isParent": true,
        "sort": 3
    }
]

View Code

事件：

事件名稱	說明	回調參數
handleAdd	新增節點時觸發，isEdit爲true時有效	新增節點node對象，包含屬性：name、parentId和sort
handleEdit	當某個節點被編輯後觸發，isEdit爲true時有效	被編輯節點的id和name
handleDelete	當刪除節點時觸發，isEdit爲true時有效	被刪除節點的id
handleClick	點擊某節點時觸發	被點擊節點的node對象,包含完整的node信息

完整node的信息

回調函數中返回完整的node節點會包含如下數據：

{
    "id": 76, // 節點id
    "name": "手機", // 節點名稱
    "parentId": 75, // 父節點id
    "isParent": false, // 是不是父節點
    "sort": 1, // 順序
    "path": ["手機", "手機通信", "手機"] // 全部父節點的名稱數組
}

5.3.實現功能

5.3.1.url異步請求

給你們的頁面中，treeData是假數據，咱們刪除數據treeData屬性，只保留url看看會發生什麼：

<v-tree url="/item/category/list"
        :isEdit="isEdit"
        @handleAdd="handleAdd"
        @handleEdit="handleEdit"
        @handleDelete="handleDelete"
        @handleClick="handleClick"
        />

刷新頁面，能夠看到：

頁面中的樹沒有了，而且發起了一條請求：http://localhost/api/item/category/list?pid=0

你們可能會以爲很奇怪，咱們明明是使用的相對路徑，講道理髮起的請求地址應該是：

http://manage.leyou.com/item/category/list

但實際倒是：

http://localhost/api/item/category/list?pid=0

這是由於，咱們有一個全局的配置文件，對全部的請求路徑進行了約定：

路徑是localhost，而且默認加上了/api的前綴，這剛好與咱們的網關設置匹配，咱們只須要把地址改爲網關的地址便可,由於咱們使用了nginx反向代理，這裏能夠寫域名。

接下來，咱們要作的事情就是編寫後臺接口，返回對應的數據便可。

5.3.2.實體類

在ly-item-interface中添加category實體類：

內容：

package com.leyou.item.pojo;

import lombok.Data;
import tk.mybatis.mapper.annotation.KeySql;

import javax.persistence.Id;
import javax.persistence.Table;

@Table(name="tb_category")
@Data
public class Category {
    @Id
    @KeySql(useGeneratedKeys=true)
    private Long id;
    private String name;
    private Long parentId;
    private Boolean isParent;
    private Integer sort;
    // getter和setter略
    // 注意isParent生成的getter和setter方法須要手動加上Is
}

public class Category

要注意的是，這裏要用到jpa的註解，所以咱們在ly-item-iterface中添加jpa依賴的替代方案：

        <dependency>
            <groupId>tk.mybatis</groupId>
            <artifactId>mapper-core</artifactId>
            <version>1.0.4</version>
        </dependency>

5.3.3.controller

編寫一個controller通常須要知道四個內容：

請求方式：決定咱們用GetMapping仍是PostMapping
請求路徑：決定映射路徑
請求參數：決定方法的參數
返回值結果：決定方法的返回值

在剛纔頁面發起的請求中，咱們就能獲得絕大多數信息：

請求方式：Get
請求路徑：/api/item/category/list。其中/api是網關前綴，/item是網關的路由映射，真實的路徑應該是/category/list
請求參數：pid=0，根據tree組件的說明，應該是父節點的id，第一次查詢爲0，那就是查詢一級類目
返回結果：？？

根據前面tree組件的用法咱們知道，返回的應該是json數組：

[
    { 
        "id": 74,
        "name": "手機",
        "parentId": 0,
        "isParent": true,
        "sort": 2
    },
     { 
        "id": 75,
        "name": "家用電器",
        "parentId": 0,
        "isParent": true,
        "sort": 3
    }
]

View Code

對應的java類型能夠是List集合，裏面的元素就是類目對象了。也就是List<Category>

添加Controllerr代碼：

@RestController
@RequestMapping("category")
public class CategoryController {
    @Autowired
    private CategoryService categoryService;

    /**
     * 根據父節點id查詢商品分類
     * @param pid
     * @return
     */
    @GetMapping("list")
    public ResponseEntity<List<Category>> queryCategoryListByPid(@RequestParam("pid")Long pid){
        return ResponseEntity.ok(categoryService.queryCategoryListByPid(pid));
    }
}

5.3.4.service

通常service層咱們會定義接口和實現類，不過這裏咱們就偷懶一下，直接寫實現類了：

@Service
public class CategoryServiceImpl implements CategoryService {
    @Autowired
    private CategoryMapper categoryMapper;

    @Override
    public List<Category> queryCategoryListByPid(Long pid) {
        //查詢條件，mapper會把對象中的非空屬性做爲查詢條件
        Category t =new Category();
        t.setParentId(pid);
        //該方法查詢實體對象中非空字段
        List<Category> list = categoryMapper.select(t);
        if(CollectionUtils.isEmpty(list)){
            throw new LyException(ExceptionEnum.CATEGORY_NOT_FOND);
        }

        return list;
    }
}

添加自定義異常的枚舉內容：

package com.leyou.common.enums;

import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Getter
@NoArgsConstructor
@AllArgsConstructor
public enum ExceptionEnum {

    PRICE_CANNOT_BE_NULL(400,"價格不能爲空！"),
    CATEGORY_NOT_FOND(404,"商品分類沒查到"),
    ;
    private int code;
    private String msg;

}

public enum ExceptionEnum

5.3.5.mapper

咱們使用通用mapper來簡化開發：

public interface CategoryMapper extends Mapper<Category> {
}

要注意，咱們並無在mapper接口上聲明@Mapper註解，那麼mybatis如何才能找到接口呢？

咱們在啓動類上添加一個掃描包功能：

@SpringBootApplication
@EnableDiscoveryClient
@MapperScan("com.leyou.item.mapper") // mapper接口的包掃描
public class LeyouItemServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(LeyouItemServiceApplication.class, args);
    }
}

5.3.6.啓動並測試

咱們不通過網關，直接訪問：http://localhost:8081/category/list

而後試試網關是否暢通：http://api.leyou.com/api/item/category/list

一切OK！

而後刷新後臺管理頁面查看：

發現報錯了！

瀏覽器直接訪問沒事，可是這裏卻報錯，什麼緣由？

6.跨域問題

跨域：瀏覽器對於javascript的同源策略的限制。

如下狀況都屬於跨域：

跨域緣由說明	示例
域名不一樣	`www.jd.com` 與 `www.taobao.com`
域名相同，端口不一樣	`www.jd.com:8080` 與 `www.jd.com:8081`
二級域名不一樣	`item.jd.com` 與 `miaosha.jd.com`

若是域名和端口都相同，可是請求路徑不一樣，不屬於跨域，如：

www.jd.com/item

www.jd.com/goods

而咱們剛纔是從manage.leyou.com去訪問api.leyou.com，這屬於二級域名不一樣，跨域了。

6.1.爲何有跨域問題？

跨域不必定會有跨域問題。

由於跨域問題是瀏覽器對於ajax請求的一種安全限制：一個頁面發起的ajax請求，只能是與當前頁域名相同的路徑，這能有效的阻止跨站攻擊。

所以：跨域問題是針對ajax的一種限制。

可是這卻給咱們的開發帶來了不便，並且在實際生產環境中，確定會有不少臺服務器之間交互，地址和端口均可能不一樣，怎麼辦？

6.2.解決跨域問題的方案

目前比較經常使用的跨域解決方案有3種：

Jsonp

最先的解決方案，利用script標籤能夠跨域的原理實現。

限制：
- 須要服務的支持
- 只能發起GET請求

nginx反向代理

思路是：利用nginx把跨域反向代理爲不跨域，支持各類請求方式

缺點：須要在nginx進行額外配置，語義不清晰
CORS

規範化的跨域請求解決方案，安全可靠。

優點：
- 在服務端進行控制是否容許跨域，可自定義規則
- 支持各類請求方式
缺點：
- 會產生額外的請求

咱們這裏會採用cors的跨域方案。

6.3.cors解決跨域

6.3.1.什麼是cors

CORS是一個W3C標準，全稱是"跨域資源共享"（Cross-origin resource sharing）。

它容許瀏覽器向跨源服務器，發出XMLHttpRequest請求，從而克服了AJAX只能同源使用的限制。

CORS須要瀏覽器和服務器同時支持。目前，全部瀏覽器都支持該功能，IE瀏覽器不能低於IE10。

瀏覽器端：

目前，全部瀏覽器都支持該功能（IE10如下不行）。整個CORS通訊過程，都是瀏覽器自動完成，不須要用戶參與。
服務端：

CORS通訊與AJAX沒有任何差異，所以你不須要改變之前的業務邏輯。只不過，瀏覽器會在請求中攜帶一些頭信息，咱們須要以此判斷是否容許其跨域，而後在響應頭中加入一些信息便可。這通常經過過濾器完成便可。

6.3.2.原理有點複雜

瀏覽器會將ajax請求分爲兩類，其處理方案略有差別：簡單請求、特殊請求。

6.3.2.1.簡單請求

只要同時知足如下兩大條件，就屬於簡單請求。：

（1) 請求方法是如下三種方法之一：

HEAD
GET
POST

（2）HTTP的頭信息不超出如下幾種字段：

Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain

當瀏覽器發現發起的ajax請求是簡單請求時，會在請求頭中攜帶一個字段：Origin

Origin中會指出當前請求屬於哪一個域（協議+域名+端口）。服務會根據這個值決定是否容許其跨域。

若是服務器容許跨域，須要在返回的響應頭中攜帶下面信息：

Access-Control-Allow-Origin: http://manage.leyou.com
Access-Control-Allow-Credentials: true
Content-Type: text/html; charset=utf-8

Access-Control-Allow-Origin：可接受的域，是一個具體域名或者*（表明任意域名）
Access-Control-Allow-Credentials：是否容許攜帶cookie，默認狀況下，cors不會攜帶cookie，除非這個值是true

有關cookie：

要想操做cookie，須要知足3個條件：

服務的響應頭中須要攜帶Access-Control-Allow-Credentials而且爲true。
瀏覽器發起ajax須要指定withCredentials 爲true
響應頭中的Access-Control-Allow-Origin必定不能爲*，必須是指定的域名

6.3.2.2.特殊請求

不符合簡單請求的條件，會被瀏覽器斷定爲特殊請求,，例如請求方式爲PUT。

預檢請求

特殊請求會在正式通訊以前，增長一次HTTP查詢請求，稱爲"預檢"請求（preflight）。

瀏覽器先詢問服務器，當前網頁所在的域名是否在服務器的許可名單之中，以及可使用哪些HTTP動詞和頭信息字段。只有獲得確定答覆，瀏覽器纔會發出正式的XMLHttpRequest請求，不然就報錯。

一個「預檢」請求的樣板：

OPTIONS /cors HTTP/1.1
Origin: http://manage.leyou.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.leyou.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

與簡單請求相比，除了Origin之外，多了兩個頭：

Access-Control-Request-Method：接下來會用到的請求方式，好比PUT
Access-Control-Request-Headers：會額外用到的頭信息

預檢請求的響應

服務的收到預檢請求，若是許可跨域，會發出響應：

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://manage.leyou.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Max-Age: 1728000
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

除了Access-Control-Allow-Origin和Access-Control-Allow-Credentials之外，這裏又額外多出3個頭：

Access-Control-Allow-Methods：容許訪問的方式
Access-Control-Allow-Headers：容許攜帶的頭
Access-Control-Max-Age：本次許可的有效時長，單位是秒，過時以前的ajax請求就無需再次進行預檢了

若是瀏覽器獲得上述響應，則認定爲能夠跨域，後續就跟簡單請求的處理是同樣的了。

6.3.3.實現很是簡單

雖然原理比較複雜，可是前面說過：

瀏覽器端都有瀏覽器自動完成，咱們無需操心
服務端能夠經過攔截器統一實現，沒必要每次都去進行跨域斷定的編寫。

事實上，SpringMVC已經幫咱們寫好了CORS的跨域過濾器：CorsFilter ,內部已經實現了剛纔所講的斷定邏輯，咱們直接用就行了。

在leyou-gateway中編寫一個配置類，而且註冊CorsFilter：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
import org.springframework.web.filter.CorsFilter;

@Configuration
public class GlobalCorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        //1.添加CORS配置信息
        CorsConfiguration config = new CorsConfiguration();
        //1) 容許的域,不要寫*，不然cookie就沒法使用了
        config.addAllowedOrigin("http://manage.leyou.com");
        //2) 是否發送Cookie信息
        config.setAllowCredentials(true);
        //3) 容許的請求方式
        config.addAllowedMethod("OPTIONS");
        config.addAllowedMethod("HEAD");
        config.addAllowedMethod("GET");
        config.addAllowedMethod("PUT");
        config.addAllowedMethod("POST");
        config.addAllowedMethod("DELETE");
        config.addAllowedMethod("PATCH");
        // 4）容許的頭信息
        config.addAllowedHeader("*");

        //2.添加映射路徑，咱們攔截一切請求
        UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
        configSource.registerCorsConfiguration("/**", config);

        //3.返回新的CorsFilter.
        return new CorsFilter(configSource);
    }
}