「國貨之光」 完美日記的微服務實踐和優化思路

若是你是一位程序媛，你必定知道完美日記。
若是你是一位程序員，你的那個她必定知道完美日記。

今年雙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。

問題四：

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

# 優化思路：

1）充分利用 Nginx 的併發處理能力，Lua 腳本提供了強大的處理能力，將 Java 處理請求改成使用 OpenResty 接收；
2）接收到請求以後作好基本的校驗以後，使用 lua-resty-kafka 模塊異步發送到 Kafka；
3）Kafka 落盤到 HDFS 後，由 Spark 離線計算日誌數據；
4）後端接口獨立部署，實時數據統計調用接口設置更短的超時時間；

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

迭代

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

一、壓測

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

阿里雲上有個 PTS 的壓測工具，能夠直接導入 Jmeter 腳本，使用起來很方便，接下來講說咱們的使用步驟：

1）先是按過往一個月的用戶行爲日誌裏，找出用戶的路徑和每一個行爲的思考時間，作了一個大概的模型；
2）按照雙十一活動的運營節奏，定義了兩到三個場景；
3）使用 ECS 搭建 Jmeter 集羣，內網對接口進行施壓，目的是減小網絡開銷，讓請求都能打到後端服務器上；
4）觀察服務器的壓力，調節應用內存分配，再經過 PolarDB 性能分析，找出有性能瓶頸的 SQL 儘量地優化掉；
5）將 Jmeter 腳本導入到 PTS，關聯上數據庫和 ECS 機器的雲監控，設置好思考時間等相關的參數後施壓，能夠動態秒級調整壓力，生成的壓測報告就是咱們想要的結果，須要拿這個結果來進行下一步的限流控制。

二、限流

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）業務中臺化：創建業務中臺，打通商品中心、庫存中心、用戶中心和交易中心；

爲了更好的應對源源不斷的挑戰，如下崗位持續招聘中：

• Java開發工程師
• 前端開發工程師
• 測試工程師

有意請發送簡歷至郵箱：Lynn.Guo@yatsenglobal.com

做者信息：
莊工：逸仙電商架構師&技術委員會負責人，負責完美日記商城基礎架構和微服務體系建設。
關工：逸仙電商後端技術專家，現主要參與微商城後端框架集成方案、以及性能調優和微商城技術規範管理。
唐工：逸仙電商技術經理，曾前後就任於中國航信和惟品會，現主要負責先後端技術統籌等打雜工做。

---

本文做者：莊工、關工、唐工

閱讀原文

本文爲阿里雲內容，未經容許不得轉載。