現在越來越多的技術團隊開始嘗試採納微服務架構進行產品開發。而基於微服務架構後後端服務通常而言是動態的,為了簡化前端的呼叫邏輯,通常會引入api gateway作為輕量級閘道器,同時api gateway中也會實現相關的認證邏輯從而簡化內部服務之間相互呼叫的複雜度,這邊文章我們就來聊聊api gateway的那些事。
在微服務架構模式下後端服務的例項數一般是動態的,對於客戶端而言如何發現這些動態改變的服務例項的訪問位址資訊?因此在基於微服務的專案中為了簡化前端的呼叫邏輯,通常會引入api gateway作為輕量級閘道器,同時api gateway中也會實現相關的認證邏輯從而簡化內部服務之間相互呼叫的複雜度。
通常而言多餘不同的客戶端對於顯示時對於資料的需求是不一致的,比如手機端或者web端又或者在低延遲的網路環境或者高延遲的網路環境。
因此為了優化客戶端的使用體驗,api gateway可以對通用性的響應資料進行裁剪以適應不同客戶端的使用需求。同時還可以將多個api呼叫邏輯進行聚合,從而減少客戶端的請求數,優化客戶端使用者體驗
當然我們還可以針對不同的渠道和客戶端提供不同的api gateway,對於該模式的使用由另外乙個大家熟知的方式叫backend for front-end, 在backend for front-end模式當中,我們可以針對不同的客戶端分別建立其bff
對於系統系統而言進行微服務改造通常是由於原有的系統存在或多或少的問題,比如技術債務,**質量,可維護性,可擴充套件性等等。api gateway的模式同樣適用於這一類遺留系統的改造,通過微服務化的改造逐步實現對原有系統中的問題的修復,從而提公升對於原有業務響應力的提公升。通過引入抽象層,逐步使用新的實現替換舊的實現。
spring cloud的zuul元件提供了輕量級閘道器的功能支援,通過定義路由規則可以快速實現乙個輕量級的api閘道器
1234567
891011
1213
1415
zuul:同時除了通過serviceid關聯已經註冊到consul的服務例項以外,我們也可以通過zuul直接定義實現對已有服務的直接整合。ignoredpatterns:
/api/auth
sensitive-headers:
"*"ignorelocalservice:
true
retryable:
false
host:
max-total-connections:
500routes:
service01:
pateh:
/service01/**
serviceid:
service01
stripprefix:
true
thirdpart:
pateh:
/thirdpart/**
url:
這裡我們就不過多介紹zuul的細節,在實際使用中我們會發現直接使用zuul會存在諸多問題,包括:
為了解決以上問題,可以通過在zuul前端部署nginx實現對zuul例項的反向**,同時適當的通過新增cache以及請求壓縮減少對後端zuul例項的壓力。
通過nginx我們可以實現對多例項zuul的請求**,同時通過新增適當的快取以及請求壓縮配置可以提公升前端ui的請求響應時間。這裡需要解決的問題是nginx如何動態發現zuul例項資訊並且將請求**到zuul當中。
consul-template可以幫助我們解決以上問題,consul-template是乙個命令列工具,結合consul實現配置檔案的動態生成並且支援在配置檔案發生變化後觸發使用者自定義命令。
我們使用了如下的dockerfile用於構建我們的nginx服務
1234567
891011
1213
1415
1617
1819
20
from nginx:1.11.10nginx配置模板檔案addconsul-template /usr/local/bin
run mkdir /etc/consul-templates
# 模板檔案
add nginx.tpl /etc/consul-templates/nginx.tpl
env ct_file /etc/consul-templates/nginx.tpl
env nx_file /etc/nginx/conf.d/default.conf # 目標檔案
env service identity # 註冊在consul的服務名
copy dist /usr/share/nginx/html
run mkdir -p /data/cache
cmd /usr/sbin/nginx -c /etc/nginx/nginx.conf \
& consul_template_log=debug \
consul-template -consul-addr=$consul -template "$ct_file:$nx_file:/usr/sbin/nginx -s reload";
1234567
891011
1213
1415
1617
1819
2021
# nginx.tpl其中upstream api_server }
server }:};
}server
127.0
.0.1:9191;}
}server
location /api
}
123456
upstream api_server }server }:};
}server 127.0.0.1:9191;}
}
123
cmd /usr/sbin/nginx -c /etc/nginx/nginx.conf \啟用nginx的gzip可以對伺服器端響應內容進行壓縮從而減少一定的客戶端響應時間& consul_template_log=debug \
consul-template -consul-addr=$consul -template "$ct_file:$nx_file:/usr/sbin/nginx -s reload";
12345
gzip on;快取以及其它靜態資源可以減少對zuul例項的請求量gzip_min_length 1k;
gzip_buffers 4
32k;
gzip_vary on;
1234567
891011
1213
proxy_buffering如果需要通過nginx實現對websocket的**可以新增一下配置on;proxy_cache_valid any 10m;
proxy_cache_path /data/cache levels=1:2 keys_zone=my-cache:8m max_size=1000m inactive=600m;
proxy_temp_path /data/temp;
proxy_buffer_size
4k;proxy_buffers
1008k;
location
~* (images)
1234567
891011
1213
1415
1617
1819
location /sockjs
分布式系統API閘道器原理及選型
什麼是閘道器?兩個獨立的區域網之間通訊的橋梁 或可以理解為外部所有請求都會打在閘道器上,閘道器對請求分發路由等處理,隱藏了內部服務的各種api介面 閘道器作用及功能 1.動態路由 根據請求路由到對應的服務上去,如果服務不可用還會有重試機制 2.負載均衡 多伺服器提供同一種服務,閘道器會從註冊中心拉取...
分布式 分布式鎖
本質是利用redis的setnx 方法的特性來加鎖,setnx 即key不存在則設定key,否則直接返回false,要求在分布式系統中使用同乙個redis服務,以下提供兩種解決方案 1 直接使用redistemplate 這其實並不能完全保證高併發下的安全問題,因為可能在鎖過期之後該執行緒尚未執行完...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位,由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時,併發事務之間互相影響的程度。永續性 d...