前言
簡單整理一下閘道器。
正文
在介紹閘道器之前,介紹一下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餘節,因為部落格園一天只能放一篇,故而持續放出。