|
關(guān)于 NginxNginx 已誕生十余年，其作為一款開源的 Web 服務(wù)器軟件，因其具有性能穩(wěn)定、高并發(fā)、低內(nèi)存耗用、高性能的處理能力等特點，被廣泛應(yīng)用到國內(nèi)外各互聯(lián)網(wǎng)廠商的實際生產(chǎn)架構(gòu)中。其主要有如下場景應(yīng)用：- Web 服務(wù)應(yīng)用，可實現(xiàn)靜態(tài)資源、PHP、Python 等網(wǎng)站的架設(shè)
- 代理負載服務(wù)，支持 TCP/UDP、HTTP、HTTP/2、gRPC、FastCGI、SCGI、uWSGI 等協(xié)議的轉(zhuǎn)發(fā)處理，并實現(xiàn)了相應(yīng)通信協(xié)議的請求解析、長連接、代理轉(zhuǎn)發(fā)、負載均衡、會話保持等互聯(lián)網(wǎng)架構(gòu)中常見的應(yīng)用功能
- 緩存應(yīng)用，基于其代理功能，實現(xiàn)正向或反向代理緩存功能
- API 網(wǎng)關(guān)應(yīng)用，其提供了包括身份認證、路由轉(zhuǎn)發(fā)、更基于支持 Lua 語言腳本模塊擴展的可編程能力，使其可用于各種復(fù)雜環(huán)境的路由處理
Nginx 基于事件驅(qū)動架構(gòu)，具有可支持數(shù)百萬級別并發(fā)請求的處理能力，其通常被用于技術(shù)架構(gòu)中的訪問入口。近幾年云計算、微服務(wù)、服務(wù)中臺等架構(gòu)及 DevOps 標準的快速發(fā)展，統(tǒng)一入口、智能路由、有效解耦、基礎(chǔ)設(shè)施拆分等架構(gòu)需求更使得 Nginx 被廣泛應(yīng)用其中。Nginx 在 DevOps 中的應(yīng)用DevOps 已成為當(dāng)前最流行的研發(fā)管理標準，其倡導(dǎo)的云計算、微服務(wù)曾被無數(shù)運維從業(yè)者視為洪水猛獸，認為是取代了運維的工作。然而當(dāng)我們真正的理解云計算及微服務(wù)的架構(gòu)時，也應(yīng)深刻的認識到，這不是搶飯碗而是主動投喂。DevOps 標準也正在驅(qū)動我們運維工作者能更深入的參與到開發(fā)架構(gòu)中，并與研發(fā)達成交織共存的狀態(tài)。在我看來，這個紐帶就是 Nginx。1、業(yè)務(wù)架構(gòu)中的應(yīng)用互聯(lián)網(wǎng)產(chǎn)品的開發(fā)過程，都是先做一個當(dāng)前需求的版本，然后再根據(jù)不斷變更的需求，添加新的功能。這是非常符合現(xiàn)實的邏輯，但隨著技術(shù)的迭代及業(yè)務(wù)需求的增加，也會給我們的工作帶來諸多的挑戰(zhàn)。比如，在某一功能比較少的時候，會由一個項目組去開發(fā)，由于業(yè)務(wù)的不斷的發(fā)展，就會逐漸擴大到一個部門或事業(yè)部的人去共同協(xié)作開發(fā)。此時，原有的單體服務(wù)，就會面臨因業(yè)務(wù)部門調(diào)整或業(yè)務(wù)產(chǎn)品的變化而進行拆分。2015年我就遇到過這樣的問題，商戶服務(wù)曾是一個團隊開發(fā)的，但由于業(yè)務(wù)部門拆分，就提出了部分分類商戶獨立開發(fā)的需求，如果拆分由開發(fā)完成，則會面臨技術(shù)架構(gòu)、技術(shù)棧遷移、業(yè)務(wù)開發(fā)成本增加等多方面的問題?；趯嵤┑谋憬菪?，所以我們運維就提供了一個基于 Nginx 實現(xiàn)動態(tài)路由的平滑拆分方案。訪問架構(gòu)如下所示：該服務(wù)的URL只有域名和商戶標識碼(http://www./shop/111xxxxx)，根據(jù)這個特點，我們設(shè)計了一個由 Nginx + Lua + Redis 構(gòu)成的動態(tài)路由架構(gòu)， 由 Nginx 做入口動態(tài)路由。為避免阻塞，所以我們本著最少路由判斷邏輯的原則，將所有的商戶標識碼都以 Key 的形式存儲在 Redis，每個 key 對應(yīng)的 value 則是相應(yīng)的被代理服務(wù)器組標識，當(dāng)用戶的訪問進入 Nginx 后，由 lua 腳本快速的從 redis 中讀取到對應(yīng)的標識，并將用戶的訪問，路由到對應(yīng)標識的被代理服務(wù)器組中。開發(fā)同事開發(fā)了一個商戶代碼管理小工具，可以實現(xiàn)商戶標識碼的動態(tài)管理。這樣我們就用很短的時間，將單一商戶服務(wù)的代碼按照業(yè)務(wù)的維度拆分成了商戶、酒店、旅游、電影等多個服務(wù)，開發(fā)可以先將代碼復(fù)制多套，再根據(jù)各自開發(fā)的進度進行逐商戶或整體的進行替換。該方案在很短的時間內(nèi)實現(xiàn)了服務(wù)拆分工作的實施，并為開發(fā)團隊為日后商戶服務(wù)的開發(fā)提供了更多的可能。總之，無論是 Open API 、微服務(wù)亦或是中臺架構(gòu)，Nginx 總可以通過其強大的功能，為開發(fā)減負并實現(xiàn)架構(gòu)變化的平滑過渡。通過 Nginx 做路由及數(shù)據(jù)處理可以靈活的解決開發(fā)架構(gòu)多變的問題，并以不變應(yīng)萬變的能力，滿足不同階段開發(fā)架構(gòu)的需求。2、應(yīng)急保障中的應(yīng)用在運維保障工作中，RTO（Recovery Time Objective，恢復(fù)時間目標）和 RPO（Recovery Point Objective，恢復(fù)點目標）是衡量運維保障工作的一個重要指標。RTO 指的是從業(yè)務(wù)故障發(fā)生到整個業(yè)務(wù)系統(tǒng)恢復(fù)所需的最大時長。而 RPO 則是指可能丟失數(shù)據(jù)的最大時長。這兩個指標，都對運維架構(gòu)的災(zāi)備、應(yīng)急切換能力提出了嚴峻的挑戰(zhàn)。目前流行的做法是多活架構(gòu)，但在實際實施中，多活架構(gòu)投入成本高、實施周期長、對已有的技術(shù)架構(gòu)變更的難度較大，且后期投入的維護工作也非常巨大。此時可以利用Nginx 設(shè)計一個動態(tài)降級的方案，對小規(guī)模且開發(fā)架構(gòu)技術(shù)能力較低時期的應(yīng)急保障工作起到有效的補充。該方案整體投入小，即可以快速實施落地，又可以在發(fā)生故障時實快速切換，并記錄故障期間的用戶變更數(shù)據(jù)的請求，最大化的避免數(shù)據(jù)的丟失。方案設(shè)計如下：- 所有的靜態(tài)資源交由 CDN 廠商提供訪問服務(wù)
- 正常訪問時，Nginx 負載實時同步 GET 請求及響應(yīng)結(jié)果到降級集群，降級集群的Nginx 將同步的數(shù)據(jù)處理后，存儲到 Redis 集群中
- 當(dāng)業(yè)務(wù)服務(wù)發(fā)生故障時，按照故障情況通過 DNS 或 Nginx 負載將用戶訪問切換到降級集群中
- 業(yè)務(wù)服務(wù)恢復(fù)后，通過 Nginx 負載逐步將用戶訪問切回
- 通過專用工具，將記錄的 POST 數(shù)據(jù)中變更的數(shù)據(jù)恢復(fù)到數(shù)據(jù)庫中
該方案只是個探討模型，在實際實施中仍有諸多問題需要去考慮，例如：- GET 方法的 URL 最小取值，以避免重復(fù)數(shù)據(jù)占用更多的存儲空間
- POST 方法數(shù)據(jù)與用戶身份的綁定
- POST 記錄數(shù)據(jù)的恢復(fù)準確性設(shè)計
3、運維的數(shù)據(jù)化運營Nginx 通常被置于服務(wù)器訪問的入口，其訪問日志可以全局的記錄用戶訪問的來源、響應(yīng)時間、行為熱點等數(shù)據(jù)，通過對訪問日志的分析，可以清晰的了解用戶來源、行為習(xí)慣及自身服務(wù)器性能等情況。借助 ELK 的高性能處理能力，可以實時的將數(shù)據(jù)分析結(jié)果展現(xiàn)給服務(wù)器的維護人員及應(yīng)用的開發(fā)人員，進而不斷提高業(yè)務(wù)的可用性及產(chǎn)品的用戶體驗。對 Nginx 的日志可以從安全、性能、可用性及訪問統(tǒng)計4個方面進行分類處理。安全方面的可以即時記錄訪問者IP，根據(jù)現(xiàn)階段的實際情況進行人工或自動的屏蔽。性能方面可以結(jié)合基礎(chǔ)資源監(jiān)控分析原因并作出提前預(yù)判?？捎眯灾腥羰菢I(yè)務(wù)設(shè)計方面的則可及時反饋給產(chǎn)品，以做出更友好的提示信息。訪問統(tǒng)計方面的則可提供給相應(yīng)的部門，進行進一步分析處理。運維的工作不僅是響應(yīng)外部的需求，通過 Nginx 提供的強大功能，也可以主動的參與到企業(yè)的數(shù)據(jù)化運營工作中。 4、微服務(wù)中的 Nginx微服務(wù)是 DevOps 水平的一個重要標志，微服務(wù)架構(gòu)中的服務(wù)網(wǎng)格(Service Mesh)及serverless 的架構(gòu)設(shè)計，其最大的理念就是將可復(fù)用的、基礎(chǔ)的非業(yè)務(wù)功能從業(yè)務(wù)開發(fā)中剝離出來，例如服務(wù)發(fā)現(xiàn)、端到端認證、訪問追蹤、組件依賴等功能。在向服務(wù)網(wǎng)格遷移的過程中，Nginx 更是起到了重要的作用。- 路由網(wǎng)格架構(gòu) ，這個架構(gòu)是向服務(wù)網(wǎng)格過渡的初級架構(gòu)，其無需對原有的單體應(yīng)用和新的微服務(wù)應(yīng)用做什么改造，可以很輕易的遷移進來，并為更復(fù)雜的改造積累經(jīng)驗。
- Sidecar 代理/Fabric 模型，該模型應(yīng)用程序和代理被被放在了POD里，可以對應(yīng)用程序的流量做更細粒度的控制。在該階段可以自己開發(fā)控制平面，也可以選擇直接切換到istio平臺。
寫在最后2019年初，電影《流浪地球》讓我們看到了中國科幻電影的希望，但導(dǎo)演郭帆則反復(fù)強調(diào)，“我們工業(yè)化不足的時候就是靠人肉填的，中國電影工業(yè)化還是處在一個非常早期的階段”。這不禁讓我想到了我從業(yè)的互聯(lián)網(wǎng)行業(yè)，我們其實也一直是在一個非工業(yè)化環(huán)境中勞作著。工業(yè)化，自然是由自動化的“機器體系”來取代人肉的“手工勞動”，其生產(chǎn)過程中的每個階段都必然是標準化、流程化的。當(dāng)我看到由中國信息通信研究院牽頭，聯(lián)合云計算開源產(chǎn)業(yè)聯(lián)盟、高效運維社區(qū)及國內(nèi)多個互聯(lián)網(wǎng)大廠編寫的 DevOps 標準-研發(fā)運營一體化能力成熟度模型，并正式立項國際標準時，不禁尤感自豪，也深深對為推動我國互聯(lián)網(wǎng)行業(yè)工業(yè)化進程努力的精英們深表敬佩。 作為互聯(lián)網(wǎng)從業(yè)人員，也深刻認識到用好開源技術(shù)、推動工作內(nèi)容標準化、流程化也是我們在互聯(lián)網(wǎng)行業(yè)工業(yè)化進程中應(yīng)盡的一份責(zé)任。 關(guān)于作者王小東 ，資深運維專家，有十余年的互聯(lián)網(wǎng)企業(yè)運維和架構(gòu)經(jīng)驗，擅長服務(wù)器優(yōu)化、大規(guī)模集群管理、開源工具應(yīng)用和業(yè)務(wù)故障處理等。EXIN 認證 DevOps Master，專注于運維架構(gòu)優(yōu)化、自動化運維以及運維工作的 DevOps 治理。著有《Nginx應(yīng)用與運維實戰(zhàn)》一書。《Nginx應(yīng)用與運維實戰(zhàn)》是一部基于 Nginx 新版本和云原生應(yīng)用場景系統(tǒng)講解Nginx的著作，是作者十余年運維經(jīng)驗的總結(jié)。從應(yīng)用、運維以及與 Kubernetes 和微服務(wù)集成3個維度對 Nginx 的基礎(chǔ)知識、工作原理、核心應(yīng)用、運維管理、集成擴展等重點內(nèi)容進行了全面、細致的講解。完全以實戰(zhàn)為導(dǎo)向，包含大量的配置案例和示例代碼，能幫助讀者快速掌握并在實際工作中熟練應(yīng)用 Nginx。
|
