Categories
程式開發

完美日記的微服務實踐和優化思路


如果你是一位程序媛,你一定知道完美日記。

如果你是一位程序員,你的那個她一定知道完美日記。

今年雙11,完美日記僅用28分鐘就超過了2018年雙11全天的銷售額,成為第一個登上天貓雙11彩妝榜首的國貨品牌。在這個遍地都是漂亮小姐姐、號稱男人(特指程序員)天堂的公司裡,擁有著一支什麼樣的基礎架構技術團隊,他們是如何在4 個月內籌建、上線電商平台的呢?本文將為您分享他們在實踐微服務過程遇到的難點和優化思路。

完美日記基礎架構技術團隊歡迎您的加入,移步文末,了解詳情。

起步

自建商城在設計之初,業務部門就提出了兩個要求:不崩 & 快速上線

在立項之後,團隊還沒有完全配備好,一邊從其他團隊裡調取人手,一邊大力招聘,與此同時,我們的架構師也在搭建一套分佈式商城開發框架,編寫Demo,讓新加入的同學能快速上手。

暴露問題

問題一:分佈式事務

為什麼會使用分佈式事務?

這個暫且可以歸因於快速上線,因為生成訂單會調用到商品服務扣減庫存,使用了分佈式事務解決了因為跨服務調用引起庫存超賣的問題,帶來的問題就是性能上的消耗。

問題二:數據庫壓力

在大促活動期間,有個實時統計是直接從業務庫上直接查詢統計的,運營部門的小姐姐在不斷地刷新,導致該接口上的壓力山大,而且沒有使用緩存,連SQL 查詢條件的時間都是動態的,導致DB 層的緩存也使用不上,每次請求都打到DB 上。

開發和測試環境是使用自建的 MySQL,生產環境使用的是 PolarDB,從阿里雲官網上看到:

  • 集群架構,計算與存儲分離
  • 讀寫分離

我們主觀地認為,只要我們使用了集群連接地址就會自動進行讀寫分離,但是實際上並沒有,後來發現在方法上顯式的指定只讀事務就有請求走到只讀節點上了。 @Transactional(readOnly = true)

# 優化思路

1)從 SQL 洞察和慢 SQL 裡找調用響應時間最長和頻度最高的 SQL;

2)結合代碼,能用緩存代替的直接處理掉,不用能緩存的優化查詢,結合阿里雲提供的優化分析工具,調整索引;

3)活動高峰時段,禁止分析統計類的查詢執行,臨時改代碼已經來不及了,幸虧 AHAS(阿里雲的一款限流降級產品) 的接口限流和 SQL 限流功能;

4)TP 和 AP 分離,避免分析類直接查詢到業務庫(這是一個比較漫長的過程)。

問題三:緩存壓力

除了前面所提到的分佈式事務之後,發現還有同事寫了使用 Keys 模糊查詢 Redis,直接導致 Redis 的 CPU 飆升嚴重,通過阿里雲提供的 Redis 管理工具可以很方便地查看到有哪些慢查詢。

另外一個低級錯誤,我們相信應該不是第一個,也不會是最後一個,本來要設置一個 Key 的過期時間,結果少寫了個 Unit 參數,第三個就變更偏移量了。

redisTemplate.opsForValue().set(key, value, offset)

# 為什麼我們花了10分鐘左右才解決?

1)慣性思維,review 代碼沒發現出來;

2)在錯誤日誌裡發現 Redisson 鎖失敗時,懷疑是 Redis 寫滿了;

3)使用阿里雲的工具去查大Key 時發現了Key 很大,但是直接在網頁查看值的時候只看到保存了一個字符,問題就出在這裡,因為RDS 管控台裡獲取到的值看起來是正確的,大概又過了2分鐘左右,我覺得不太對勁,然後登錄上去用redis-cli 查看,傻眼了,裡面塞滿了0x00。

完美日記的微服務實踐和優化思路 1

問題四

商城上線當月有一個促銷活動,因為瞬間進來的流量過大,小程序前端埋點事件上報的接口連接數爆了,商城實時數據統計調用了流量統計服務的接口,然而服務調用超時時間設置的是60s,導致過多請求積壓,CPU 突然飆升得很厲害。

# 優化思路

1)充分利用 Nginx 的並發處理能力,Lua 腳本提供了強大的處理能力,將 Java 處理請求改為使用 OpenResty 接收;

2)接收到請求之後做好基本的校驗之後,使用 lua-resty-kafka 模塊異步發送到 Kafka;

3)Kafka 落盤到 HDFS 後,由 Spark 離線計算日誌數據;

4)後端接口獨立部署,實時數據統計調用接口設置更短的超時時間;

經過以上改造之後,前端日誌上報服務單機處理能力由原來的 1K 提升 40K,那種如絲般順滑的體驗實在是太好了。

迭代

從當時的情形來看,針對雙11的活動做大動作調整代碼優化基本上是來不及了,離活動還有不到兩個星期的時間,即便改了,風險也很高。

1、壓測

作為一個新上線的項目,數據量還比較小,使用雲服務來搭建一套1比1的壓測環境還是比較容易的,在這個時間節點上,我們需要模擬真實的場景摸清楚目前的系統能承受多大的壓力,需要多少機器。

阿里雲上有個 PTS 的壓測工具,可以直接導入 Jmeter 腳本,使用起來很方便,接下來說說我們的使用步驟:

1)先是按過往一個月的用戶行為日誌裡,找出用戶的路徑和每個行為的思考時間,做了一個大概的模型;

2)按照雙十一活動的運營節奏,定義了兩到三個場景;

3)使用 ECS 搭建 Jmeter 集群,內網對接口進行施壓,目的是減少網絡開銷,讓請求都能打到後端服務器上;

4)觀察服務器的壓力,調節應用內存分配,再通過 PolarDB 性能分析,找出有性能瓶頸的 SQL 盡可能地優化掉;

5)將Jmeter 腳本導入到PTS,關聯上數據庫和ECS 機器的雲監控,設置好思考時間等相關的參數後施壓,可以動態秒級調整壓力,生成的壓測報告就是我們想要的結果,需要拿這個結果來進行下一步的限流控制。

2、限流

1)在接入AHAS 過程中,由於微商城項目當前版本接入的是spring-cloud-alibaba-dependencies-0.9.0.RELEASE版本來使用阿里雲的OSS 與SMS,在接入AHAS 後,需要對依賴Alibaba 版本的升級,涉及包括Nacos 配置中心與服務發現的升級和包路徑的命名變更修改;

2)在接入AHAS 的gateway 網關路由限流,採用的是SDK 接入方式,AHAS 採用了符合springboot-starter 特性的SDK 開發,這樣在我們微商城接入gateway 時只需要在項目POM 中加入spring -cloud-gateway-starter-ahas-sentinel,在接入gateway 的時候發現,網關路由限流採集上傳的API 出現了沒有兼容Restfull 風格API 的問題,導致URL 上出現參數時多個url沒有合併一起的情況,阿里雲AHAS 支持團隊立即發布Fix 版本,提供新的SentinelWebInterceptor 攔截器進行清洗Restful 風格API 處理;

3)在接入AHAS 的應用模塊限流,採用的也是SDK 接入方式,在按官網文檔進行接入的時候,發現我們微商城採用的是最新版本的Mybatis Plus 版本,在接入SQL 限流分析功能時發現出現ahas報錯,在將此反饋到ahas釘釘團隊支援群後,當時已經差不多凌晨一點了,ahas團隊的及時響應以及第二天早上就發布了兼容Mybatis Plus 版本的SQL 限流分析版本給到我們微商城,在我們接入新版本後,SQL 分析和限流功能也能正常使用了;

4)在使用AHAS 接入的時候,發現AHAS 除了接口的API 限流功能外,還提供了CPU/Load 的限流,對服務器性能情況的監控和保護做了很好的護航,在微商城服務器壓力過高時能夠很好的保護服務器不被高並發壓垮,保證了服務的高可用,同時在服務器壓力大的時候,做到了實時QPS 日誌上傳的隔離,避免上傳搶占服務器資源,保證了服務器在接入AHAS 後也能保持良好的性能。

未來

未來計劃要做的事情

1)按服務拆分 Redis;

2)數據庫讀寫分離、分庫分錶、TP/AP 分離;

3)業務中台化:建立業務中台,打通商品中心、庫存中心、用戶中心和交易中心;

作者介紹

莊工:逸仙電商架構師&技術委員會負責人,負責完美日記商城基礎架構和微服務體系建設。

關工:逸仙電商後端技術專家,現主要參與微商城後端框架集成方案、以及性能調優和微商城技術規範管理。

唐工:逸仙電商技術經理,曾先後就職於中國航信和唯品會,現主要負責前後端技術統籌等打雜工作。

本文轉載自公眾號阿里巴巴中間件(ID:Aliware_2018)。

原文鏈接

https://mp.weixin.qq.com/s/UjeAfZVz0l_-qyjyVYkB7A