標籤: 網站設計

本文來自作者投稿，原作者：上帝愛吃蘋果

目前在魔都，貝殼找房是我的僱主，平時關注一些 java 領域相關的技術，希望你們能在這篇文章中找到些有用的東西。個人水平有限，如果文章有錯誤還請指出，在留言區一起交流。

我想大家肯定都或多或少的看過各種“策略模式”的講解、佈道等等，這篇文章就是來好好“澄清”一下策略模式，並嘗試回答以下的問題：

1. 策略模式是如何優化業務邏輯代碼結構的？

2. 殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！

3. 有沒有什麼更好的代碼結構來實現策略模式的嗎？

策略模式是如何優化業務邏輯代碼結構的？

要回答這個問題，我們還得先扒一扒策略模式的定義，從定義着手來理解它

策略模式的教科書定義

它的定義很精簡：一個類的行為或其算法可以在運行時更改。我們把它降維到代碼層面，用人話翻譯一下就是，運行時我給你這個類的方法傳不同的“key”，你這個方法會執行不同的業務邏輯。細品一下，這不就是 if else 乾的事嗎？

策略模式優化了什麼？

其實策略模式的核心思想和 if else如出一轍，根據不同的key動態的找到不同的業務邏輯，那它就只是如此嗎？

實際上，我們口中的策略模式其實就是在代碼結構上調整，用接口+實現類+分派邏輯來使代碼結構可維護性好點。

一般教科書上講解到接口與實現類就結束了，其他博客上會帶上提及分派邏輯。這裏就不啰嗦了。

小結一下，即使用了策略模式，你該寫的業務邏輯照常寫，到邏輯分派的時候，還是變相的if else。而它的優化點是抽象了出了接口，將業務邏輯封裝成一個一個的實現類，任意地替換。在複雜場景（業務邏輯較多）時比直接 if else 來的好維護些。

殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！

我想小夥伴們經常有這樣的不滿，我的業務邏輯就3 4 行，你給我整一大堆類定義？有必要這麼麻煩嗎？我看具體的業務邏輯還需要去不同的類中，簡單點行不行。

其實我們所不滿的就是策略模式帶來的缺點：

1、策略類會增多

2、業務邏輯分散到各個實現類中，而且沒有一個地方可以俯視整個業務邏輯

針對傳統策略模式的缺點，在這分享一個實現思路，這個思路已經幫我們團隊解決了多個複雜if else的業務場景，理解上比較容易，代碼上需要用到Java8的特性——利用Map與函數式接口來實現。

直接show代碼結構：為了簡單演示一個思路，代碼用String 類型來模擬一個業務BO

其中：

1. getCheckResult() 為傳統的做法

2. getCheckResultSuper()則事先在Map中定義好了“判斷條件”與“業務邏輯”的映射關係,具體講解請看代碼註釋

/**
 * 某個業務服務類
 */
@Service
public class BizService {

    /**
     * 傳統的 if else 解決方法
     * 當每個業務邏輯有 3 4 行時，用傳統的策略模式不值得，直接的if else又顯得不易讀
     */
    public String getCheckResult(String order) {
        if ("校驗1".equals(order)) {
            return "執行業務邏輯1";
        } else if ("校驗2".equals(order)) {
            return "執行業務邏輯2";
        }else if ("校驗3".equals(order)) {
            return "執行業務邏輯3";
        }else if ("校驗4".equals(order)) {
            return "執行業務邏輯4";
        }else if ("校驗5".equals(order)) {
            return "執行業務邏輯5";
        }else if ("校驗6".equals(order)) {
            return "執行業務邏輯6";
        }else if ("校驗7".equals(order)) {
            return "執行業務邏輯7";
        }else if ("校驗8".equals(order)) {
            return "執行業務邏輯8";
        }else if ("校驗9".equals(order)) {
            return "執行業務邏輯9";
        }
        return "不在處理的邏輯中返回業務錯誤";
    }

    /**
     * 業務邏輯分派Map
     * Function為函數式接口，下面代碼中 Function<String, String> 的含義是接收一個Stirng類型的變量，返回一個String類型的結果
     */
    private Map<String, Function<String, String>> checkResultDispatcher = new HashMap<>();

    /**
     * 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
     */
    @PostConstruct
    public void checkResultDispatcherInit() {
        checkResultDispatcher.put("校驗1", order -> String.format("對%s執行業務邏輯1", order));
        checkResultDispatcher.put("校驗2", order -> String.format("對%s執行業務邏輯2", order));
        checkResultDispatcher.put("校驗3", order -> String.format("對%s執行業務邏輯3", order));
        checkResultDispatcher.put("校驗4", order -> String.format("對%s執行業務邏輯4", order));
        checkResultDispatcher.put("校驗5", order -> String.format("對%s執行業務邏輯5", order));
        checkResultDispatcher.put("校驗6", order -> String.format("對%s執行業務邏輯6", order));
        checkResultDispatcher.put("校驗7", order -> String.format("對%s執行業務邏輯7", order));
        checkResultDispatcher.put("校驗8", order -> String.format("對%s執行業務邏輯8", order));
        checkResultDispatcher.put("校驗9", order -> String.format("對%s執行業務邏輯9", order));
    }

    public String getCheckResultSuper(String order) {
        //從邏輯分派Dispatcher中獲得業務邏輯代碼，result變量是一段lambda表達式
        Function<String, String> result = checkResultDispatcher.get(order);
        if (result != null) {
            //執行這段表達式獲得String類型的結果
            return result.apply(order);
        }
        return "不在處理的邏輯中返回業務錯誤";
    }
}

通過http調用一下看看效果：

/**
 * 模擬一次http調用
 */
@RestController
public class BizController {

    @Autowired
    private BizService bizService;

    @PostMapping("/v1/biz/testSuper")
    public String test2(String order) {
        return bizService.getCheckResultSuper(order);
    }
}

這是個簡單的demo演示，之後會舉一些複雜的場景案例。

魯迅曾說過，“每解決一個問題，就會因出更多的問題”。我們一起來看看這樣的實現有什麼好處，會帶來什麼問題。

好處很直觀：

1. 在一段代碼里直觀的看到”判斷條件”與業務邏輯的映射關係
2. 不需要單獨定義接口與實現類，直接使用現有的函數式接口（什麼？不知道函數式接口？快去了解），而實現類直接就是業務代碼本身。

不好的點：

1. 需要團隊成員對lambda表達式有所了解(什麼？Java14都出來了還有沒用上Java8新特性的小夥伴？)

接下來我舉幾個在業務中經常遇到的if else場景，並用Map+函數式接口的方式來解決它

在真實業務場景問題的解決思路

有的小夥伴會說，我的判斷條件有多個啊，而且很複雜，你之前舉個例子只有單個判斷邏輯，而我有多個判斷邏輯該怎麼辦呢？

很好解決：寫一個判斷邏輯的方法，Map的key由方法計算出

/**
 * 某個業務服務類
 */
@Service
public class BizService {

    private Map<String, Function<String, String>> checkResultDispatcherMuti = new HashMap<>();

    /**
     * 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
     */
    @PostConstruct
    public void checkResultDispatcherMuitInit() {
        checkResultDispatcherMuti.put("key_訂單1", order -> String.format("對%s執行業務邏輯1", order));
        checkResultDispatcherMuti.put("key_訂單1_訂單2", order -> String.format("對%s執行業務邏輯2", order));
        checkResultDispatcherMuti.put("key_訂單1_訂單2_訂單3", order -> String.format("對%s執行業務邏輯3", order));
    }

    public String getCheckResultMuti(String order, int level) {
        //寫一段生成key的邏輯：
        String ley = getDispatcherKey(order, level);

        Function<String, String> result = checkResultDispatcherMuti.get(ley);
        if (result != null) {
            //執行這段表達式獲得String類型的結果
            return result.apply(order);
        }
        return "不在處理的邏輯中返回業務錯誤";
    }

    /**
     * 判斷條件方法
     */
    private String getDispatcherKey(String order, int level) {
        StringBuilder key = new StringBuilder("key");
        for (int i = 1; i <= level; i++) {
            key.append("_" + order + i);
        }
        return key.toString();
    }
}

用http模擬一下：

/**
 * 模擬一次http調用
 */
@RestController
public class BizController {

    @Autowired
    private BizService bizService;

    @PostMapping("/v1/biz/testMuti")
    public String test1(String order, Integer level) {
        return bizService.getCheckResultMuti(order, level);
    }
}

只要設計好你的key的生成規則就好。

還有小夥伴會問：我的業務邏輯有很多很多行，在checkResultDispatcherMuitInit()方法的Map中直接寫不會很長嗎？

直接寫當然長了，我們可以抽象出一個service服務專門放業務邏輯，然後在定義中調用它就好了：

提供一個業務邏輯單元：

/**
 * 提供業務邏輯單元
 */
@Service
public class BizUnitService {

    public String bizOne(String order) {
        return order + "各種花式操作1";
    }
    public String bizTwo(String order) {
        return order + "各種花式操作2";
    }
    public String bizThree(String order) {
        return order + "各種花式操作3";
    }
}

/**
 * 某個業務服務類
 */
@Service
public class BizService {
    @Autowired
    private BizUnitService bizUnitService;

    private Map<String, Function<String, String>> checkResultDispatcherComX = new HashMap<>();

    /**
     * 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
     */
    @PostConstruct
    public void checkResultDispatcherComXInit() {
        checkResultDispatcherComX.put("key_訂單1", order -> bizUnitService.bizOne(order));
        checkResultDispatcherComX.put("key_訂單1_訂單2", order -> bizUnitService.bizTwo(order));
        checkResultDispatcherComX.put("key_訂單1_訂單2_訂單3", order -> bizUnitService.bizThree(order));
    }

    public String getCheckResultComX(String order, int level) {
        //寫一段生成key的邏輯：
        String ley = getDispatcherComXKey(order, level);

        Function<String, String> result = checkResultDispatcherComX.get(ley);
        if (result != null) {
            //執行這段表達式獲得String類型的結果
            return result.apply(order);
        }
        return "不在處理的邏輯中返回業務錯誤";
    }

    /**
     * 判斷條件方法
     */
    private String getDispatcherComXKey(String order, int level) {
        StringBuilder key = new StringBuilder("key");
        for (int i = 1; i <= level; i++) {
            key.append("_" + order + i);
        }
        return key.toString();
    }
}

調用結果：

總結

最後，我們一起嘗試回答以下幾個問題：

1. 策略模式是如何優化業務邏輯代碼結構的？

抽象了出了接口，將業務邏輯封裝成一個一個的實現類，任意地替換。在複雜場景（業務邏輯較多）時比直接 if else 來的好維護些。

2. 殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！

我們所不滿的其實就是傳統接口實現的缺點： 1、策略類會很多。 2、業務邏輯分散到各個實現類中，而且沒有一個地方可以俯覽整個業務邏輯

3. 有沒有什麼更好的代碼結構來實現策略模式的嗎？

針對傳統策略模式的缺點，分享了利用Map與函數式接口來實現的思路。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

目錄

• 序言
• DOM事件流
  • 事件捕獲階段、處於目標階段、事件冒泡階段
  • addEventListener 方法
• React 事件概述
• 事件註冊
  • document 上註冊
  • 回調函數存儲
• 事件分發
• 小結
• 參考

1.序言

React 有一套自己的事件系統，其事件叫做合成事件。為什麼 React 要自定義一套事件系統？React 事件是如何註冊和觸發的？React 事件與原生 DOM 事件有什麼區別？帶着這些問題，讓我們一起來探究 React 事件機制的原理。為了便於理解，此篇分析將盡可能用圖解代替貼 React 源代碼進行解析。

2.DOM事件流

首先，在正式講解 React 事件之前，有必要了解一下 DOM 事件流，其包含三個流程：事件捕獲階段、處於目標階段和事件冒泡階段。

W3C協會早在1988年就開始了DOM標準的制定，W3C DOM標準可以分為 DOM1、DOM2、DOM3 三個版本。

從 DOM2 開始，DOM 的事件傳播分三個階段進行：事件捕獲階段、處於目標階段和事件冒泡階段。

（1）事件捕獲階段、處於目標階段和事件冒泡階段

示例代碼：

<html>
    <body>
        <div id="outer">
	    <p id="inner">Click me!</p>
	</div>
    </body>
</html>

上述代碼，如果點擊 <p>元素，那麼 DOM 事件流如下圖：

（1）事件捕獲階段：事件對象通過目標節點的祖先 Window 傳播到目標的父節點。

（2）處於目標階段：事件對象到達事件目標節點。如果阻止事件冒泡，那麼該事件對象將在此階段完成后停止傳播。

（3）事件冒泡階段：事件對象以相反的順序從目標節點的父項開始傳播，從目標節點的父項開始到 Window 結束。

（2）addEventListener 方法

DOM 的事件流中同時包含了事件捕獲階段和事件冒泡階段，而作為開發者，我們可以選擇事件處理函數在哪一個階段被調用。

addEventListener() 方法用於為特定元素綁定一個事件處理函數。addEventListener 有三個參數：

element.addEventListener(event, function, useCapture)

另外，如果一個元素（element）針對同一個事件類型（event），多次綁定同一個事件處理函數（function），那麼重複的實例會被拋棄。當然如果第三個參數capture值不一致，此時就算重複定義，也不會被拋棄掉。

3.React 事件概述

React 根據W3C 規範來定義自己的事件系統，其事件被稱之為合成事件 (SyntheticEvent)。而其自定義事件系統的動機主要包含以下幾個方面：

（1）抹平不同瀏覽器之間的兼容性差異。最主要的動機。

（2）事件”合成”，即事件自定義。事件合成既可以處理兼容性問題，也可以用來自定義事件（例如 React 的 onChange 事件）。

（3）提供一個抽象跨平台事件機制。類似 VirtualDOM 抽象了跨平台的渲染方式，合成事件（SyntheticEvent）提供一個抽象的跨平台事件機制。

（4）可以做更多優化。例如利用事件委託機制，幾乎所有事件的觸發都代理到了 document，而不是 DOM 節點本身，簡化了 DOM 事件處理邏輯，減少了內存開銷。（React 自身模擬了一套事件冒泡的機制）

（5）可以干預事件的分發。V16引入 Fiber 架構，React 可以通過干預事件的分發以優化用戶的交互體驗。

注：「幾乎」所有事件都代理到了 document，說明有例外，比如audio、video標籤的一些媒體事件（如 onplay、onpause 等），是 document 所不具有，這些事件只能夠在這些標籤上進行事件進行代理，但依舊用統一的入口分發函數（dispatchEvent）進行綁定。

4.事件註冊

React 的事件註冊過程主要做了兩件事：document 上註冊、存儲事件回調。

（1）document 上註冊

在 React 組件掛載階段，根據組件內的聲明的事件類型（onclick、onchange 等），在 document 上註冊事件（使用addEventListener），並指定統一的回調函數 dispatchEvent。換句話說，document 上不管註冊的是什麼事件，都具有統一的回調函數 dispatchEvent。也正是因為這一事件委託機制，具有同樣的回調函數 dispatchEvent，所以對於同一種事件類型，不論在 document 上註冊了幾次，最終也只會保留一個有效實例，這能減少內存開銷。

示例代碼：

function TestComponent() {
  handleFatherClick=()=>{
		// ...
  }

  handleChildClick=()=>{
		// ...
  }

  return <div className="father" onClick={this.handleFatherClick}>
	<div className="child" onClick={this.handleChildClick}>child </div>
  </div>
}

上述代碼中，事件類型都是onclick，由於 React 的事件委託機制，會指定統一的回調函數 dispatchEvent，所以最終只會在 document 上保留一個 click 事件，類似document.addEventListener('click', dispatchEvent)，從這裏也可以看出 React 的事件是在 DOM 事件流的冒泡階段被觸發執行。

（2）存儲事件回調

React 為了在觸發事件時可以查找到對應的回調去執行，會把組件內的所有事件統一地存放到一個對象中（listenerBank）。而存儲方式如上圖，首先會根據事件類型分類存儲，例如 click 事件相關的統一存儲在一個對象中，回調函數的存儲採用鍵值對（key/value）的方式存儲在對象中，key 是組件的唯一標識 id，value 對應的就是事件的回調函數。

React 的事件註冊的關鍵步驟如下圖：

5.事件分發

事件分發也就是事件觸發。React 的事件觸發只會發生在 DOM 事件流的冒泡階段，因為在 document 上註冊時就默認是在冒泡階段被觸發執行。

其大致流程如下：

1. 觸發事件，開始 DOM 事件流，先後經過三個階段：事件捕獲階段、處於目標階段和事件冒泡階段
2. 當事件冒泡到 document 時，觸發統一的事件分發函數 ReactEventListener.dispatchEvent
3. 根據原生事件對象（nativeEvent）找到當前節點（即事件觸發節點）對應的 ReactDOMComponent 對象
4. 事件的合成
   1. 根據當前事件類型生成對應的合成對象
   2. 封裝原生事件對象和冒泡機制
   3. 查找當前元素以及它所有父級
   4. 在 listenerBank 中查找事件回調函數併合成到 events 中
5. 批量執行合成事件（events）內的回調函數
6. 如果沒有阻止冒泡，會將繼續進行 DOM 事件流的冒泡（從 document 到 window），否則結束事件觸發

注：上圖中阻止冒泡是指調用stopImmediatePropagation 方法阻止冒泡，如果是調用stopPropagation阻止冒泡，document 上如果還註冊了同類型其他的事件，也將會被觸發執行，但會正常阻斷 window 上事件觸發。了解兩者之間的詳細區別

示例代碼：

class TestComponent extends React.Component {

  componentDidMount() {
    this.parent.addEventListener('click', (e) => {
      console.log('dom parent');
    })
    this.child.addEventListener('click', (e) => {
      console.log('dom child');
    })
    document.addEventListener('click', (e) => {
      console.log('document');
    })
    document.body.addEventListener('click', (e) => {
      console.log('body');
    })
    window.addEventListener('click', (e) => {
      console.log('window');
    })
  }

  childClick = (e) => {
    console.log('react child');
  }

  parentClick = (e) => {
    console.log('react parent');
  }

  render() {
    return (
      <div class='parent' onClick={this.parentClick} ref={ref => this.parent = ref}>
        <div class='child' onClick={this.childClick} ref={ref => this.child = ref}>
          Click me!
        </div>
      </div>)
  }
}

點擊 child div 時，其輸出如下：

在 DOM 事件流的冒泡階段先後經歷的元素：child <div> -> parent <div> -> <body> -> <html> -> document -> window，因此上面的輸出符合預期。

6.小結

React 合成事件和原生 DOM 事件的主要區別:

（1）React 組件上聲明的事件沒有綁定在 React 組件對應的原生 DOM 節點上。

（2）React 利用事件委託機制，將幾乎所有事件的觸發代理（delegate）在 document 節點上，事件對象(event)是合成對象(SyntheticEvent)，不是原生事件對象，但通過 nativeEvent 屬性訪問原生事件對象。

（3）由於 React 的事件委託機制，React 組件對應的原生 DOM 節點上的事件觸發時機總是在 React 組件上的事件之前。

7.參考

javascript中DOM0,DOM2,DOM3級事件模型解析

Event dispatch and DOM event flow

EventTarget.addEventListener() – Web API 接口參考| MDN

合成事件

談談React事件機制和未來(react-events)

React源碼解讀系列 – 事件機制

一文吃透 react 事件機制原理

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

 

BMW i3 純電動汽車今年 8 月在美銷量為 1,025 輛，首次超過特斯拉 Model S，後者 8 月銷量僅為 600 輛。

寶馬 i3 純電動車型在美國市場已上市 3 個月，之前由於寶馬內部的運轉效率問題，其銷量一直低於特斯拉 Model S。但該問題解決後，寶馬 i3 的銷量也迎頭趕上。特斯拉 8 月整體需求較去年同期下降 54%，7 月更是下降了 72%。與 2013 年同期相比，特斯拉今年上半年銷量下降了 26%。

專家稱，特斯拉目前正處發展壯大的階段，而寶馬在歐洲和亞洲市場則以紮穩腳跟。在產品創新度、更新速度及售價方面，特斯拉 Model S 的優勢愈來愈不明顯，而隨著寶馬 i3 的銷量逐步上升，預計歐洲將會成為其最大銷售市場。

 

（圖片來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

如果你想從頭學習Jmeter，可以看看這個系列的文章哦

https://www.cnblogs.com/poloyy/category/1746599.html

 

前言

• Jmeter 使用 JDBC Request 獲取數據庫中數據，很多人都會用，因為測試中，有時候需要大量的用戶進行登錄，然後獲取數據庫中真實的數據用於測試
• 前面也詳細講到 JDBC Request 的具體使用，一般是通過 Variable names 和 Result variable name 來獲取返回的數據
• 這篇文章主要講的就是把 Variable names 和 Result variable name 獲取到的數據提取出來，給到 HTTP 請求使用

 

Variable names + Foreach控制器

線程組結構樹

 

JDBC Request

 

調試取樣器運行結果

有 100 條記錄

 

ForEach控制器

 

循環運行的結果（ mobile:${mobile} ）

 

Variable names + 循環控制器

和上面的栗子只是換了個控制器而已，沒太大變化

線程組結構樹

 

循環控制器

填寫 100，是代表循環100次

 

計數器

從 1 開始，遞增加到 100為止，每次遞增 1

• 初始值=1
• 每次增加 1
• 最大的值=100（包含）
• 新變量 num

 

循環控制器內的 Debug Sampler

 ${__V()} 是關聯函數，後面講到

 

循環運行的結果（ mobile:${mobile} ）

 

Result variable name + Foreach控制器

線程組結構樹

 

JDBC Request

 

正則提取器

 

重點

Applu to 選中 Jmeter Variable Name to use，因為要從 Jmeter Variables 中拿到 result_mobile 變量進行提取

 

調試取樣器運行結果

正則提取后的值是不是跟上面 Variable names 獲取的值列表很像，是的！然後再結合 ForEach控制器就好啦

 

ForEach控制器

變量前綴是正則提取器里的引用名稱

 

循環運行的結果（ mobile:${mobile} ）

 

Result variable name + 循環控制器

和上面的栗子只是換了個控制器而已，沒太大變化

線程組結構樹

 

循環控制器

填寫 100，是代表循環100次

 

計數器

 

用戶參數

重點一

•  ${__BeanShell(vars.getObject(“result_mobile”).get(${num}).get(“mobile”))} 
•  ${__BeanShell()} ：執行BeanShell腳本，一般比較短的腳本可以用此方法來寫，後面會再詳細講解這個函數

重點二

•  vars.getObject(“result_mobile”).get(${num}).get(“mobile”) 
• result_mobile：是一個數組，即 JDBC Request 里的 Result variable name，每個元素的格式都是 {mobile=158000480001} 
• ${num}：上面計數器的值，每次遞增 1，這裡是數組下標的意思
• 總結：獲取 result_mobile 數組，每次取數組中第 num 個元素，從元素中取 mobile 鍵的值【這是固定寫法，只改Object 名、鍵名就行了】

 

循環運行的結果（ mobile:${user_mobile} ）

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※新北清潔公司,居家、辦公、裝潢細清專業服務

※推薦評價好的iphone維修中心

作者簡介

Vyacheslav，擁有運維和項目管理經驗的軟件工程師

這篇文章將承接我此前搭建的本地Docker開發環境，具體步驟已經放在在以下網址：

https://github.com/Voronenko/traefik2-compose-template

除了經典的docker化的項目之外，我還有其他的Kubernetes項目。儘管Kubernetes已經成為容器編排的事實標準，但是不得不承認Kubernetes是一個既消耗資源又消耗金錢的平台。由於我並不經常需要外部集群，因此我使用輕量級K3s發行版來進行Kubernetes本地開發。

K3s是為IoT和邊緣計算而構建的經過認證的Kubernetes發行版之一，還能夠按產品規模部署到VM。

我使用K3s的方式是這樣的：在我的工作筆記本上本地安裝K3s，儘管有時我需要在本地部署較重的測試工作負載，為此，我準備了兩個神器——兩個運行ESXi的外部Intel NUCs。

默認情況下，K3s安裝Traefik 1.x作為ingress，如果你對此十分滿意，那麼無需往下繼續閱讀了。

在我的場景中，我同時會牽涉到好幾個項目，特別是經典的docker和docker swarm，因此我經常遇到在獨立模式下部署Traefik的情況。

因此，本文其餘部分將深入介紹如何將外部traefik2配置為K3s集群的ingress。

安裝Kubernetes K3s系列集群

你可以按照常規方式使用命令curl -sfL https://get.k3s.io | sh -安裝K3s，或者你可以使用輕量實用程序k3sup安裝（https://github.com/alexellis/k3sup）。具體步驟在之前的文章介紹過。

與我們的設置不同的是，我們使用命令--no-deploy traefik專門安裝了不帶traefik組件的K3s。

export CLUSTER_MASTER=192.168.3.100
export CLUSTER_DEPLOY_USER=slavko
k3sup install --ip $CLUSTER_MASTER --user $CLUSTER_DEPLOY_USER --k3s-extra-args '--no-deploy traefik'

執行后，你將獲得使用kubectl所需的連接詳細信息。安裝K3s后，你可以快速檢查是否可以看到節點。

# Test your cluster with - export path to k3s cluster kubeconfig:
export KUBECONFIG=/home/slavko/kubeconfig
kubectl get node -o wide

注：這裏沒有固定的安裝模式，你甚至可以使用docker-compose自行啟動它。

server:
  image: rancher/k3s:v0.8.0
  command: server --disable-agent --no-deploy traefik
  environment:
    - K3S_CLUSTER_SECRET=somethingtotallyrandom
    - K3S_KUBECONFIG_OUTPUT=/output/kubeconfig.yaml
    - K3S_KUBECONFIG_MODE=666
  volumes:
    # k3s will generate a kubeconfig.yaml in this directory. This volume is mounted
    # on your host, so you can then 'export KUBECONFIG=/somewhere/on/your/host/out/kubeconfig.yaml',
    # in order for your kubectl commands to work.
    - /somewhere/on/your/host/out:/output
    # This directory is where you put all the (yaml) configuration files of
    # the Kubernetes resources.
    - /somewhere/on/your/host/in:/var/lib/rancher/k3s/server/manifests
  ports:
    - 6443:6443

node:
  image: rancher/k3s:v0.8.0
  privileged: true
  links:
    - server
  environment:
    - K3S_URL=https://server:6443
    - K3S_CLUSTER_SECRET=somethingtotallyrandom
  volumes:
    # this is where you would place a alternative traefik image (saved as a .tar file with
    # 'docker save'), if you want to use it, instead of the traefik:v2.0 image.
    - /sowewhere/on/your/host/custom-image:/var/lib/rancher/k3s/agent/images

配置Traefik 2，與Kubernetes一起使用

在文章開頭提到的鏈接中，我已經在我的系統中安裝了Traefik 2，並根據該鏈接內容，服務於一些需求。現在是時候配置Traefik 2 Kubernetes後端了。

Traefik 2使用CRD（自定義資源定義）來完成這一點。定義的最新示例可以在以下鏈接中找到，但這些示例僅適用於Traefik 2也作為Kubernetes工作負載的一部分執行的情況：

https://docs.traefik.io/reference/dynamic-configuration/kubernetes-crd/

對於外部Traefik 2，我們僅需要以下描述的定義子集。

我們引入一系列自定義資源定義，以允許我們來描述我們的Kubernetes服務將會如何暴露到外部，traefik-crd.yaml：

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressroutes.traefik.containo.us

spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRoute
    plural: ingressroutes
    singular: ingressroute
  scope: Namespaced

---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressroutetcps.traefik.containo.us

spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRouteTCP
    plural: ingressroutetcps
    singular: ingressroutetcp
  scope: Namespaced

---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: middlewares.traefik.containo.us

spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: Middleware
    plural: middlewares
    singular: middleware
  scope: Namespaced

---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: tlsoptions.traefik.containo.us

spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TLSOption
    plural: tlsoptions
    singular: tlsoption
  scope: Namespaced

---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: traefikservices.traefik.containo.us

spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TraefikService
    plural: traefikservices
    singular: traefikservice
  scope: Namespaced  

同時，我們需要集群角色traefik-ingress-controller，以提供對服務、端點和secret的只讀訪問權限以及自定義的traefik.containo.us組，traefik-clusterrole.yaml：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller

rules:
  - apiGroups:
      - ""
    resources:
      - services
      - endpoints
      - secrets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses/status
    verbs:
      - update
  - apiGroups:
      - traefik.containo.us
    resources:
      - middlewares
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - traefik.containo.us
    resources:
      - ingressroutes
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - traefik.containo.us
    resources:
      - ingressroutetcps
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - traefik.containo.us
    resources:
      - tlsoptions
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - traefik.containo.us
    resources:
      - traefikservices
    verbs:
      - get
      - list
      - watch

最後，我們需要系統服務賬號traefik-ingress-controller與之前創建的集群角色traefik-ingress-controller相關聯。

---
kind: ServiceAccount
apiVersion: v1
metadata:
  namespace: kube-system
  name: traefik-ingress-controller

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller

roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-ingress-controller
subjects:
  - kind: ServiceAccount
    name: traefik-ingress-controller
    namespace: kube-system

我們應用以上資源之後：

apply:
  kubectl apply -f traefik-crd.yaml
  kubectl apply -f traefik-clusterrole.yaml
  kubectl apply -f traefik-service-account.yaml

我們已經準備好開始調整Traefik 2

將Traefik 2指向K3s集群

根據Traefik文檔的建議，當Traefik部署到Kubernetes中時，它將讀取環境變量KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT或KUBECONFIG來構造端點。

在/var/run/secrets/kubernetes.io/serviceaccount/token中查找訪問token，而SSL CA證書將在/var/run/secrets/kubernetes.io/serviceaccount/ca.crt.中查找。當部署到Kubernetes內部時，兩者都會自動提供掛載。

當無法找到環境變量時，Traefik會嘗試使用external-cluster客戶端連接到Kubernetes API server。這一情況下，需要設置endpoint。具體來說，可以將其設置為kubectl代理使用的URL，以使用相關的kubeconfig授予的身份驗證和授權連接到Kubernetes集群。

Traefik 2可以使用任何受支持的配置類型來靜態配置-toml、yaml或命令行交換。

[providers.kubernetesCRD]
  endpoint = "http://localhost:8080"
  token = "mytoken"

providers:
  kubernetesCRD:
    endpoint = "http://localhost:8080"
    token = "mytoken"
    # ...

--providers.kubernetescrd.endpoint=http://localhost:8080 
--providers.kubernetescrd.token=mytoken

第一次運行時，如果你在外部有Traefik，很有可能沒有traefik-ingress-controller訪問token來指定mytoken。那麼，你需要執行以下命令：

# Check all possible clusters, as your .KUBECONFIG may have multiple contexts:
kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'

# Output kind of
# Alias tip: k config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
# Cluster name  Server
# default  https://127.0.0.1:6443

# You are interested in: "default", if you did not name it differently

# Select name of cluster you want to interact with from above output:
export CLUSTER_NAME="default"

# Point to the API server referring the cluster name
export APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
# usually https://127.0.0.1:6443

# Gets the token value
export TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='traefik-ingress-controller')].data.token}" --namespace kube-system|base64 --decode)

# Explore the API with TOKEN

如果成功了，你應該收到以下響應：

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.3.100:6443"
    }
  ]

以及一些事實，如token：

eyJhbGciOiJSUzI1NiIsImtpZCI6IjBUeTQyNm5nakVWbW5PaTRRbDhucGlPeWhlTHhxTXZjUDJsRmNacURjVnMifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJ0cmFlZmlrLWluZ3Jlc3MtY29udHJvbGxlci10b2tlbi12emM3diIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJ0cmFlZmlrLWluZ3Jlc3MtY29udHJvbGxlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImQ5NTc3ZTkxLTdlNjQtNGMwNi1iZDgyLWNkZTk0OWM4MTI1MSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlLXN5c3RlbTp0cmFlZmlrLWluZ3Jlc3MtY29udHJvbGxlciJ9.Mk8EBS4soO8uX-uSnV3o4qZKR6Iw6bgeSmPhHbJ2fjuqFgLnLh4ggxa-N9AqmCsEWiYjSi5oKAu986UEC-_kGQh3xaCYsUwlkM8147fsnwCbomSeGIct14JztVL9F8JwoDH6T0BOEjn-J9uY8-fUKYL_Y7uTrilhFapuILPsj_bFfgIeOOapRD0XshKBQV9Qzg8URxyQyfzl68ilm1Q13h3jLj8CFE2RlgEUFk8TqYH4T4fhfpvV-gNdmKJGODsJDI1hOuWUtBaH_ce9w6woC9K88O3FLKVi7fbvlDFrFoJ2iVZbrRALPjoFN92VA7a6R3pXUbKebTI3aUJiXyfXRQ

根據上次響應的API server的外部地址：https://192.168.3.100:6443

同樣，提供的token中沒有任何特殊之處：這是JWT的token，你可以使用https://jwt.io/#debugger-io，檢查它的內容。

{
  "alg": "RS256",
  "kid": "0Ty426ngjEVmnOi4Ql8npiOyheLxqMvcP2lFcZqDcVs"
}
{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "kube-system",
  "kubernetes.io/serviceaccount/secret.name": "traefik-ingress-controller-token-vzc7v",
  "kubernetes.io/serviceaccount/service-account.name": "traefik-ingress-controller",
  "kubernetes.io/serviceaccount/service-account.uid": "d9577e91-7e64-4c06-bd82-cde949c81251",
  "sub": "system:serviceaccount:kube-system:traefik-ingress-controller"
}

正確的配置非常重要，因此請確保對APISERVER的兩個調用均返回合理的響應。

export APISERVER=YOURAPISERVER
export TOKEN=YOURTOKEN

curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

curl -X GET $APISERVER/api/v1/endpoints --header "Authorization: Bearer $TOKEN" --insecure

創建其他訪問token

控制器循環確保每個服務賬戶都有一個帶有API token的secret，可以像我們之前那樣被發現。

此外，你還可以為一個服務賬戶創建額外的token，創建一個ServiceAccountToken類型的secret，併為服務賬戶添加一個註釋，控制器會用生成的token來更新它。

---
apiVersion: v1
kind: Secret
namespace: kube-system
metadata:
  name: traefik-manual-token
  annotations:
    kubernetes.io/service-account.name: traefik-ingress-controller
type: kubernetes.io/service-account-token

# Any tokens for non-existent service accounts will be cleaned up by the token controller.

# kubectl describe secrets/traefik-manual-token

用以下命令創建：

kubectl create -f ./traefik-service-account-secret.yaml
kubectl describe secret traefik-manual-token

刪除/無效：

kubectl delete secret traefik-manual-token

對外部traefik 2的更改構成定義

我們需要在文章開頭給出的鏈接中獲得的traefik2配置進行哪些更改？

https://github.com/Voronenko/traefik2-compose-template

a） 我們在新文件夾kubernetes_data中存儲ca.crt文件，該文件用於驗證對Kubernetes授權的調用。這是可以在kubeconfig文件的clusters-> cluster-> certificate-authority-data下找到的證書。

該volume將映射在/var/run/secrets/kubernetes.io/serviceaccount下以獲取官方Traefik 2鏡像

volumes:
    ...
      - ./kubernetes_data:/var/run/secrets/kubernetes.io/serviceaccount

b） 調整Traefik 2 kubernetescrd後端以提供3個參數：endpoint、證書路徑和token。請注意，作為外部Traefik作為docker容器，你需要指定正確的endpoint地址，並確保以安全的方式進行。

  - "--providers.kubernetescrd=true"
      - "--providers.kubernetescrd.endpoint=https://192.168.3.100:6443"
      - "--providers.kubernetescrd.certauthfilepath=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
      - "--providers.kubernetescrd.token=YOURTOKENWITHOUTANYQUOTES

如果你都執行正確了，那麼你現在應該在Traefik UI上看到了一些希望。如果你沒有看到traefik，或者在運行Traefik時有問題，你可以查看之後的故障排除部分。

現在是時候通過Trafik 2暴露一些Kubernetes服務了，以確保Traefik 2能夠作為ingress工作。讓我們來看經典案例whoami服務，whoami-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: whoami

spec:
  ports:
    - protocol: TCP
      name: web
      port: 80
  selector:
    app: whoami

---
kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: default
  name: whoami
  labels:
    app: whoami

spec:
  replicas: 2
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: containous/whoami
          ports:
            - name: web
              containerPort: 80

並且以http或https的方式暴露它，whoami.k.voronenko.net全限定域名下的whoami-ingress-route.yaml。

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: ingressroute-notls
  namespace: default
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`whoami.k.voronenko.net`)
      kind: Rule
      services:
        - name: whoami
          port: 80

---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: ingressroute-tls
  namespace: default
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`whoami.k.voronenko.net`)
      kind: Rule
      services:
        - name: whoami
          port: 80
  tls:
    certResolver: default

然後應用它：

kubectl apply -f whoami-service.yaml
  kubectl apply -f whoami-ingress-route.yaml

應用后，你應該會在Traefik dashboard上看到一些希望，即KubernetesCRD後端。

正如你所看到的，Traefik已經檢測到我們的K3s Kubernetes集群上運行的新工作負載，而且它與我們在同一個盒子上的經典Docker工作負載（如portainer）很好地共存。

讓我們檢查一下Traefik 2是否將Traefik路由到了我們的Kubernetes工作負載：如你所見，你可以在http和https endpoint上成功地接觸到whoami工作負載，瀏覽器接受你的證書為可信任的“綠標籤”。

我們的目標達到了！我們在本地筆記本上配置了Traefik 2。Traefik 2將你的docker或Kubernetes工作流暴露在http或https endpoint上。帶可選的 letsencrypt 的 Traefik 2 將負責 https。

故障排查

正如你所知，在配置過程可能存在多個問題，你可以考慮使用一些分析工具，如：

https://github.com/Voronenko/dotfiles/blob/master/Makefile#L185

我特別建議：

a） VMWare octant：這是一個基於Web的功能強大的Kubernetes dashboard，你可以在上面使用你的kubeconfig

b） Rakess：這是一個獨立工具也是一個kubectl插件，用於显示Kubernetes服務器資源的訪問矩陣（https://github.com/corneliusweig/rakkess）

檢查系統賬戶的憑據

rakkess --sa kube-system:traefik-ingress-controller

c） kubectl

檢查哪些角色與服務賬戶相關聯

kubectl get clusterrolebindings -o json | jq -r '
  .items[] |
  select(
    .subjects // [] | .[] |
    [.kind,.namespace,.name] == ["ServiceAccount","kube-system","traefik-ingress-controller"]
  ) |
  .metadata.name'

d） Traefik 文檔：例如kubernetescrd後端提供了更多配置開關的方式。

--providers.kubernetescrd  (Default: "false")
        Enable Kubernetes backend with default settings.
    --providers.kubernetescrd.certauthfilepath  (Default: "")
        Kubernetes certificate authority file path (not needed for in-cluster client).
    --providers.kubernetescrd.disablepasshostheaders  (Default: "false")
        Kubernetes disable PassHost Headers.
    --providers.kubernetescrd.endpoint  (Default: "")
        Kubernetes server endpoint (required for external cluster client).
    --providers.kubernetescrd.ingressclass  (Default: "")
        Value of kubernetes.io/ingress.class annotation to watch for.
    --providers.kubernetescrd.labelselector  (Default: "")
        Kubernetes label selector to use.
    --providers.kubernetescrd.namespaces  (Default: "")
        Kubernetes namespaces.
    --providers.kubernetescrd.throttleduration  (Default: "0")
        Ingress refresh throttle duration
    --providers.kubernetescrd.token  (Default: "")
        Kubernetes bearer token (not needed for in-cluster client).
    --providers.kubernetesingress  (Default: "false")
        Enable Kubernetes backend with default settings.
    --providers.kubernetesingress.certauthfilepath  (Default: "")
        Kubernetes certificate authority file path (not needed for in-cluster client).
    --providers.kubernetesingress.disablepasshostheaders  (Default: "false")
        Kubernetes disable PassHost Headers.
    --providers.kubernetesingress.endpoint  (Default: "")
        Kubernetes server endpoint (required for external cluster client).
    --providers.kubernetesingress.ingressclass  (Default: "")
        Value of kubernetes.io/ingress.class annotation to watch for.
    --providers.kubernetesingress.ingressendpoint.hostname  (Default: "")
        Hostname used for Kubernetes Ingress endpoints.
    --providers.kubernetesingress.ingressendpoint.ip  (Default: "")
        IP used for Kubernetes Ingress endpoints.
    --providers.kubernetesingress.ingressendpoint.publishedservice  (Default: "")
        Published Kubernetes Service to copy status from.
    --providers.kubernetesingress.labelselector  (Default: "")
        Kubernetes Ingress label selector to use.
    --providers.kubernetesingress.namespaces  (Default: "")
        Kubernetes namespaces.
    --providers.kubernetesingress.throttleduration  (Default: "0")
        Ingress refresh throttle duration
    --providers.kubernetesingress.token  (Default: "")
        Kubernetes bearer token (not needed for in-cluster client).

e） 確保Traefik有足夠的權限可以訪問apiserver endpoint

如果你希望Traefik為你查詢信息：通過在配置中放置一些錯誤的apiserver地址，可以查看訪問的endpoint和查詢順序。有了這些知識和你的Traefik Kubernetes token，你就可以使用Traefik憑證檢查這些endpoint是否可以訪問。

traefik_1    | E0421 12:30:12.624877       1 reflector.go:125] pkg/mod/k8s.io/client-go@v0.0.0-20190718183610-8e956561bbf5/tools/cache/reflector.go:98: Failed to list *v1.Endpoints: Get https://192.168.3.101:6443/api/v1/endpoints?limit=500&resourceVersion=0:
traefik_1    | E0421 12:30:12.625341       1 reflector.go:125] pkg/mod/k8s.io/client-go@v0.0.0-20190718183610-8e956561bbf5/tools/cache/reflector.go:98: Failed to list *v1.Service: Get https://192.168.3.101:6443/api/v1/services?limit=500&resourceVersion=0:
traefik_1    | E0421 12:30:12.625395       1 reflector.go:125] pkg/mod/k8s.io/client-go@v0.0.0-20190718183610-8e956561bbf5/tools/cache/reflector.go:98: Failed to list *v1beta1.Ingress: Get https://192.168.3.101:6443/apis/extensions/v1beta1/ingresses?limit=500&resourceVersion=0:
traefik_1    | E0421 12:30:12.625449       1 reflector.go:125] pkg/mod/k8s.io/client-go@v0.0.0-20190718183610-8e956561bbf5/tools/cache/reflector.go:98: Failed to list *v1alpha1.Middleware: Get https://192.168.3.101:6443/apis/traefik.containo.us/v1alpha1/middlewares?limit=500&resourceVersion=0:
traefik_1    | E0421 12:30:12.625492       1 reflector.go:125] pkg/mod/k8s.io/client-go@v0.0.0-20190718183610-8e956561bbf5/tools/cache/reflector.go:98: Failed to list *v1alpha1.IngressRoute: Get https://192.168.3.101:6443/apis/traefik.containo.us/v1alpha1/ingressroutes?limit=500&resourceVersion=0:
traefik_1    | E0421 12:30:12.625531       1 reflector.go:125] pkg/mod/k8s.io/client-go@v0.0.0-20190718183610-8e956561bbf5/tools/cache/reflector.go:98: Failed to list *v1alpha1.TraefikService: Get https://192.168.3.101:6443/apis/traefik.containo.us/v1alpha1/traefikservices?limit=500&resourceVersion=0:
traefik_1    | E0421 12:30:12.625572       1 reflector.go:125] pkg/mod/k8s.io/client-go@v0.0.0-20190718183610-8e956561bbf5/tools/cache/reflector.go:98: Failed to list *v1alpha1.TLSOption: Get https://192.168.3.101:6443/apis/traefik.containo.us/v1alpha1/tlsoptions?limit=500&resourceVersion=0:
traefik_1    | E0421 12:30:12.625610       1 reflector.go:125] pkg/mod/k8s.io/client-go@v0.0.0-20190718183610-8e956561bbf5/tools/cache/reflector.go:98: Failed to list *v1alpha1.IngressRouteTCP: Get https://192.168.3.101:6443/apis/traefik.containo.us/v1alpha1/ingressroutetcps?limit=500&resourceVersion=0:

f） 記錄K3s本身

安裝腳本將自動檢測你的操作系統是使用systemd還是openrc並啟動服務。使用openrc運行時，將在/var/log/k3s.log中創建日誌。使用systemd運行時，將在/var/log/syslog中創建日誌，並使用journalctl -u k3s查看。

在那裡，你可能會得到一些提示，例如：

кві 21 15:42:44 u18d k3s[612]: E0421 15:42:44.936960     612 authentication.go:104] Unable to authenticate the request due to an error: invalid bearer token

這將為你提供有關K8s Traefik起初使用時出現問題的線索，Enjoy your journey！

相關代碼你可以在以下鏈接中找到：

https://github.com/Voronenko/k3s-mini

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

前言

有些時候我們會發現方法名稱都正確匹配，但就是找不到對應請求接口，所以本文我們來深入了解下何時會出現接口請求404的情況。

匹配控制器Action方法（404）

首先我們創建一個web api應用程序，我們給出如下示例控制器代碼

[ApiController]
[Route("[controller]/[action]")]
public class WeatherController : ControllerBase
{
    [HttpGet]
    string Get()
    {
        return "Hello World";
    }
}

 

當我們進行如上請求時會發現接口請求不到，這是為何呢？細心的你應該可能發現了，對於請求方法是私有，而不是公共的，當我們加上public就可以請求到了接口

[HttpGet("get")]
public string Get()
{
    return "Hello World";
}

匹配控制器Action方法本質

經過如上示例，那麼對於Action方法的到底要滿足怎樣的定義才能夠不至於請求不到呢？接下來我們看看源碼怎麼講。我們找到DefaultApplicationModelProvider類，在此類中有一個OnProvidersExecuting方法用來構建控制器和Action方法模型，當我們構建完畢所有滿足條件的控制器模型后，緊接着勢必會遍歷控制器模型去獲取對應控制器模型下的Action方法，這裏只截取獲取Action方法片段，源碼如下：

foreach (var controllerType in context.ControllerTypes)
{    
    //獲取控制器模型下的Action方法
    foreach (var methodInfo in controllerType.AsType().GetMethods())
    {
        var actionModel = CreateActionModel(controllerType, methodInfo);
        if (actionModel == null)
        {
            continue;
        }

        actionModel.Controller = controllerModel;
        controllerModel.Actions.Add(actionModel);    
    }
}

上述紅色標記則是創建Action模型的重點，我們繼續往下看到底滿足哪些條件才創建Action模型呢？

protected virtual ActionModel CreateActionModel(TypeInfo typeInfo, MethodInfo methodInfo)
{
    if (typeInfo == null)
    {
        throw new ArgumentNullException(nameof(typeInfo));
    }

    if (methodInfo == null)
    {
        throw new ArgumentNullException(nameof(methodInfo));
    }

    if (!IsAction(typeInfo, methodInfo))
    {
        return null;
    }    
    ......    
}

到了這個方法裏面，我們找到了如何確定一個方法為Action方法的源頭，由於該方法有點長，這裏我採用文字敘述來作為判斷邏輯，如下：

protected virtual bool IsAction(TypeInfo typeInfo, MethodInfo methodInfo)
{
    //如果有屬性訪問器（無效）

    //如果有NonAction特性標識無效）

    //如果重寫Equals(Object), GetHashCode()方法（無效）

    //如果實現Dispose方法（無效）

    //如果是靜態方法（無效）

    //如果是抽象方法（無效）

    //如果是構造函數（無效）

    //如果是泛型方法（無效）

    //必須為公共方法
    return methodInfo.IsPublic;
}

如上是從方法定義的角度來過濾而獲取Action方法，除此之外，我們請求方法的名稱還可以自定義，比如通過路由、ActionName特性指定，那麼這二者是否存在優先級呢？比如如下示例：

[ApiController]
[Route("[controller]/[action]")]
public class WeatherController : ControllerBase
{
    [HttpGet]
    [ActionName("get1")]
    public string get()
    {
        var routeValue = HttpContext.Request.RouteValues.FirstOrDefault();

        return routeValue.Value.ToString();
    }
}

我們可以看到此時將以ActionName特性作為方法名稱。所以在上述過濾方法定義后開始構建方法模型，在此之後還會再做一步操作，那就是查找該方法是否通過ActionName特性標識，若存在則以ActionName特性標識給定的名稱作為請求方法名稱，否則以方法定義名稱為準，源碼如下：

var actionModel = new ActionModel(methodInfo, attributes);

AddRange(actionModel.Filters, attributes.OfType<IFilterMetadata>());

var actionName = attributes.OfType<ActionNameAttribute>().FirstOrDefault();
if (actionName?.Name != null)
{
    actionModel.ActionName = actionName.Name;
}
else
{
    actionModel.ActionName = methodInfo.Name;
}

還沒完，若是將路由特性放到Action方法上，如下，此時請求接口應該是weather/get還是weather/get1呢？

[ApiController]
public class WeatherController : ControllerBase
{
    [HttpGet]
    [Route("weather/get")]
    [ActionName("get1")]
    public string get()
    {
        var routeValue = HttpContext.Request.RouteValues.FirstOrDefault();

        return routeValue.Value.ToString();
    }
}

此時若我們以weather/get1請求將出現404，還是以路由特性模板給定為準進行請求，但最終會將路由上Action方法名稱通過ActionName特性上的名稱賦值給Action模型中的ActionName進行覆蓋，源碼如下，所以上述我們得到的action名稱為get1，，當然這麼做沒有任何實際意義。

public static void AddRouteValues(ControllerActionDescriptor actionDescriptor,ControllerModel controller,ActionModel action)
{
    foreach (var kvp in action.RouteValues)
    {
        if (!actionDescriptor.RouteValues.ContainsKey(kvp.Key))
        {
            actionDescriptor.RouteValues.Add(kvp.Key, kvp.Value);
        }
    }

    if (!actionDescriptor.RouteValues.ContainsKey("action"))
    {
        actionDescriptor.RouteValues.Add("action", action.ActionName ?? string.Empty);
    }

    if (!actionDescriptor.RouteValues.ContainsKey("controller"))
    {
        actionDescriptor.RouteValues.Add("controller", controller.ControllerName);
    }
}

總結

本文我們只是單獨針對查找Action方法名稱匹配問題做了進一步的探討，根據源碼分析，對Action方法名稱指定會做3步操作：第一，根據方法定義進行過濾篩選，第二，若方法通過AcionName特性標識則以其所給名稱為準，否則以方法名稱為準，最終賦值給ActionModel上的ActionName屬性，第三，將ActionModel上的ActionName值賦值給路由集合中的鍵Action。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?