如果你是一位程式媛，你一定知道完美日記。
如果你是一位程式員，你的那個她一定知道完美日記。
今年雙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）業務中台化：建立業務中台，打通商品中心、庫存中心、使用者中心和交易中心；
為了更好的應對源源不斷的挑戰，以下崗位持續招聘中：
- Java開發工程師
- 前端開發工程師
- 測試工程師
**有意請發送履歷至郵箱：
作者資訊：
莊工：逸仙電商架構師&技術委員會負責人，負責完美日記商城基礎架構和微服務體系建設。
關工：逸仙電商後端技術專家，現主要參與微商城後端架構內建方案、以及性能調優和微商城技術規範管理。
唐工：逸仙電商技術經理，曾先後就職于中國航信和唯品會，現主要負責前後端技術統籌等打雜工作。