建站
咨詢
售后
建站咨詢
新聞中心
作為一名程序員，我們不能只關(guān)注代碼的實(shí)現(xiàn)和上線，而忽視了線上環(huán)境的運(yùn)行和優(yōu)化。
循化網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),循化網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為循化成百上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站制作要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的循化做網(wǎng)站的公司定做！
近期遇到了兩個(gè)線上服務(wù)的問(wèn)題，一個(gè)后端應(yīng)用和一個(gè)前端項(xiàng)目，它們存在一些 bug 和歷史遺留問(wèn)題。為了不影響用戶的使用體驗(yàn)，決定對(duì)它們進(jìn)行一次優(yōu)化。
后端服務(wù)
這個(gè)后端服務(wù)是年初的時(shí)候有同事離職了，交到了我這里，沒(méi)接手的時(shí)候不知道，沒(méi)想到接手后，到處都是問(wèn)題，天天各種報(bào)警，基本上隔三差五就要重啟。
雖然一開(kāi)始的時(shí)候知道這個(gè)服務(wù)不是很穩(wěn)定，日常會(huì)有一些隊(duì)列消息堆積，但是不在自己手上，不知道問(wèn)題會(huì)這么多，動(dòng)不動(dòng)就堆積上億條消息，天天慢 SQL 和高負(fù)載報(bào)警。
平時(shí)工作日的時(shí)候收到報(bào)警不是很在意，順手重啟一下就算了，但是當(dāng)每次周末或者出門(mén)在外的時(shí)候，收到報(bào)警心里還是蠻荒的。
抱著做一個(gè)問(wèn)題的終結(jié)者的想法，最后還是準(zhǔn)備花時(shí)間把這個(gè)服務(wù)做一下手術(shù)，從根本上解決問(wèn)題。
效果
先說(shuō)一下效果，這個(gè)服務(wù)從優(yōu)化過(guò)后，基本上除了迭代就再也沒(méi)有需要重新啟動(dòng)過(guò)，更不存在隔三差五的重啟，現(xiàn)在每天的報(bào)警量從之前的一天幾百條變?yōu)?0，隊(duì)列無(wú)任何堆積。
優(yōu)化過(guò)程
優(yōu)化的過(guò)程中最難的是發(fā)現(xiàn)問(wèn)題，只要能精準(zhǔn)的找到問(wèn)題所在，解決起來(lái)還是很容易的。
優(yōu)化主要分兩步：1. 解決慢 SQL；2. 解決堆積報(bào)警；
慢 SQL
解決慢 SQL 的思路很簡(jiǎn)單，根據(jù)慢 SQL 日志，找到對(duì)應(yīng)的慢 SQL 進(jìn)行優(yōu)化即可。優(yōu)化可以從兩個(gè)方向來(lái)進(jìn)行，一種是基于 SQL 本身來(lái)進(jìn)行優(yōu)化，另一種是可以通過(guò)緩存來(lái)解決。這里需要根據(jù)具體的業(yè)務(wù)來(lái)選擇，如果不是經(jīng)常變動(dòng)的數(shù)據(jù)，則可以通過(guò)增加緩存來(lái)解決，剛好我這里就可以滿足。
經(jīng)過(guò)分析可以通過(guò)增加 Redis 緩存來(lái)解決這個(gè)問(wèn)題，所以通過(guò)引入的 Redis 解決了慢 SQL 問(wèn)題。
消息堆積
隊(duì)列消息堆積的處理方式無(wú)非也就是兩種，減少數(shù)據(jù)量，加快處理速度。
消息隊(duì)列里面的消息因?yàn)槭巧嫌伟l(fā)過(guò)來(lái)的，沒(méi)辦法從發(fā)送方進(jìn)行減少，不過(guò)分析了一下消息類型，發(fā)現(xiàn)有很多消息的類型是完全不需要關(guān)心的，所以第一步增加消息過(guò)濾，將無(wú)用的消息直接提交掉。
另外之前遇到消息堆積的時(shí)候，觀察到消費(fèi)消息的 TPS 特別低，有時(shí)候只有個(gè)位數(shù)，完全不正常，而且每次重啟過(guò)后 TPS 可以達(dá)到幾千的級(jí)別，并且每次堆積的時(shí)候在日志層面都有一些“斷開(kāi)連接” 的錯(cuò)誤。
所以從日志層面分析，肯定是消費(fèi)線程出了問(wèn)題，導(dǎo)致消費(fèi)能力下降從而堆積，從而問(wèn)題就轉(zhuǎn)變?yōu)闉槭裁淳€程會(huì)出現(xiàn)異常。
仔細(xì)查了下應(yīng)用層面的監(jiān)控，發(fā)現(xiàn)應(yīng)用有頻繁的 FullGC 發(fā)生，奇怪的是為什么頻繁 FullGc 卻沒(méi)有觸發(fā)報(bào)警呢？看了一眼簡(jiǎn)直要吐血，因?yàn)?nbsp;FullGc 的報(bào)警開(kāi)關(guān)被關(guān)了。。。
至此基本上能知道問(wèn)題的原因了，因?yàn)榘l(fā)生了 FullGc 導(dǎo)致 STW，然后消費(fèi)線程掛了，導(dǎo)致消息堆積，重啟后內(nèi)存釋放重新進(jìn)行消費(fèi)。接下來(lái)的問(wèn)題就轉(zhuǎn)變?yōu)榕挪?nbsp;FullGc 的原因了。
排查 FullGc 的基本流程首先肯定是 dump 一下內(nèi)存的 heap ，然后分析一下內(nèi)存泄露的代碼塊。通過(guò) dump 下來(lái)的日志，發(fā)現(xiàn)在代碼中使用 ThreadLocal，但是沒(méi)有釋放，從而導(dǎo)致頻次的 FullGc。問(wèn)題到這基本上也解決了，修改了相關(guān)的地方，重新上線，穩(wěn)定運(yùn)行。
至此沒(méi)有堆積，沒(méi)有報(bào)警，沒(méi)有重啟，爽歪歪！
總結(jié)
敬畏線上，不要放過(guò)任何一個(gè)線上的異常和報(bào)警！
有時(shí)候問(wèn)題的表象并不是真正的原因，我們需要精準(zhǔn)的找到根源，解決問(wèn)題最難的地方是找到問(wèn)題！
別干隨便關(guān)閉線上監(jiān)控報(bào)警的事情！
另外之所以能快速的定位到問(wèn)題所在也是因?yàn)橄到y(tǒng)有著很好的異常監(jiān)控，可以監(jiān)測(cè)到慢 SQL 和堆積報(bào)警，這也告訴我們平時(shí)的服務(wù)監(jiān)控是很重要的。
前端項(xiàng)目
之前有個(gè)內(nèi)部服務(wù)，在部署服務(wù)的時(shí)候，nginx 配置了 http 和 https 兩個(gè) server，公司內(nèi)部使用的時(shí)候一直都用的是 https，結(jié)果今天運(yùn)營(yíng)同事突然說(shuō)訪問(wèn)不了了，通過(guò)觀察發(fā)現(xiàn)是 http 協(xié)議訪問(wèn)不通。
正常的邏輯是如果用戶在地址欄直接輸入 xxx.com 的時(shí)候默認(rèn)是走的 http 協(xié)議 80 端口，在 nginx 層會(huì)轉(zhuǎn)發(fā)到 https 的 443 端口，也就是會(huì)有一個(gè)重定向的過(guò)程。
檢查了一下 nginx 的配置文件，發(fā)現(xiàn)在 80 這個(gè) server 里面沒(méi)有配置 server_name，修改如下就好了。
只能說(shuō)太粗心了
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name xxx.com www.xxx.com;
root /usr/share/nginx/html;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name xxx.com www.xxx.com;
root /usr/share/nginx/html;
ssl_certificate "xxx.crt";
ssl_certificate_key "xxx.key";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_ciphers PROFILE=SYSTEM;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://backend$request_uri;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
client_max_body_size 10m;
# 實(shí)現(xiàn)前端打字效果
proxy_buffering off;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}頁(yè)面加載時(shí)間優(yōu)化
另外在使用的時(shí)候還發(fā)現(xiàn)，有的時(shí)候網(wǎng)頁(yè)或者手機(jī)打開(kāi)網(wǎng)站需要好幾秒才能把整個(gè)頁(yè)面渲染出來(lái)，自己用起來(lái)都很不爽更別說(shuō)什么用戶體驗(yàn)了。
通過(guò)瀏覽器的 network 欄目，發(fā)現(xiàn)網(wǎng)站在加載的時(shí)候會(huì)聯(lián)網(wǎng)訪問(wèn)一個(gè) css 文件，這個(gè) css 文件里面會(huì)用到很多字體文件，而且這些字體文件也是從網(wǎng)絡(luò)實(shí)時(shí)下載的。
看了下 Issue 發(fā)現(xiàn)也有其他人遇到了這個(gè)問(wèn)題，這個(gè)更夸張直接加載了 42 秒。
圖片
通過(guò)將這個(gè)問(wèn)題提交下載下來(lái)，然后直接訪問(wèn)，不再?gòu)木W(wǎng)絡(luò)上下載。手動(dòng)將這個(gè) css 文件下載下來(lái)過(guò)后，發(fā)現(xiàn)里面還引用的很多字體文件，如下所示，總共 388 個(gè)，這樣是手動(dòng)一個(gè)個(gè)下載那不是要了老命。
圖片
所以需要通過(guò)腳本來(lái)進(jìn)行下載，通過(guò)詢問(wèn) ChatGPT 讓它幫我們寫(xiě)一個(gè) go 語(yǔ)言腳本來(lái)執(zhí)行這個(gè)邏輯。
圖片
完整的代碼如下所示
package main
import (
"bufio"
"fmt"
"net/http"
"os"
"regexp"
"strings"
)
func main() {
const cssPath = "css2.css"
const fontDir = "fonts"
const urlPrefix = "https:"
// 讀取 CSS 文件
cssFile, err := os.Open(cssPath)
if err != nil {
panic(fmt.Sprintf("Failed to open %s: %s", cssPath, err))
}
defer cssFile.Close()
// 創(chuàng)建字體存儲(chǔ)目錄
if err := os.MkdirAll(fontDir, 0755); err != nil {
panic(fmt.Sprintf("Failed to create font directory: %s", err))
}
// 解析 CSS 文件
scanner := bufio.NewScanner(cssFile)
for scanner.Scan() {
line := scanner.Text()
if strings.Contains(line, "url(") && strings.Contains(line, ".woff2") {
// 使用正則表達(dá)式提取 WOFF2 文件 URL
re := regexp.MustCompile(`url\(["']?([^"']+\.(woff2))`)
matches := re.FindStringSubmatch(line)
if len(matches) >= 2 {
fontUrl := matches[1]
if strings.HasPrefix(fontUrl, "http://") {
fontUrl = urlPrefix + fontUrl
}
// 下載 WOFF2 文件
fmt.Printf("Downloading %s...\n", fontUrl)
res, err := http.Get(fontUrl)
if err != nil {
fmt.Printf("Failed to download %s: %s\n", fontUrl, err)
continue
}
defer res.Body.Close()
// 創(chuàng)建字體文件
fontPath := fmt.Sprintf("%s/%s", fontDir, matches2)
fontFile, err := os.Create(fontPath)
if err != nil {
fmt.Printf("Failed to create font file %s: %s\n", fontPath, err)
continue
}
defer fontFile.Close()
// 寫(xiě)入字體文件
_, err = fontFile.ReadFrom(res.Body)
if err != nil {
fmt.Printf("Failed to write to font file %s: %s\n", fontPath, err)
} else {
fmt.Printf("Font file %s downloaded.\n", fontPath)
}
}
}
}
}ChatGPT 不僅給出了代碼，還給出了解釋
此腳本遵循以下步驟：
- 打開(kāi) CSS 文件
- 逐行讀取文件內(nèi)容
- 對(duì)每一行使用正則表達(dá)式進(jìn)行匹配，查找字體文件鏈接
- 使用 http.Get() 發(fā)送 HTTP 請(qǐng)求下載字體文件
- 創(chuàng)建本地文件，并將字體數(shù)據(jù)寫(xiě)入該文件
圖片
上面代碼通過(guò) go run download.go 直接運(yùn)行腳本發(fā)現(xiàn)是可以正常運(yùn)行的，但是一開(kāi)始是有個(gè)問(wèn)題的那就是沒(méi)有考慮到多個(gè)文件會(huì)覆蓋，我們簡(jiǎn)單修改幾行就可以正常使用了。
index := strings.LastIndex(matches[1], "/")
filename := matches[1][index+1:]
// 創(chuàng)建字體文件
fontPath := fmt.Sprintf("%s/%s", fontDir, filename)運(yùn)行后的效果是這樣的，全部下載下來(lái)，我們需要做的就是在 css 文件中通過(guò)快捷鍵全部替換一下就好了。
圖片
優(yōu)化過(guò)后文件的下載速度穩(wěn)定了一秒以內(nèi)，雖然還可以通過(guò) CDN 等方式進(jìn)一步優(yōu)化，但是感覺(jué)目前是沒(méi)必要的?，F(xiàn)在剩下的就是受限于服務(wù)器的寬帶和網(wǎng)絡(luò)了，不過(guò)整體是可以接受的了。
圖片
試了下移動(dòng)端打開(kāi)的速度也有所提升。
總結(jié)
通過(guò)上面的過(guò)程，可以看到 ChatGPT 是真的可以幫我們提高工作效率的，寫(xiě)一個(gè)腳本沒(méi)什么難度，花點(diǎn)時(shí)間也是可以寫(xiě)出來(lái)的，但是有了這樣的工具大大的節(jié)省了我們的時(shí)間，對(duì)于生成的內(nèi)容需要能看懂和能進(jìn)行修改就行了。
但是工具也只是工具，還是要學(xué)會(huì)使用才行，不能太盲目的依賴。
網(wǎng)站標(biāo)題：作為程序員，我們不能只管上線，不管線上！
網(wǎng)站鏈接：http://www.5511xx.com/article/cosghpe.html
