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

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

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

總結

以上是生活随笔為你收集整理的“国货之光” 完美日记的微服务实践和优化思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。