前言

呵呵 最近出現(xiàn)了這樣的一個(gè)問題, 我們有多個(gè)前端服務(wù), 分別連接了對(duì)應(yīng)的后端服務(wù), 前端A -> 后端A, 前端B -> 后端B?

但是 最近的時(shí)候 卻會(huì)出現(xiàn)一種情況就是, 有些時(shí)候 前端A 連接到了 后端B, 前端B 連接到了 后端A??

我們 前端服務(wù)使用 nginx 提供前端 html, js, css 的服務(wù), 對(duì)于前端業(yè)務(wù)中的請(qǐng)求, 也是使用的 nginx 來代理到真實(shí)的后端服務(wù)上面, 后端服務(wù) 我們就假定為普通的 tomcat 服務(wù)器, 前后端服務(wù)都是部署在 docker 上面

然后 就給人造成一種 數(shù)據(jù)跑掉了的錯(cuò)覺, 呵呵 也是引起了我們同事 使用系統(tǒng)的很大的疑惑, 然后 搞出了一些 "我的數(shù)據(jù) 再和我做迷藏", "我的數(shù)據(jù)從成都跑到北京去了" 之類的笑話?

然后 你一去檢查服務(wù)的配置, 等等, 你發(fā)現(xiàn) 前端配置, 后端配置 都沒得問題, 我最開始以為是 nginx 運(yùn)行時(shí)加載的配置 被修改了?, 加載在內(nèi)存的配置 和 實(shí)際的配置文件不一致?, 但是 實(shí)際 看了一下, 發(fā)現(xiàn)配置是 沒有問題的?

對(duì)于這個(gè)問題 還是很好奇的, 當(dāng)然 后面也做了一些 探索, 也有一些 初步的推斷, 然后 今天的時(shí)候[1114]?嘗試在本地復(fù)現(xiàn)一下這個(gè)問題, 也發(fā)現(xiàn)了一些 和自己開始的判斷 不一樣的一些地方?

let's go?

問題特征

這個(gè)問題的出現(xiàn) 和 消失有這樣的一些特征?

1. 所有的前端, 后端配置都是正常的, 但是 實(shí)際接口返回的數(shù)據(jù) 就是不一樣?

2. 出現(xiàn)了這個(gè)問題之后, 重啟一下 前端服務(wù) 之后, 前端服務(wù)就正常了?

3. 一般是后端代碼更新了之后, jenkins 自動(dòng)發(fā)版之后 會(huì)出現(xiàn)這個(gè)問題?

前端容器中 也缺少 ping 之類的網(wǎng)絡(luò)工具, 造成排查的時(shí)候 還是存在一些 障礙?

問題inspect

最開始 想要處理這個(gè)問題, 我得看一下 nginx 最終吧服務(wù)轉(zhuǎn)發(fā)到了 那一臺(tái)后端服務(wù)器?

因此, 在 nginx 配置的地方, 增加了一個(gè)?add_header backendIP $upstream_addr; 來獲取實(shí)際處理 后端請(qǐng)求的服務(wù)的信息?

然后 后來一次?是因?yàn)?后臺(tái)發(fā)版了, 之后 這個(gè)問題就復(fù)現(xiàn)了, 這也使我觀察到了 上面的 特征3?

然后 看一下?backendIP, 然后 再 inspect 對(duì)應(yīng)的額后端服務(wù), 發(fā)現(xiàn)后端服務(wù)的 ip 和這個(gè)?backendIP 對(duì)不上 ???

所以 問題的大致原因 也就出現(xiàn)了, 發(fā)版之后 后端服務(wù)的 ip 變化了, 然后 前端服務(wù)里面訪問的 ip 還是之前的 ip?

當(dāng)然 最開始, 我以為是 前端服務(wù)里面的 dns 緩存之類的, 直到今天 測(cè)試了一下, 發(fā)現(xiàn) 似乎是其他的原因?

接下來 我們便來以一個(gè) demo 實(shí)際的走一下 這個(gè)流程?

構(gòu)造問題

首先 我們需要 一個(gè)前端服務(wù), 和 兩個(gè)后端服務(wù), 前端服務(wù)A 只連接 其中的一個(gè) 后端服務(wù)A?

然后 之后我們同時(shí)重啟 兩個(gè)后端服務(wù), 然后 再來訪問這個(gè) 前端服務(wù)A, 可能會(huì)存在 前端服務(wù)A 訪問到了 后端服務(wù)B 的情況?

1. 看下后端服務(wù)?

一個(gè)簡單的 SpringBoot 項(xiàng)目, 其中開放了一些簡單的接口, 比如這里的 /hello/context, 可以輸出 當(dāng)前應(yīng)用名稱 和 一些上下文的信息?

2. 部署后端服務(wù)?

首先來部署兩個(gè)后端服務(wù), docker-compose 大致如下?

兩個(gè)服務(wù)使用 同一個(gè)鏡像, 只是傳遞的環(huán)境變量的 APP_NAME 有一些區(qū)別, 因此 訪問 /hello/context 的時(shí)候 appName 的輸出會(huì)有一些區(qū)別?

另外使用同一個(gè)鏡像的原因在于, 更加簡單的構(gòu)造 兩個(gè)鏡像同時(shí)重啟?

version: "2"networks:fuzzy:external: trueservices:app0:container_name: app0image: app0:0.0.1ports:- "7901:7901"environment:APP_NAME: app0networks:- fuzzyapp1:container_name: app1image: app0:0.0.1ports:- "7902:7901"environment:APP_NAME: app1networks:- fuzzy

服務(wù)起起來之后 測(cè)試一下, 這里把服務(wù)映射到了宿主機(jī)的端口, 根據(jù)這個(gè)來測(cè)試一下?

訪問情況如下, 可以看到是 符合我們的預(yù)期的, 不是很意外?

http://localhost:7901/hello/context

http://localhost:7902/hello/context

3. 部署前端服務(wù)?

前端服務(wù)我們這里 為了簡單, 是直接使用的 nginx 鏡像, 沒有業(yè)務(wù), 連接 app0 的服務(wù)?

前端服務(wù)的 docker-compose 如下?

version: "2"networks:fuzzy:external: trueservices:nginx:container_name: nginximage: nginx:latestports:- "80:80"volumes:- ./data:/etc/nginxnetworks:- fuzzy

nginx 配置大致如下?

可以看到 /hello 開頭的這部分請(qǐng)求, 我們把它 轉(zhuǎn)發(fā)到了 app0 的服務(wù)上面, 使用?add_header backendIP $upstream_addr; 輸出了一下 具體的處理業(yè)務(wù)的后端服務(wù)器的信息??

server {listen       80;listen  [::]:80;server_name  localhost;location / {root   /usr/share/nginx/html;index  index.html index.htm;}location ~ /hello {proxy_pass   http://app0:7901;add_header backendIP $upstream_addr;proxy_set_header SSL-Client-Cert $ssl_client_cert;proxy_set_header name jerry;}#error_page  404              /404.html;# redirect server error pages to the static page /50x.htmlerror_page   500 502 503 504  /50x.html;location = /50x.html {root   /usr/share/nginx/html;}}

4. 正常情況 和 出現(xiàn)問題的情況?

正常的情況?

出現(xiàn)問題?

問題細(xì)節(jié)

正常情況

首先我們看一下 app0, app1, nginx 的 ip 情況?

從下面可以整理出 網(wǎng)路情況如下?

app0	192.168.80.3
app1	192.168.80.2
nginx	192.168.80.4

然后我們來看一下 正常的情況下 處理的后端服務(wù)的情況?

可以看到的是 訪問的是 ip 是 192.168.80.3 對(duì)應(yīng)于上面的 app0?

我們重啟 app0, app1 直到復(fù)現(xiàn)問題

我們可以看到 此時(shí)處理服務(wù)的容器 的ip還是 192.168.80.3?

但是 返回的數(shù)據(jù), 卻已經(jīng)是 app1 應(yīng)該返回的數(shù)據(jù)了?

我們?cè)賮砜匆幌?app0, app1, nginx 的 ip 情況?

從下面可以整理出 網(wǎng)路情況如下?

app0	192.168.80.2
app1	192.168.80.3
nginx	192.168.80.4

可以看到的是 app0 和 app1 的 ip 變了, 兩個(gè)容器的 ip 交換了一下, 但是 前端容器 還是將服務(wù)委托給了 192.168.80.3 的這個(gè)容器, 而不是 app0 這個(gè)服務(wù)?

是前端容器的 dns 的緩存么??

為了 驗(yàn)證這個(gè)問題, 呵呵 可以使用 ping 或者 nslookup 之類的網(wǎng)絡(luò)工具, 但是 在 nginx 容器里面這兩個(gè)都沒得?

我今天 還想了一陣子, 怎么驗(yàn)證這個(gè)問題, 呵呵 curl 有一個(gè) -v, verbose 展示出請(qǐng)求的更詳細(xì)的信息?

curl -v http://app0:7901/hello/context?

從下面的日志信息可以看出, 從 前端服務(wù)的容器中訪問 app0 訪問的是 最新的app0[192.168.80.2], 因此可以排除 容器的 dns緩存的猜測(cè)?

master:nginx jerry$ docker exec -it nginx /bin/sh
# curl -v http://app0:7901/hello/context
* Expire in 0 ms for 6 (transfer 0x55712a1dff50)
* Expire in 1 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 1 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 2 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 2 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 2 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 2 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
* Expire in 0 ms for 1 (transfer 0x55712a1dff50)
*   Trying 192.168.80.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55712a1dff50)
* Connected to app0 (192.168.80.2) port 7901 (#0)
> GET /hello/context HTTP/1.1
> Host: app0:7901
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 135
< Date: Sat, 14 Nov 2020 09:24:12 GMT
< 
* Connection #0 to host app0 left intact
context info as follow!, APP_NAME : app0<br/> headers : {"host":"app0:7901","user-agent":"curl/7.64.0","accept":"*/*"}<br/> params : {}

nginx 的 dns 緩存

nginx -s reload 一下?

# nginx -s reload 
2020/11/14 09:27:13 [notice] 33#33: signal process started

看一下 /hello/context 的情況, 返回的數(shù)據(jù)也是 app0 處理之后返回的數(shù)據(jù), backendIP 也更新成了 192.168.80.2[app0對(duì)應(yīng)的ip]?

所以之前的處理方式 : 重啟前端服務(wù), 實(shí)際上真正解決問題的是 nginx 的重新加載?

完?

參考

nginx查看請(qǐng)求被轉(zhuǎn)發(fā)到哪臺(tái)服務(wù)器