Nginx在運維領域中的應用是什么

這篇文章主要介紹“Nginx在運維領域中的應用是什么”，在日常操作中，相信很多人在Nginx在運維領域中的應用是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Nginx在運維領域中的應用是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

關于 Nginx

Nginx 已誕生十余年，其作為一款開源的 Web 服務器軟件，因其具有性能穩定、高并發、低內存耗用、高性能的處理能力等特點，被廣泛應用到國內外各互聯網廠商的實際生產架構中。其主要有如下場景應用：

• Web 服務應用，可實現靜態資源、PHP、Python 等網站的架設

• 代理負載服務，支持 TCP/UDP、HTTP、HTTP/2、gRPC、FastCGI、SCGI、uWSGI 等協議的轉發處理，并實現了相應通信協議的請求解析、長連接、代理轉發、負載均衡、會話保持等互聯網架構中常見的應用功能

• 緩存應用，基于其代理功能，實現正向或反向代理緩存功能

• API 網關應用，其提供了包括身份認證、路由轉發、更基于支持 Lua 語言腳本模塊擴展的可編程能力，使其可用于各種復雜環境的路由處理

Nginx 基于事件驅動架構，具有可支持數百萬級別并發請求的處理能力，其通常被用于技術架構中的訪問入口。近幾年云計算、微服務、服務中臺等架構及 DevOps 標準的快速發展，統一入口、智能路由、有效解耦、基礎設施拆分等架構需求更使得 Nginx 被廣泛應用其中。

Nginx 在 DevOps 中的應用

DevOps 已成為當前最流行的研發管理標準，其倡導的云計算、微服務曾被無數運維從業者視為洪水猛獸，認為是取代了運維的工作。然而當我們真正的理解云計算及微服務的架構時，也應深刻的認識到，這不是搶飯碗而是主動投喂。DevOps 標準也正在驅動我們運維工作者能更深入的參與到開發架構中，并與研發達成交織共存的狀態。在我看來，這個紐帶就是 Nginx。

1、業務架構中的應用

互聯網產品的開發過程，都是先做一個當前需求的版本，然后再根據不斷變更的需求，添加新的功能。這是非常符合現實的邏輯，但隨著技術的迭代及業務需求的增加，也會給我們的工作帶來諸多的挑戰。比如，在某一功能比較少的時候，會由一個項目組去開發，由于業務的不斷的發展，就會逐漸擴大到一個部門或事業部的人去共同協作開發。此時，原有的單體服務，就會面臨因業務部門調整或業務產品的變化而進行拆分。

2015年我就遇到過這樣的問題，商戶服務曾是一個團隊開發的，但由于業務部門拆分，就提出了部分分類商戶獨立開發的需求，如果拆分由開發完成，則會面臨技術架構、技術棧遷移、業務開發成本增加等多方面的問題。基于實施的便捷性，所以我們運維就提供了一個基于 Nginx 實現動態路由的平滑拆分方案。訪問架構如下所示：

該服務的URL只有域名和商戶標識碼，根據這個特點，我們設計了一個由 Nginx + Lua + Redis 構成的動態路由架構， 由 Nginx 做入口動態路由。為避免阻塞，所以我們本著最少路由判斷邏輯的原則，將所有的商戶標識碼都以 Key 的形式存儲在 Redis，每個 key 對應的 value 則是相應的被代理服務器組標識，當用戶的訪問進入 Nginx 后，由 lua 腳本快速的從 redis 中讀取到對應的標識，并將用戶的訪問，路由到對應標識的被代理服務器組中。

開發同事開發了一個商戶代碼管理小工具，可以實現商戶標識碼的動態管理。這樣我們就用很短的時間，將單一商戶服務的代碼按照業務的維度拆分成了商戶、酒店、旅游、電影等多個服務，開發可以先將代碼復制多套，再根據各自開發的進度進行逐商戶或整體的進行替換。該方案在很短的時間內實現了服務拆分工作的實施，并為開發團隊為日后商戶服務的開發提供了更多的可能。

總之，無論是 Open API 、微服務亦或是中臺架構，Nginx 總可以通過其強大的功能，為開發減負并實現架構變化的平滑過渡。通過 Nginx 做路由及數據處理可以靈活的解決開發架構多變的問題，并以不變應萬變的能力，滿足不同階段開發架構的需求。

2、應急保障中的應用

在運維保障工作中，RTO（Recovery Time Objective，恢復時間目標）和 RPO（Recovery Point Objective，恢復點目標）是衡量運維保障工作的一個重要指標。RTO 指的是從業務故障發生到整個業務系統恢復所需的最大時長。而 RPO 則是指可能丟失數據的最大時長。這兩個指標，都對運維架構的災備、應急切換能力提出了嚴峻的挑戰。

目前流行的做法是多活架構，但在實際實施中，多活架構投入成本高、實施周期長、對已有的技術架構變更的難度較大，且后期投入的維護工作也非常巨大。此時可以利用Nginx 設計一個動態降級的方案，對小規模且開發架構技術能力較低時期的應急保障工作起到有效的補充。該方案整體投入小，即可以快速實施落地，又可以在發生故障時實快速切換，并記錄故障期間的用戶變更數據的請求，最大化的避免數據的丟失。方案設計如下：

• 所有的靜態資源交由 CDN 廠商提供訪問服務

• 降級集群異地機房部署

• 正常訪問時，Nginx 負載實時同步 GET 請求及響應結果到降級集群，降級集群的Nginx 將同步的數據處理后，存儲到 Redis 集群中

• 當業務服務發生故障時，按照故障情況通過 DNS 或 Nginx 負載將用戶訪問切換到降級集群中

• 業務服務恢復后，通過 Nginx 負載逐步將用戶訪問切回

• 通過專用工具，將記錄的 POST 數據中變更的數據恢復到數據庫中

該方案只是個探討模型，在實際實施中仍有諸多問題需要去考慮，例如：

• GET 方法的 URL 最小取值，以避免重復數據占用更多的存儲空間

• 登錄用戶的處理及 GET 方法請求的個性化問題

• POST 方法數據與用戶身份的綁定

• POST 記錄數據的恢復準確性設計

• 訪問切換的監控

• 前端用戶的提示信息

3、運維的數據化運營

Nginx 通常被置于服務器訪問的入口，其訪問日志可以全局的記錄用戶訪問的來源、響應時間、行為熱點等數據，通過對訪問日志的分析，可以清晰的了解用戶來源、行為習慣及自身服務器性能等情況。借助 ELK 的高性能處理能力，可以實時的將數據分析結果展現給服務器的維護人員及應用的開發人員，進而不斷提高業務的可用性及產品的用戶體驗。

對 Nginx 的日志可以從安全、性能、可用性及訪問統計4個方面進行分類處理。安全方面的可以即時記錄訪問者IP，根據現階段的實際情況進行人工或自動的屏蔽。性能方面可以結合基礎資源監控分析原因并作出提前預判。可用性中若是業務設計方面的則可及時反饋給產品，以做出更友好的提示信息。訪問統計方面的則可提供給相應的部門，進行進一步分析處理。運維的工作不僅是響應外部的需求，通過 Nginx 提供的強大功能，也可以主動的參與到企業的數據化運營工作中。

4、微服務中的 Nginx

微服務是 DevOps 水平的一個重要標志，微服務架構中的服務網格(Service Mesh)及serverless 的架構設計，其最大的理念就是將可復用的、基礎的非業務功能從業務開發中剝離出來，例如服務發現、端到端認證、訪問追蹤、組件依賴等功能。在向服務網格遷移的過程中，Nginx 更是起到了重要的作用。

• 路由網格架構 ，這個架構是向服務網格過渡的初級架構，其無需對原有的單體應用和新的微服務應用做什么改造，可以很輕易的遷移進來，并為更復雜的改造積累經驗。

• Sidecar 代理/Fabric 模型，該模型應用程序和代理被被放在了POD里，可以對應用程序的流量做更細粒度的控制。在該階段可以自己開發控制平面，也可以選擇直接切換到istio平臺。

到此，關于“Nginx在運維領域中的應用是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！