“京東開(kāi)放服務(wù)平臺(tái)是京東對(duì)外開(kāi)發(fā)的窗口，每年的 618 大促，京東的網(wǎng)關(guān)都要承載十億級(jí)的調(diào)用量來(lái)保障幾十萬(wàn)商家穩(wěn)定使用的使命。

在保證近千個(gè)不同類(lèi)型服務(wù)接口的海量調(diào)用的同時(shí)，我們還要確保服務(wù)接口之間的互不干擾，并且能夠快速響應(yīng)任何復(fù)雜情況，因此穩(wěn)定、快速是我們一直追求的目標(biāo)。

[[209075]]

今年的 618 大促，京東的網(wǎng)關(guān)承載了幾十億的流量和調(diào)用，在這種情況下，網(wǎng)關(guān)系統(tǒng)必須保證整個(gè)系統(tǒng)的穩(wěn)定性和高可用，保證高性能和可靠性，以支撐業(yè)務(wù)。

我們面臨的是一個(gè)非常復(fù)雜的問(wèn)題，基于這種復(fù)雜問(wèn)題，怎樣做到很好地提高它的性能和穩(wěn)定性，復(fù)雜技術(shù)之間怎么整合保證整體網(wǎng)關(guān)的高可用，是本文的重點(diǎn)。

網(wǎng)關(guān)涵蓋技術(shù)

網(wǎng)關(guān)系統(tǒng)

網(wǎng)關(guān)系統(tǒng)主要有兩種：

• 客戶(hù)端網(wǎng)關(guān)，主要用來(lái)接收一些客戶(hù)端的請(qǐng)求，也就是 APP 的服務(wù)端。
• 開(kāi)放網(wǎng)關(guān)，主要是公司(比如京東)對(duì)于第三方合作伙伴提供接口。

這兩種不同網(wǎng)關(guān)所使用的技術(shù)非常類(lèi)似。

流量比較大的網(wǎng)關(guān)面臨的難點(diǎn)包括：

• 網(wǎng)關(guān)系統(tǒng)需要扛幾十億的流量調(diào)用，接口的平穩(wěn)運(yùn)行、每一個(gè)接口在后端服務(wù)之后的性能耗損都非常重要。

比如我們使用了一個(gè) Redis 集群，然后構(gòu)建了兩個(gè)機(jī)房，每一個(gè)機(jī)房都搭建了一個(gè) Redis 集群，這樣的話就能夠很好地保證高可用。

在面對(duì)一個(gè)瞬間流量的時(shí)候，我們采用了一些緩存技術(shù)，或者更前置的 Nginx+lua+Redis 技術(shù)，讓這種大流量應(yīng)用能夠脫離開(kāi) JVM 的依賴(lài)。

還有我們需要梳理各個(gè)接口，通過(guò)降級(jí)的策略把一些弱依賴(lài)的接口進(jìn)行降級(jí)，從而保證核心應(yīng)用的可用。

網(wǎng)關(guān)系統(tǒng)其實(shí)就是一個(gè)把 HTTP 請(qǐng)求拓展到后端服務(wù)的過(guò)程。

我們的網(wǎng)關(guān)承接了一千以上的后端服務(wù)接口，面對(duì)這種情況，怎樣做到服務(wù)與服務(wù)之間相互不影響?架構(gòu)層面怎樣能夠杜絕蝴蝶效應(yīng)、防止雪崩?

就是說(shuō)當(dāng)一個(gè)接口出現(xiàn)問(wèn)題的時(shí)候，不至于影響到其他接口的健康運(yùn)行。這個(gè)說(shuō)起來(lái)簡(jiǎn)單，但實(shí)際卻不然。

一千個(gè)以上的接口，每個(gè)接口性能都不一致，而且每個(gè)接口所依賴(lài)的外部資源、數(shù)據(jù)庫(kù)緩存等都不一樣，幾乎每天都會(huì)出現(xiàn)各種各樣的問(wèn)題，我們?cè)鯓油ㄟ^(guò)一些隔離技術(shù)、治理技術(shù)等，保證當(dāng)這些接口出現(xiàn)問(wèn)題的時(shí)候，不會(huì)影響到全局?

• 我們對(duì)外暴露了一千個(gè)服務(wù)接口，所有接口的后面意味著幾十個(gè)甚至上百個(gè)團(tuán)隊(duì)每天在不停地開(kāi)發(fā)，每天都可能上線新的需求。

面對(duì)這么復(fù)雜的情況，我們不可能每次后端服務(wù)器有任何修改，都需要有網(wǎng)關(guān)的修改或上線，這樣網(wǎng)關(guān)會(huì)變得非常脆弱，穩(wěn)定性極低。

我們采用了一個(gè)動(dòng)態(tài)接入的技術(shù)，讓后端的網(wǎng)關(guān)能夠通過(guò)一種接入的協(xié)議進(jìn)行無(wú)縫接入，之后通過(guò)一些動(dòng)態(tài)代理的方式，直接讓后端的接口，不管做任何修改或上線，都可以通過(guò)后端管理平臺(tái)從網(wǎng)關(guān)上對(duì)外進(jìn)行透?jìng)靼l(fā)布。

這樣就很好地解決了網(wǎng)關(guān)所面臨的依賴(lài)于后端接口服務(wù)的上線問(wèn)題。

網(wǎng)關(guān)涵蓋技術(shù)

網(wǎng)關(guān)的四個(gè)技術(shù)方向：

• 統(tǒng)一接入，就是前端(包括 APP 或其他來(lái)源)的流量，都能在統(tǒng)一網(wǎng)絡(luò)層進(jìn)行接入。

這一層所面臨的問(wèn)題是：高性能透?jìng)?、高并發(fā)接入、高可效性，以及當(dāng)前端流量來(lái)了之后，怎樣能夠進(jìn)行一個(gè)負(fù)載的服務(wù)往后端的轉(zhuǎn)發(fā)。

• 流量管控，主要指流量治理部分。面對(duì)海量流量，我們?cè)鯓油ㄟ^(guò)一些防刷技術(shù)，保障網(wǎng)關(guān)不被大流量沖垮;以及怎樣通過(guò)一些像限流、降級(jí)、熔斷等技術(shù)，對(duì)網(wǎng)關(guān)進(jìn)行全方位保護(hù)。
• 協(xié)議適配，就是前文提到的，網(wǎng)關(guān)會(huì)透?jìng)骱蠖松锨€(gè)服務(wù)，而這些服務(wù)一定不是每一個(gè)都需要網(wǎng)關(guān)去開(kāi)發(fā)配置的。

我們通過(guò)一個(gè)協(xié)議適配的轉(zhuǎn)換，讓后端的各種服務(wù)通過(guò)我們指定的協(xié)議、通過(guò) HTTP 的方式從網(wǎng)關(guān)開(kāi)放出去，當(dāng)然網(wǎng)關(guān)不單單是 HTTP 協(xié)議，還有一些 TCP 的。

京東內(nèi)部的協(xié)議相對(duì)比較統(tǒng)一，有 HTTP 的 restful 的協(xié)議，也有 JSF 的接口，JSF 是京東內(nèi)部自研的一個(gè)框架，一個(gè) RPC 調(diào)用框架，和 Double 是類(lèi)似的，然后基于注冊(cè)發(fā)現(xiàn)的一個(gè) RPC 框架。

• 安全防護(hù)，這一部分對(duì)于網(wǎng)絡(luò)來(lái)說(shuō)非常重要，因?yàn)榫W(wǎng)關(guān)是整個(gè)公司對(duì)外的一個(gè)出口，在這一層我們要做一些防刷。

比如防清洗一些惡意流量、做一些黑名單，當(dāng)有一些惡意流量的話，通過(guò)限制 IP 等限制手段把它拒絕在整個(gè)網(wǎng)關(guān)之外，防止這些惡意流量把網(wǎng)關(guān)沖垮。

自研網(wǎng)關(guān)架構(gòu)

自研網(wǎng)關(guān)架構(gòu)

我們的自研網(wǎng)關(guān)架構(gòu)主要分為三層：

接入層

主要負(fù)責(zé)一些長(zhǎng)短鏈接的接入、限流、黑白名單、路由、負(fù)載均衡、容災(zāi)切換等。這一層所采用的技術(shù)是 Nginx+lua 的方式。

分發(fā)層

這一層是分發(fā)層或者叫網(wǎng)關(guān)的業(yè)務(wù)層，它更多的是 NIO+Serviet3 異步的技術(shù)。

在這一層中又分為幾個(gè)部分：

• 最上層部分是數(shù)據(jù)校驗(yàn)，在這一層會(huì)做一些簽名的校驗(yàn)、時(shí)間的校驗(yàn)、版本、方法等。
• 下面一層叫泛化調(diào)用層，主要是把網(wǎng)關(guān)對(duì)外暴露的 restful 請(qǐng)求轉(zhuǎn)換成京東內(nèi)部的協(xié)議，進(jìn)行一個(gè)動(dòng)態(tài)適配調(diào)用的過(guò)程。

這一塊我們更多使用的是一些緩存的技術(shù)，線程隔離、熔斷等技術(shù)也都是在這一層實(shí)現(xiàn)的。

因?yàn)橛写罅繑?shù)據(jù)和協(xié)議的轉(zhuǎn)換，所以這一層用了多使用緩存的技術(shù)，我們網(wǎng)關(guān)層所有的數(shù)據(jù)都不會(huì)直接穿透到 DB，而是采用一個(gè)叫異構(gòu)數(shù)據(jù)的方式直接用緩存去做的。

泛化層中間有兩塊：

• 主動(dòng)通知，就是我們會(huì)通過(guò)這種 TCP 的下行通道及時(shí)通知到客戶(hù)端，發(fā)一些像京東賬戶(hù)優(yōu)惠券或提醒等。
• 沙箱測(cè)試，主要是在一些接口發(fā)布上線之前，進(jìn)行一個(gè)外部的測(cè)試。

如上圖，最右側(cè)部分是服務(wù)降級(jí)、日志記錄、監(jiān)控告警，這三個(gè)都是我們整個(gè)網(wǎng)關(guān)的支撐系統(tǒng)。

服務(wù)降級(jí)是說(shuō)當(dāng)有些服務(wù)出現(xiàn)問(wèn)題，第一時(shí)間把它降調(diào);日志是給我們排查問(wèn)題用的。

監(jiān)控告警在下文會(huì)重點(diǎn)介紹，因?yàn)橐粋€(gè)網(wǎng)關(guān)的可用性很大方面是通過(guò)監(jiān)控系統(tǒng)來(lái)完善的，沒(méi)有監(jiān)控系統(tǒng)、沒(méi)有告警，就像沒(méi)有眼睛一樣，沒(méi)辦法知道任何事。

后端各種各樣的業(yè)務(wù) API

這些業(yè)務(wù) API(業(yè)務(wù)接口)通過(guò)網(wǎng)關(guān)對(duì)外進(jìn)行暴露。整個(gè)網(wǎng)關(guān)大體上分為如上圖的三層，最上面是接入層、中間是網(wǎng)關(guān)的分發(fā)層，以及業(yè)務(wù)校驗(yàn)、業(yè)務(wù)邏輯層，然后通過(guò)網(wǎng)關(guān)透?jìng)髡?qǐng)求到后端服務(wù)。

除了這三層之外，我們?cè)倏磧蛇叺南到y(tǒng)，都是我們整個(gè)網(wǎng)關(guān)比較核心和重要的支撐：

• 網(wǎng)關(guān)注冊(cè)中心，后端各種各樣的接口可以通過(guò)網(wǎng)關(guān)注冊(cè)中心對(duì)外進(jìn)行發(fā)布，這個(gè)系統(tǒng)有一個(gè)類(lèi)似的管理界面，只要后端的 API 服務(wù)按照固有的協(xié)議進(jìn)行一個(gè)編寫(xiě)。
• 如果格式 OK 的話上傳到管理后臺(tái)，一鍵就可以發(fā)布到線上。當(dāng)然接口發(fā)布之前會(huì)有一個(gè)測(cè)試。
• OA 鑒權(quán)中心，這一塊主要是做鑒權(quán)用的，像數(shù)據(jù)校驗(yàn)層的很多簽名的校驗(yàn)等安全校驗(yàn)都是在這一層統(tǒng)一做的。

技術(shù)棧

我們的網(wǎng)關(guān)系統(tǒng)所涉及到的一些技術(shù)棧：

• 接入層 Nginx+lua 技術(shù)。
• NIO+Serviet3 異步技術(shù)。
• 分離技術(shù)。
• 降級(jí)限流。
• 熔斷技術(shù)。
• 緩存，哪些地方該加緩存，哪些地方可以直接讀庫(kù)。
• 異構(gòu)數(shù)據(jù)。
• 快速失敗。
• 監(jiān)控統(tǒng)計(jì)，這是整個(gè)高可用網(wǎng)關(guān)系統(tǒng)里非常重要的一部分。

下文會(huì)針對(duì)這些技術(shù)所適用的場(chǎng)景進(jìn)行深入探討和分析，包括我們用這些技術(shù)解決什么問(wèn)題。

基本思路及過(guò)程改進(jìn)點(diǎn)

Nginx 層統(tǒng)一接入

先看網(wǎng)關(guān)整個(gè)線上的部署架構(gòu)，通過(guò)一個(gè)軟負(fù)載 LVS 進(jìn)入到整個(gè)京東的網(wǎng)關(guān)，第一層是核心 Nginx，經(jīng)過(guò)核心 Nginx 之后就是后面的業(yè)務(wù) Nginx，然后通過(guò)業(yè)務(wù) Nginx 把我們的請(qǐng)求透?jìng)鞯胶蠖说姆?wù)器。

核心 Nginx 主要是前端流量的分配，比如限流、防刷都是在這層去做。下層是業(yè)務(wù) Nginx，主要的 Nginx+lua 的邏輯在這一層實(shí)現(xiàn)。

這一層還有能減輕核心 Nginx 壓力、CPU 壓力的作用，而且一些 lua 的應(yīng)用邏輯，比如限流、防刷、鑒權(quán)、降級(jí)都是在這一層做的。

為什么要加上 Nginx+lua 這一層?相較于 Tomcat 等，Nginx 是一個(gè)能扛特別大并發(fā)流量的服務(wù)器。

基于這種狀況，我們之前出現(xiàn)過(guò)問(wèn)題，當(dāng)這種并發(fā)流量特別大的時(shí)候，一旦后面出現(xiàn)單機(jī)有問(wèn)題，哪怕你針對(duì)這個(gè)接口做了降級(jí)，但真正流量還是到了 Tomcat 層的 JVM 里。

當(dāng)流量很大的時(shí)候，很難通過(guò) JVM 能夠消化掉，這樣導(dǎo)致的結(jié)果是：當(dāng)你的 Tomcat 出現(xiàn)問(wèn)題了，你很難通過(guò)重啟去解決這個(gè)問(wèn)題。

因?yàn)榱髁繒?huì)一直存在，這臺(tái) Tomcat 出問(wèn)題了， 重啟完之后是把所有行動(dòng)都釋放了，但是它們就像病毒一樣，會(huì)來(lái)回傳染，你重啟了一批，這批馬上又被傳染到。

Nginx 天然就是這種 NIO 異步的方式，能夠非常好地支持大并發(fā)的業(yè)務(wù)需求。所以我們把一些核心的，比如降級(jí)、流控等，都放在這一層，讓它替我們?cè)谧钋岸税蚜髁糠雷　?/p>

引入 NIO、利用 Servlet3 異步化

第二個(gè)實(shí)踐是在 Tomcat 層引入了 NIO，用了一個(gè) JDK7+TOMCAT7+Servlet3 的配置，讓同步請(qǐng)求變得異步化，然后利用 NIO 的多路復(fù)用處理技術(shù)，讓我們能夠同時(shí)處理更高的并發(fā)數(shù)。

利用 Servlet3 異步化之后可以提升吞吐量，但單個(gè)請(qǐng)求的響應(yīng)時(shí)間會(huì)略微變長(zhǎng)，不過(guò)這種損耗是可以忍受的，因?yàn)檫@會(huì)帶來(lái)整個(gè)應(yīng)用吞吐量的增加和靈活性的增強(qiáng)，還是非常值得我們使用的。

具體采用策略：

• 業(yè)務(wù)方法開(kāi)啟異步化上下文 AsynContext。
• 釋放 Tomcat 當(dāng)前處理線程。
• Tomcat 該線程被釋放，然后用于下次請(qǐng)求的處理，提高其吞吐量。
• 在 AsynContext 環(huán)境中完成業(yè)務(wù)方法的處理，調(diào)用其 complete 方法，將響應(yīng)寫(xiě)回響應(yīng)流。

這樣可以提高 Tomcat 業(yè)務(wù)邏輯的可能性，讓我們?cè)谶@一層非常少的線程數(shù)就能處理更多的請(qǐng)求，而不至于當(dāng)流量非常大的時(shí)候被壓垮。

分離之術(shù)

在所有分離技術(shù)中，我挑兩個(gè)比較重要的點(diǎn)進(jìn)行分享。

請(qǐng)求解析和業(yè)務(wù)處理分離

第一個(gè)是通過(guò) NIO 的方式，把請(qǐng)求解析的線程和后面處理的業(yè)務(wù)線程進(jìn)行分離。

請(qǐng)求由 Tomcat 單線程處理，在 NIO 模式下可以用非常少量的線程處理大量的鏈接情況。

業(yè)務(wù)邏輯處理和生成響應(yīng)都是由另外的 Tomcat 線程池處理，從而跟請(qǐng)求線程隔離。這里的業(yè)務(wù)線程池還可以進(jìn)一步隔離，不同業(yè)務(wù)設(shè)置不同的線程池。

業(yè)務(wù)線程池分離

第二個(gè)是業(yè)務(wù)線程池分離，就是通過(guò)一個(gè)線程的隔離技術(shù)，把不同的接口或不同類(lèi)型的接口進(jìn)行隔離。

比如訂單相關(guān)的接口，拿 20 個(gè)單獨(dú)線程去處理;商品相關(guān)的接口，拿 10 個(gè)單獨(dú)的線程去處理，這樣的話就可以讓不同的接口之間互不影響，如果訂單這塊有一個(gè)出了問(wèn)題，最多消耗它自己，不會(huì)影響到其他接口的線程的調(diào)用。

具體的線程隔離可以根據(jù)業(yè)務(wù)來(lái)指定一組線程的數(shù)量，這幾個(gè)線程是為固定接口準(zhǔn)備的。

當(dāng)這個(gè)接口出現(xiàn)問(wèn)題，它就把自己的線程數(shù)用掉了，不會(huì)去占用其他接口的線程，這樣起到了線程隔離的作用，讓單個(gè) API 出問(wèn)題的時(shí)候不會(huì)影響到其他。

降級(jí)

降級(jí)主要是說(shuō)當(dāng)有某個(gè)接口出現(xiàn)問(wèn)題，我們能夠把這個(gè)接口直接降調(diào)，讓它調(diào)用直接返回，不會(huì)用到其他應(yīng)用。

還有就是如果某一塊弱一點(diǎn)的業(yè)務(wù)邏輯出現(xiàn)問(wèn)題，我們直接把這塊邏輯降調(diào)，不至于影響到其他的黃金邏輯。

降級(jí)怎么做?

首先，降級(jí)開(kāi)關(guān)要集中化管理，比如通過(guò) Zookeeper 推送到各個(gè)應(yīng)用服務(wù)。這樣才能在出現(xiàn)問(wèn)題的第一時(shí)間找到對(duì)應(yīng)開(kāi)關(guān)做降級(jí)處理。

一個(gè)基于開(kāi)發(fā)降級(jí)的統(tǒng)一配置本身這個(gè)系統(tǒng)要是高可用的、支持多維度的緩存，比如我們?nèi)绻?Zookeeper 實(shí)現(xiàn)，首先 Zookeeper 會(huì)有數(shù)據(jù)庫(kù)存儲(chǔ)，再上面會(huì)有一個(gè)本地緩存。

再就是我們會(huì)有一個(gè)快照，如果 Zookeeper 讀不到緩存，會(huì)通過(guò)快照去加載進(jìn)來(lái)一些托底的數(shù)據(jù)，以保證開(kāi)發(fā)一旦觸發(fā)之后能夠在第一時(shí)間響應(yīng)。而我們的開(kāi)關(guān)也不至于會(huì)成為其他系統(tǒng)的問(wèn)題，它是非常弱化、非常薄的一層。

精細(xì)化流量控制

說(shuō)完開(kāi)關(guān)、流量控制和降級(jí)之后，我們來(lái)看通過(guò)多維度的流量控制和降級(jí)的策略，比如按照單個(gè) API 或 API+ 地域、運(yùn)營(yíng)商等維度進(jìn)行控制。

一旦出問(wèn)題了，我們會(huì)把多種組合方式進(jìn)行降級(jí)，還可以根據(jù)秒/分鐘級(jí)等不同維度進(jìn)行流量控制，從而達(dá)到精細(xì)化流量管理。

優(yōu)雅降級(jí)

說(shuō)到降級(jí)，前面說(shuō)的更多的是技術(shù)層面的，在業(yè)務(wù)層面的話，我們也要講究?jī)?yōu)雅降級(jí)。我們不能說(shuō)這個(gè)邏輯一旦建立之后就直接返回前端 502，這肯定是不友好的。

我們肯定會(huì)跟前端進(jìn)行溝通，比如降級(jí)之后反饋給前端一個(gè)對(duì)應(yīng)的錯(cuò)誤碼，或者給用戶(hù)反饋一個(gè)提示等操作指令，這樣能夠讓用戶(hù)體驗(yàn)更好一些。

限流

惡意請(qǐng)求、惡意攻擊，惡意的請(qǐng)求流量可設(shè)置為只訪問(wèn) Cache，惡意的IP可以使用 Nginx 層的 Deny 進(jìn)行屛蔽，防止流程超出系統(tǒng)的承載能力，雖然會(huì)預(yù)估但總有意外，如果沒(méi)有限流，當(dāng)超過(guò)系統(tǒng)承載峰值的時(shí)候，整個(gè)系統(tǒng)就會(huì)被打垮。

熔斷

當(dāng)我們的后端機(jī)構(gòu)出現(xiàn)問(wèn)題了，達(dá)到某個(gè)閥值了，系統(tǒng)就能夠自動(dòng)進(jìn)行關(guān)閉降級(jí)，這是熔斷的大體思路。

我們會(huì)有更靈活的配置：比如當(dāng)某個(gè)接口接連三次訪問(wèn)超時(shí)或返回錯(cuò)誤的話就自動(dòng)熔斷。

也可以是配置一些超時(shí)間，比如連續(xù)三次這種方法調(diào)用的性能都超過(guò)了 50 毫秒，就會(huì)自動(dòng)對(duì)這個(gè)方法進(jìn)行熔斷，熔斷之后就相當(dāng)于降級(jí)了，再次調(diào)用的話會(huì)返回失敗，就是直接拒絕返回了。

熔斷之后還可以有一個(gè)設(shè)置：比如 5 秒或一分鐘之后出來(lái)一個(gè)半打開(kāi)狀態(tài)，再次醒來(lái)之后，它會(huì)去試探一下當(dāng)天這個(gè)服務(wù)是否已經(jīng) OK 了，如果沒(méi)有問(wèn)題了，它就會(huì)去把你之前熔斷的 API 業(yè)務(wù)再次打開(kāi)，能夠正常對(duì)外提供服務(wù)。

現(xiàn)在有一些開(kāi)源的實(shí)踐，通過(guò)這些實(shí)踐可以很好的做熔斷，當(dāng)然根據(jù)這里邊的思路，自己也可以實(shí)現(xiàn)，這不是特別復(fù)雜的事情。

快速失敗-鏈路中的超時(shí)

快速失敗是非常重要的一個(gè)實(shí)踐，不光是做網(wǎng)關(guān)系統(tǒng)，做其他系統(tǒng)也要記住，特別是調(diào)用量大的系統(tǒng)，比如注意到整個(gè)鏈條中的超時(shí)設(shè)置。

這是我們每年在做雙 11 和 618 備戰(zhàn)的時(shí)候，都需要重點(diǎn)去 review 的一塊功能，包括我們平時(shí)在做開(kāi)發(fā)的時(shí)候、每一次新模塊上線之前，我們都要重點(diǎn)去監(jiān)控這一塊。

我們會(huì)梳理所有系統(tǒng)對(duì)外的依賴(lài)，比如網(wǎng)關(guān)依賴(lài)于我們自己的一些業(yè)務(wù)的緩存、數(shù)據(jù)庫(kù)，更多的是依賴(lài)于后端數(shù)千個(gè)不同的服務(wù)。

這種涉及到網(wǎng)絡(luò)的，我們必須要設(shè)置超時(shí)間，因?yàn)橄窬W(wǎng)關(guān)這種調(diào)用量比較大的系統(tǒng)，如果不設(shè)超時(shí)間，有可能它默認(rèn)時(shí)間就是幾分鐘。

這么長(zhǎng)時(shí)間，一旦有一個(gè)機(jī)構(gòu)出問(wèn)題了，有可能瞬間整個(gè)網(wǎng)關(guān)系統(tǒng)會(huì)全部雪崩掉，任何一個(gè)接口都不能對(duì)外使用，因?yàn)閿?shù)據(jù)量很大，有可能你都來(lái)不及降級(jí)就已經(jīng)被沖垮了。

監(jiān)控統(tǒng)計(jì)-應(yīng)用層

監(jiān)控統(tǒng)計(jì)是網(wǎng)關(guān)系統(tǒng)里非常核心的一部分，只有有了監(jiān)控，有了報(bào)警，才能讓我們實(shí)時(shí)了解所有的運(yùn)營(yíng)情況、每一個(gè) API 調(diào)用的情況。

監(jiān)控目標(biāo)

• 保證 7*24 小時(shí)守護(hù)系統(tǒng)。
• 能夠?qū)崟r(shí)監(jiān)控系統(tǒng)的運(yùn)營(yíng)狀況，比如哪個(gè) API 是不是調(diào)用時(shí)間過(guò)長(zhǎng)了?哪個(gè) API 已經(jīng)熔斷了?等等。
• 統(tǒng)計(jì)數(shù)據(jù)，分析指標(biāo)。比如一天過(guò)去了，每一個(gè) API 調(diào)用情況有沒(méi)有超時(shí)?有沒(méi)有訪問(wèn)的性能降低等。
• 實(shí)時(shí)報(bào)警。因?yàn)楸O(jiān)控是一部分，發(fā)現(xiàn)問(wèn)題之后能夠第一時(shí)間通知到我們，讓我們能夠馬上處理也是讓系統(tǒng)更加健康的一個(gè)方面。

監(jiān)控范圍

監(jiān)控的維度

• 硬件監(jiān)控。比如系統(tǒng)的 CPU 內(nèi)存、網(wǎng)卡等。
• 自定義監(jiān)控。比如直接報(bào)警。
• 性能監(jiān)控。比如每個(gè)接口的 TP 指標(biāo)，TP999、TP99、TP90、TP50 四種性能指標(biāo)作為 SLA 的參考標(biāo)準(zhǔn)，還有可用率等，這個(gè)對(duì)于網(wǎng)關(guān)來(lái)說(shuō)至關(guān)重要。
• 心跳監(jiān)控。網(wǎng)關(guān)系統(tǒng)線上有很多機(jī)器，每個(gè)機(jī)器現(xiàn)在的情況怎樣?有沒(méi)有存貨等。
• 業(yè)務(wù)層監(jiān)控。比如我們會(huì)有一些 JVM 監(jiān)控，監(jiān)控 Nginx 連接數(shù)等。

在京東內(nèi)部有一個(gè)很完善的監(jiān)控體系，叫 UMP 系統(tǒng)，能夠幫助我們做各個(gè)層級(jí)的監(jiān)控。

它主要是提供給我們一些類(lèi)似于配置的文件，我們配置好之后就可以進(jìn)行系統(tǒng)的監(jiān)控，我們?cè)谧龅臅r(shí)候會(huì)通過(guò)一些 AOP 代理的方式，對(duì)所有的方法進(jìn)行監(jiān)控。

因?yàn)槲覀兪蔷W(wǎng)關(guān)，需要大量的后端透?jìng)?，網(wǎng)關(guān)因?yàn)槭莿?dòng)態(tài)地生成這些接口，根本不知道有哪些接口，所以在動(dòng)態(tài)生成接口的時(shí)候自動(dòng)地 AOP 給它注入一個(gè)個(gè)監(jiān)控，這樣的話就是每一個(gè)接口都能夠有一個(gè)監(jiān)控。

說(shuō)到監(jiān)控不得不提的是，我們做網(wǎng)關(guān)系統(tǒng)就是做透?jìng)鞯?，后面有各種各樣不同的接口、業(yè)務(wù)邏輯，每個(gè)業(yè)務(wù)邏輯和接口的性能都需要去監(jiān)控，然后告知對(duì)方讓對(duì)方去整改的。

所以我們除了把這些監(jiān)控加完之后，有了問(wèn)題要能夠通知到對(duì)應(yīng)的負(fù)責(zé)人，包括我們自己。

我們每一天每一周都會(huì)有郵件以報(bào)表形式發(fā)出，讓所有系統(tǒng)負(fù)責(zé)人都知道對(duì)應(yīng)的機(jī)構(gòu)的情況，比如性能是否有問(wèn)題、是否需要整改等。

[[209076]]

王棟

京東商城開(kāi)放平臺(tái)高級(jí)架構(gòu)師

擁有 10 多年的架構(gòu)和團(tuán)隊(duì)管理經(jīng)驗(yàn)，涉及信息安全、互聯(lián)網(wǎng)、電商等領(lǐng)域。 2011 年底至今一直在京東商城就職，期間負(fù)責(zé)過(guò)商城、POP、京東開(kāi)放生態(tài)、京東移動(dòng) APP、京東商戶(hù) APP 等業(yè)務(wù)，熟悉電商核心的流程和移動(dòng)互聯(lián)網(wǎng)。在這 4 年當(dāng)中見(jiàn)證了京東一步步成長(zhǎng)成為行業(yè)巨頭，也見(jiàn)證了京東的技術(shù)部從 300 人到 7000 人，從跟不上業(yè)務(wù)發(fā)展到驅(qū)動(dòng)業(yè)務(wù)發(fā)展的過(guò)程。 現(xiàn)任京東商城開(kāi)放平臺(tái)高級(jí)架構(gòu)師，京東商家移動(dòng)端負(fù)責(zé)人，京東創(chuàng)新聯(lián)盟平臺(tái)創(chuàng)新評(píng)委，新晉架構(gòu)師評(píng)委等。