[[338783]]

在 Raygun ，追求極致性能已然成為公司文化的一部分。在發(fā)布本文時(shí)，我們?cè)?Twitter 上被問到一個(gè)問題，為什么我們會(huì)使用 Nginx 作為 Raygun API 應(yīng)用程序的代理。

回答是，這是微軟推薦的方法。事實(shí)證明，自.NET Core 2.1 發(fā)布以來(lái)，情況并非如此。從我們第一次使用.NET Core 1.0 到現(xiàn)在，Kestrel 已經(jīng)成熟很多，并且自.NET Core 2.1 發(fā)行以來(lái)，微軟的安全專家們對(duì) Kestrel 在前端服務(wù)的表現(xiàn)感到十分滿意。

1. 為什么移除或使用 Nginx？

在某些情況下，大家仍然會(huì)堅(jiān)持使用 Nginx 這樣的代理，我會(huì)在下面給你列舉出來(lái)。對(duì)于 Raygun，我們的 API 服務(wù)器僅托管了一個(gè)應(yīng)用程序，然后僅通過負(fù)載均衡設(shè)備公開到互聯(lián)網(wǎng)。這意味著對(duì)端口共享的限制并不適用于我們，開放給外部的服務(wù)已經(jīng)被最小化了。

我們可能要使用代理的一些原因（來(lái)自微軟的一篇博文），列舉如下：

• 限制其托管應(yīng)用程序的對(duì)外公開部分
• 提供附加的配置和防御層
• 方便與現(xiàn)有基礎(chǔ)架構(gòu)更好地集成
• 簡(jiǎn)化負(fù)載平衡和安全通信（HTTPS）配置。只有反向代理服務(wù)器需要 X.509 證書，并且該服務(wù)器可以使用 HTTP 與內(nèi)部網(wǎng)絡(luò)上的應(yīng)用服務(wù)器進(jìn)行通信。

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy

2. 移除 Nginx 后的業(yè)務(wù)表現(xiàn)

對(duì)于我們的 API 節(jié)點(diǎn)，從配置中刪除 Nginx 可以使我們處理更多的請(qǐng)求而無(wú)需額外費(fèi)用。

通過負(fù)載測(cè)試，我們還發(fā)現(xiàn)請(qǐng)求的平均響應(yīng)時(shí)間和第 99 百分位響應(yīng)時(shí)間得到顯著改善。這意味著我們的客戶對(duì) API 服務(wù)的請(qǐng)求更快，并允許他們?cè)趩挝粫r(shí)間內(nèi)發(fā)送更多數(shù)據(jù)。

自從將新的服務(wù)器配置投入生產(chǎn)以來(lái)，我們的負(fù)載均衡設(shè)備報(bào)告 5xx 錯(cuò)誤也大大減少了?，F(xiàn)在，我們可以支撐處理更高的客戶端負(fù)載，而且用戶遇到的錯(cuò)誤問題也更少了。

3. 我們?nèi)绾螠y(cè)試.NET Core 性能

我們?cè)趤嗰R遜的 AWS c5.large 實(shí)例 Ubuntu 18.04 環(huán)境下進(jìn)行了測(cè)試?；鶞?zhǔn)服務(wù)器運(yùn)行了 Nginx 和 Kestrel Web 服務(wù)，Nginx 作為 Kestrel Web 服務(wù)代理；作為對(duì)比，在另一臺(tái)服務(wù)器上，服務(wù)請(qǐng)求直接由 Kestrel 處理。

我們使用 Apache JMeter 將 Raygun Crash Reporting 樣本有效負(fù)載發(fā)布到服務(wù) API。JMeter 可以模擬非常高的并發(fā)請(qǐng)求負(fù)載。我們對(duì)此不斷進(jìn)行調(diào)整，讓每臺(tái)服務(wù)器都最大程度地利用 CPU，逼近服務(wù)過載即將不能支撐處理所有請(qǐng)求的極限（但是仍然保證請(qǐng)求的成功率為 100％）。

https://raygun.com/platform/crash-reporting

使用 JMeter 運(yùn)行多次測(cè)試，每個(gè)測(cè)試持續(xù) 10 分鐘，每次測(cè)試結(jié)束時(shí)生成保存測(cè)試摘要報(bào)告。

最后，我們將多次測(cè)試的結(jié)果取平均值，最終得出下面的測(cè)試結(jié)果。

4. 移除 Nginx 后的結(jié)果展示

響應(yīng)時(shí)間（毫秒）

平均響應(yīng)時(shí)間（該值越小性能越好）從 1.2ms 減少到 0.8ms，相當(dāng)于降低了 33％；第 99 百分位響應(yīng)時(shí)間從 6ms 減少到 4ms，相當(dāng)于降低了 33％。

TPS

TPS（該值越大性能越好）從 3783 個(gè)增加到 5461 個(gè)，相當(dāng)于提升了 44％。

5. 在生產(chǎn)環(huán)境運(yùn)行新配置服務(wù)的觀察結(jié)果

內(nèi)存使用情況

使用 Nginx 運(yùn)行該服務(wù)實(shí)例時(shí)，每個(gè)實(shí)例使用的平均內(nèi)存非常一致，內(nèi)存使用率在 13％和 16％之間。

自從刪除 Nginx 以來(lái)，我們已經(jīng)看到服務(wù)進(jìn)程的內(nèi)存使用率變大，在 15％到 30％之間，平均值趨近為 22％。我們確信這是由于 Nginx 限制了 Kestrel 處理的請(qǐng)求數(shù)量。

因此，Kestrel 在高并發(fā)下始終會(huì)以一定的速率處理請(qǐng)求，這意味著內(nèi)存使用量幾乎沒有很大變化。消除這一瓶頸后，由于 Kestrel 會(huì)處理數(shù)量不等的請(qǐng)求，我們現(xiàn)在可以看到更多的內(nèi)存使用和變化情況。

Nginx + Kestrel

Kestral only

平均活躍節(jié)點(diǎn)數(shù)

活躍節(jié)點(diǎn)的平均數(shù)量從 5.35 下降到 4.66?，F(xiàn)在，我們可以看到相當(dāng)長(zhǎng)的時(shí)間內(nèi)僅僅運(yùn)行著四個(gè)服務(wù)器；而在同一時(shí)段的高峰時(shí)期，相比之前使用 Nginx，我們同樣運(yùn)行著更少的服務(wù)器。

Nginx + Kestrel

Kestral only

負(fù)載均衡設(shè)備的 5xx 錯(cuò)誤率

一段時(shí)間以來(lái)，我們發(fā)現(xiàn)通過負(fù)載均衡設(shè)備統(tǒng)計(jì)的信息報(bào)告中，5xx 錯(cuò)誤率很高，如下圖所示。這些錯(cuò)誤并不是來(lái)自我們應(yīng)用程序，而且在 Raygun 也沒有對(duì)其認(rèn)定為故障并進(jìn)行報(bào)告。

原來(lái)，這些錯(cuò)誤來(lái)自 Nginx，并且通過刪除此代理，我們現(xiàn)在可以更好地處理滿負(fù)載，而且大大減少了故障的發(fā)生。

總體而言，由于我們服務(wù)器處理的請(qǐng)求量很大，即使是以下較高的數(shù)量也僅占我們處理的總請(qǐng)求量的很小一部分。注意到通過刪除 Nginx 層可以得到顯著的性能提升，這一點(diǎn)是值得肯定的。我們并不是對(duì) Nginx 進(jìn)行批評(píng)和否定，當(dāng)然也有可能是我們 Nginx 最終的配置問題，但是，簡(jiǎn)化配置似乎可以更好地解決這個(gè)問題。

6. 總結(jié)

敢質(zhì)疑關(guān)于性能問題的原始假設(shè)非常棒，在 Raygun，我們追根溯源，最終發(fā)現(xiàn)問題以及解決了問題。隨著我們基礎(chǔ)架構(gòu)的不斷拓展，能夠以更低成本處理更多的數(shù)據(jù)，這給我們帶來(lái)了一些可觀的業(yè)務(wù)收益，而這一切都始于有人問了一個(gè)簡(jiǎn)單的問題：“為什么？”

值得注意的是，.NET 團(tuán)隊(duì)一直在努力改善和優(yōu)化性能。盡管.NET 5 計(jì)劃于今年 11 月發(fā)布，但目前已經(jīng)有很多重要更新可以使用了。