會議思路
1.問題
2.原因眠菇、思路
3.方案
4.期待效果
問題 及 可能原因
1.接口響應(yīng)速度不行啊 ,響應(yīng)比較慢,菊花一直轉(zhuǎn)
后端處理代碼邏輯復(fù)雜
前端的“并發(fā)”請求太多
網(wǎng)絡(luò)弱,網(wǎng)速慢
2.首屏幕加載慢
- 接口邏輯多
- 圖片加載慢
3.頁面無響應(yīng)受理不及時,接口502.高并發(fā)下的受理不及時
- 問題主要出在數(shù)據(jù)庫服務(wù)器,寫入的量太大
4.內(nèi)容可配置
- 不同的渠道要的版本不同,今早預(yù)想和溝通,有些決策必須要需求方下達(dá)的
5.圖片加載緩慢
圖片都在CDN,七牛CDN響應(yīng)慢?
HTTP和HTTPS的差距?排除
圖片未壓縮 影響較大
圖片制作的時候盡量省一點,基準(zhǔn)分辨率選iPhone 2x,矢量圖距潘、具體大小要注意一點
6.H5的測試比較麻煩(已解決笋熬、忽略)
- 支付調(diào)試
- jssdk 坑多
業(yè)務(wù)相關(guān)的 bug
響應(yīng)慢的時候,出現(xiàn)了所謂“緩存版本”,再無新的更新.
需要時間處理邊界和異常情況
能統(tǒng)一的出一套統(tǒng)一的處理方案
方案
技術(shù)方案
三個方向優(yōu)化
前端的優(yōu)化,減少請求數(shù)量,前端緩存,減少短時間內(nèi)相同的請求
接口的優(yōu)化,多使用緩存,針對專門的“許愿池列表”的優(yōu)化
架構(gòu)的優(yōu)化, 業(yè)務(wù)架構(gòu)上的業(yè)務(wù)分離.服務(wù)、緩存荠察、數(shù)據(jù)庫的服務(wù)器 的 許愿等核心 業(yè)務(wù) 逐步遷移 ,青云響應(yīng)慢挑豌、故障率高,遷移到阿里云.運維上 - 物理架構(gòu) ,代碼發(fā)布機.
外部方案
討論或者提需求 至少要有文本性質(zhì)的記錄
需求提出后,需要少量的時間理解和思考技術(shù)方案,這個過程盡量多的互相溝通
運營需求,活動全流程需要更細(xì)致的規(guī)劃和思考,需求今早提出
UI,圖片壓縮,圖片格式,圖片大小按標(biāo)準(zhǔn)來
參考:
負(fù)載均衡:請求進(jìn)來先到負(fù)載均衡再到物理機 -- 分配請求
降級:丟棄掉一些不太重要的請求
