背景
2020年2月份左右，正值疫情肆虐，突然在過(guò)年的某一天.接到領(lǐng)導(dǎo)需求，說(shuō)要在app上實(shí)現(xiàn)線上口罩預(yù)約，線下藥店申領(lǐng)的功能，而且要盡快上線,包含C端，后臺(tái)，及B端。C端實(shí)現(xiàn)線上預(yù)約，B端核銷(xiāo) ,當(dāng)時(shí)團(tuán)隊(duì)成員鏖戰(zhàn)3天，滿(mǎn)足上線要求。
上線效果
定時(shí)上線，沒(méi)想到一到時(shí)間點(diǎn)涌上來(lái)的流量與預(yù)估流量相差甚遠(yuǎn)，頁(yè)面卡頓，加載白屏，只有提前進(jìn)去服務(wù)的人才能成功預(yù)約到,客訴壓力也是巨大,沒(méi)辦法，先緊急擴(kuò)容吧，只能說(shuō)效果好了那么一點(diǎn)點(diǎn)。
優(yōu)化措施? ??
前端采用node開(kāi)發(fā),部署在docker中，沒(méi)用docker swarm管理,首先前端針對(duì)靜態(tài)資源做了一次壓縮處理,項(xiàng)目原因，沒(méi)夠買(mǎi)cdn服務(wù)，不過(guò)建議條件允許還是用cdn比較好。當(dāng)時(shí)node是跑在docker里，啟動(dòng)方式也不是pm2啟動(dòng)，后來(lái)從docker中遷移出來(lái)，改用pm2方式啟動(dòng)，相比以前快了幾個(gè)數(shù)據(jù)來(lái)，咨詢(xún)運(yùn)維，是因?yàn)檫@種方式可以比原來(lái)多很多節(jié)點(diǎn)提供服務(wù)，比如三臺(tái)集群，跑在docker中是三個(gè)節(jié)點(diǎn)，但是遷移出來(lái)改用pm2,單個(gè)服務(wù)器上等同于cpu核數(shù)個(gè)節(jié)點(diǎn)在提供服務(wù)，比如服務(wù)器是32核,那單臺(tái)就是32個(gè)節(jié)點(diǎn)，3臺(tái)服務(wù)器就是96個(gè)節(jié)點(diǎn)在提供服務(wù)，可想而知，事實(shí)證明效果確實(shí)好了，基本都能夠正常進(jìn)入服務(wù)。
后端當(dāng)時(shí)優(yōu)化了springboot默認(rèn)容器由tomcat改為了undertow,修改了數(shù)據(jù)庫(kù)連接池的相關(guān)參數(shù)，代碼層面需求是根據(jù)用戶(hù)當(dāng)前的定位按照距離降序展示預(yù)約藥店列表，計(jì)算經(jīng)緯度的邏輯是數(shù)據(jù)庫(kù)計(jì)算的，因此請(qǐng)求會(huì)直接打到db，如圖所示：
后來(lái)思考了一種方案，將藥店id及經(jīng)緯度信息初始化存儲(chǔ)在redis里，用redis的geo數(shù)據(jù)結(jié)構(gòu)計(jì)算距離排序,測(cè)試下來(lái)接口響應(yīng)速度也確實(shí)提升了,代碼如下
nginx配置keepalive等參數(shù)配置,另外還發(fā)現(xiàn)流量高峰期間，tcp time-wait狀態(tài)數(shù)居高不下，因此查閱相關(guān)資料，針對(duì)服務(wù)器相關(guān)參數(shù)進(jìn)行如下優(yōu)化：
fs.file-max=102400? ?//系統(tǒng)可以打開(kāi)最大文件數(shù)量
net.ipv4.tcp_mem = 3097431 4129911 6194862 //tcp內(nèi)存大小
net.ipv4.tcp_rmem = 4096 87380 6291456? ?//tcp讀取緩沖區(qū)大小
net.ipv4.tcp_wmem = 4096 65536 4194304 //tcp發(fā)送緩沖區(qū)
net.ipv4.tcp_max_tw_buckets = 5000 //表示系統(tǒng)同時(shí)保持TIME_WAIT套接字的最大數(shù)量
net.ipv4.tcp_tw_recycle = 1 //表示開(kāi)啟TCP連接中TIME-WAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉。
net.ipv4.tcp_tw_reuse? = 1 //表示開(kāi)啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉
net.ipv4.tcp_syncookies? = 1 //#表示開(kāi)啟SYN Cookies。當(dāng)出現(xiàn)SYN等待隊(duì)列溢出時(shí)，啟用cookies來(lái)處理，可防范少量SYN攻擊，默認(rèn)為0，表示關(guān)閉；
net.ipv4.tcp_fin_timeout = 15 #表示如果套接字由本端要求關(guān)閉，這個(gè)參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時(shí)間。
net.ipv4.ip_local_port_range = 1024 65535 #表示用于向外連接的端口范圍。缺省情況下很?。?2768到61000，改為1024到65000
net.ipv4.tcp_max_syn_backlog = 8192 #表示SYN隊(duì)列長(zhǎng)度，默認(rèn)1024，改成8192，可以容納更多等待連接的網(wǎng)絡(luò)連接數(shù)。
net.ipv4.tcp_keepalive_time = 1200 //表示當(dāng)keepalive起用的時(shí)候，TCP發(fā)送keepalive消息的頻度。缺省是2小時(shí)，改為30分鐘
net.core.somaxconn? = 65535? //#Linux kernel參數(shù)，表示socket監(jiān)聽(tīng)的backlog(監(jiān)聽(tīng)隊(duì)列)上限
net.core.netdev_max_backlog? = 200000?#該參數(shù)決定了，網(wǎng)絡(luò)設(shè)備接收數(shù)據(jù)包的速率比內(nèi)核處理這些包的速率快時(shí)，允許送到隊(duì)列的數(shù)據(jù)包的最大數(shù)目。
另外機(jī)房的帶寬以及機(jī)房waf,流量限制(比如1分鐘有同一個(gè)ip大量訪問(wèn)了服務(wù)器，會(huì)被認(rèn)為ddos攻擊從而觸發(fā)拉入黑名單等防御措施)等，都需要協(xié)調(diào)相關(guān)人,相關(guān)資源去協(xié)調(diào)排查，排查系統(tǒng)瓶頸時(shí)監(jiān)控很重要,各中間件的性能指標(biāo)情況如nginx,redis,數(shù)據(jù)庫(kù)連接數(shù)，內(nèi)存等狀態(tài)都能提供很大幫助等。
