重新整理 .net core 實踐篇————閘道器[三十六]

前言

簡單整理一下閘道器。

正文

在介紹閘道器之前，介紹一下BFF，BFF全稱是Backend For Frontend，它負責認證授權，服務聚合，目標是為前端提供服務。

說的通透一點，就是有沒有見過這種服務。

上述就是buff通過代理其他服務來讓前端訪問。這時候就有人說了，這不就是閘道器嗎?

是的，個人理解這本來就屬於一種閘道器。以前閘道器只負責資料協議的轉發，現在變得高階了，功能更多了。

但是如果只負責資料協議的轉發，那麼就有一個專門的認證服務。每次使用者訪問閘道器的時候，閘道器要轉到認證服務去認證，然後才能到後面具體訪問的服務。

這就變得非常麻煩了，故而就把認證授權移到了閘道器中，這樣系統的複雜性就減少了。

那麼什麼聚合服務呢?

上文中服務2和服務3進行了聚合，就是某個服務呼叫了服務2和服務3的介面實現了新的介面，暴露出去了。

同樣，如果服務2和服務3的聚合的介面比較少，且改動性比較少的情況下，也可以直接放到閘道器中，這樣避免系統複雜性。

其實現實中很多東西沒有必要全部分開，一般是考慮到安全性和穩定性，安全性沒得說，必須的東西，穩定性就是改動該服務後影響的服務節點是多少，如果是高頻改動，那麼即使是一個介面也要獨立出去。

像下面的，因為如果有不同領域的應用，那麼最好分開來，因為一個閘道器的改動會影響到其他不同領域的應用。

然後這裡有一個詳細的介紹演化的:https://blog.csdn.net/yang75108/article/details/86987404.

那麼來看一下.net core如何打造閘道器吧。

新增Ocelot
新增配置檔案 ocelot.json
新增配置讀取程式碼
註冊Ocelot 服務
註冊Ocelot 中介軟體

可以先看下文件哈。https://github.com/ThreeMammals/Ocelot

這裡就演示一下getStart。因為如果演示覆雜的，不一定用的上，而且整理的混亂，有需求才有實踐。千萬級之所以是千萬級應用，是因為使用者千萬級。

首先安裝好Ocelot。

新增服務:

services.AddOcelot(Configuration);

註冊中介軟體:

 app.UseOcelot().Wait();

app.UseOcelot().Wait(); 應該放在中介軟體的最後，為什麼呢？

因為閘道器內可能有一些其他api，比如說認證授權的，那麼讓那些api先生效，最後才執行到Ocelot閘道器處理部分。

  "ReRoutes": [
    {
      "DownstreamPathTemplate": "/api/order/get",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 9001
        }
      ],
      "UpStreamPathTemplate": "/api/order/get",
      "UpstreamHttpMethod": [ "Get" ]
    }
  ],
  "GlobalConfiguration": {
    "BaseUrl": "http://localhost:5000"
  },

然後在9001中加入請求:

[HttpGet("Get")]
public async Task<string> Get()
{
	return "我是一個內部請求.";
}

log如下:

我們可以直接通過配置來實現閘道器，當然這是大部分，這些看文件就好，有些需要做其他處理的，那麼就可以自己在閘道器中寫api了。

結

下一節在閘道器中實現JWT來完成身份認證和授權。後面系列中，本系列50餘節後，因為涉及到docker和k8s，故而整理了一下k8s的東西，共40餘節，因為部落格園一天只能放一篇，故而持續放出。

重新整理 .net core 實踐篇————閘道器[三十六]

前言

正文

結

相關文章