自建商城在設計之初，業務部門就提出了兩個要求：不崩 & 快速上線。
在立項之後，團隊還沒有完全配備好，一邊從其他團隊裏調取人手，一邊大力招聘，與此同時，我們的架構師也在搭建一套分佈式商城開發框架，編寫 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 後也能保持良好的性能。
參考：完美日記分享