背景

當前軟件開發中，絕大部分團隊都已經實現了前后端分離，不過實施的過程中并不總是甜頭，前端和后端的協作過程中總是會遇到讓人頭疼的問題。

比如，前端的同學正在全神貫注的調試著代碼，突然后端把服務停了(測試環境把服務停掉太正常了，最常見的原因就是打包)，接口調不通了，沒辦法，誰讓前端需要用到測試環境的接口取數據呢，這個時候只能停下手中的活，等待后端服務再次啟動，這個過程通常在幾十秒到幾分鐘不等，這就要看后端服務啟動要多久了(我見過最長的服務要啟動200多秒的),一次兩次還好，如果一天之中遇到這種問題十次八次，前端絕對要抓狂。

但是后端的同學可能也很委屈，我們也是在抓緊時間完成任務啊，測試提了一個bug需要趕緊修復，不然功能沒法兒測了；新的需求開發好了，打到測試環境走一下完整流程；各種原因都有可能，總之也不能不動測試環境(也許大公司都有一套比較好的研發流程和工具，可以保證前后端互不影響還能很好的完成工作，但大部分中小公司我相信都可能遇到這種問題)。

‘卑微’的前端同學怎么辦？

前端自己模擬數據，做擋板？就不調后端接口了，自己mock？估計很難，而且自己模擬數據也很費事啊，后端那么多接口，怎么模擬的過來，況且再怎么模擬也還是跟真實數據可能有出入不是！

把環境再分出一套，專門給前端用？好像也不行，這套環境也要維護啊，誰來維護，新的代碼也還是需要不斷的集成到這套新的環境中的，還是逃不開上面的問題。

讓后端在指定的時間打包？你可以試試看后端會不會聽你的話。。。

前端想要個穩定的環境怎么就這么難！

該如何解決？

這個問題，還是要通過技術手段去解決，最好就是后端服務別是單節點的，然后可以有手段感知到我們要用的后端接口服務的狀態，如果服務異常，我請求不去這臺服務器就可以了，然后后端打包的時候，多臺服務器串行打包，保證至少有一臺活著可以提供服務，這樣前后端就又可以愉快的玩耍啦。

理想中的架構

一般架構抽象一下大概就是這個樣子，后端也許會有很多花樣，什么spring-cloud，微服務，SOA等等，總的說來沒太多區別。像我所在的團隊，后端的API服務這一層經常發生變更，下游依賴的服務也經常變更，不過是下游的服務是dubbo組成的，dubbo服務集群本身有狀態管理，所以下游的服務并不會對前端造成影響，主要是API的變更對前端影響大。

在這種情況下，我們給nginx加上服務狀態檢測的能力，再配合jenkins分批串行打包，就可以完美解決前端的問題。

nginx的狀態檢測

nginx 代理+檢測

nginx本身并不直接支持代理的服務的健康狀態檢查，需要依賴外部的一個模塊實現，這個模塊叫

nginx_upstream_check_module

這個模塊來自阿里，模塊已經被集成在阿里的Tengine中，這里順便說一下阿里的Tengine，這個是阿里基于自己的需求定制擴展的nginx，完全兼容nginx，同時又整合了很多阿里自己開發的實用模塊，nginx_upstream_check_module就是其中之一。我們本身有已經安裝好的nginx，所以就只添加這個模塊了。如果想要簡單的辦法，也可以直接安裝tengine。

這個模塊可以通過github下載到，如下是一個使用比較多的地址：

https://github.com/yaoweibin/nginx_upstream_check_module

上面這個倉庫中也有介紹安裝和使用方法，我這里就簡單列一下大致流程：

安裝

# 1. 將倉庫clone下來，放在和nginx源碼目錄同級目錄下
# 2. 進入nginx源碼目錄，給nginx打補丁
patch -p1 < ../nginx_upstream_check_module/check_1.16.1+.patch
# 3. 重新編譯nginx，注意，這里configure后面的參數要和之前安裝的時候一樣
./configure --add-module=../nginx_upstream_check_module/
# 4. 使用./objs/nginx文件 替換現有的nginx文件

配置nginx的健康檢查

upstream service-dev {
server 192.168.3.151:8080;
server 192.168.3.152:8080;
check interval=3000 rise=2 fall=2 timeout=1000 type=tcp;
}

## 然后在server下的location中可以使用上面的upstream，這其實是nginx負載均衡配置的方法。

這里的check就是我們添加的模塊中提供的指令，表示每3秒向后端節點發起一次tcp連接，連續兩次失敗則標記為不可用，再有兩次成功則標記為可用。更多詳細解析可以看上面的github主頁。

配置狀態頁面

在同一個端口下，增加status路徑，可以顯示nginx檢測的狀態頁面，訪問/status 就可以看到

location /status {
check_status;
access_log off;
}

就像下面這樣

狀態檢測的結果

這樣后端和前端各自干活，后臺隨便打包，前端不會受到任何影響。

既然都看到這里了，不妨點個贊再走唄。

總結

以上是生活随笔為你收集整理的nginx怎么用_后端服务老是重启，前端该如何拯救自己？nginx的妙用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。