前言
本周六晚受邀，參加了由數列科技主辦的線下直播技術沙龍——高可用&性能技術沙龍。
分享過程中，參與沙龍的同學們提了很多問題，礙於很多問題口頭描述解釋不清，因此寫了這篇文章，對這些同學提出的問題做一個解答。
當然，回答僅限於我個人的角度，僅供參考。
課程回放：高可用&性能測試技術
Question
1、大數據平台性能測試工具推薦哪些？側重集群性能方面？@楊楊
2、什么場景適合做生產環境的全鏈路壓測？
3、如何定位性能瓶頸？@AIS.Chang
4、目前工作中，壓測環境更新維護成本特別高，有沒有環境維護方便建議優化的點？@饅頭大王.Manju
(背景：壓測環境資源有限，只能更新當前需求涉及的服務，但每次都會出現配置不對、缺少庫表字段的情況)
5、數據庫壓測有沒有什么好的建議？@新
6、壓測和生產環境不是同等配置，是否有方案或公式在結論中給出本次性能環境結果能否滿足上線要求？@Hinn
7、全鏈路不改造底層區分流量，數據庫不做影子庫，算全鏈路壓測么？@Hinn
8、只有測試團隊來做，全鏈路壓測可以實現怎么樣的模式？@Hinn
9、性能測試需要強烈的代碼能力么？@未名同學
10、kafka消費者服務怎么做性能測試和調優？@Aron
Answer
PS：由於很多問題的point都很類似，因此我會針對這些點抽取共性來答疑，請各位知悉。
1、全鏈路壓測相關問題......
1）什么場景適合做生產環境的全鏈路壓測？
- 全鏈路壓測不是銀彈，更不是萬能。它只適合某些具有特定業務需求的公司，能否實施取決於是否具有合適的組織管理能力和對應的技術架構；
- 一般來說小公司沒有特別復雜的業務場景和高並發，全鏈路壓測落地又是個比較復雜的技術工程，因此不是很建議小公司搞全鏈路壓測，特別是自研，我更推薦找成熟的商業產品，比如數列；
- 全鏈路壓測，特別是生產全鏈路壓測，成本和風險相對比較大，而且涉及到的底層改造等問題，需要合適的契機才能推動，否則會比較困難；
- 什么場景適合做生產全鏈路壓測？舉一些場景：線上故障頻發&性能穩定性問題凸出，業務場景復雜且調用鏈路比較長，基礎技術設施建設尚可，有高並發場景等，這些場景適合做全鏈路壓測；
2）只有測試團隊來做，全鏈路壓測可以實現怎么樣的模式？
這個問題可以從2個點來出發，試着探尋一下：
1）首先是技術儲備問題，一般來說測試團隊的開發運維架構能力相對較弱，而全鏈路壓測又需要基礎技術設施齊全，且需要合適的契機才能落地，需要自上而下的推動；
2）第二個是成本問題，自研的話就是造輪子，可能輪子更適合自己，但ROI需要評估；
看完上面2點，然后可以結合起來進行評估，是否有足夠的技術儲備，基礎技術設施建設是否齊全，是否有自上而下的推動，是否有足夠的成本預算等；
其次，全鏈路壓測如果不上生產進行，測試的結果最終和線上是有比較大的gap的。如果只能由測試團隊推動，我更建議在獨立等配的壓測環境進行單接口&單鏈路&混合鏈路壓測驗證。
3）全鏈路不改造底層區分流量，數據庫不做影子庫，算全鏈路壓測么？
首先回答問題：算。
業內對全鏈路壓測並沒有定性的標准解釋，在我看來全鏈路壓測這個概念如果能解決問題，它就是全鏈路壓測。
至於底層改造，流量識別和影子庫，有下面幾個方案可以參考：
- 底層改造：可以通過服務隔離&網絡隔離等手段，通過單獨的VPC和網關等設施來做到；
- 流量識別：可以通過特定發壓的流量引擎IP添加白名單，來解決流量識別問題；
- 影子庫表：業內有公司是通過生產庫表的特定字段來做區分，然后數據清洗來解決臟數據問題；
2、如何定位性能瓶頸？
性能問題定位和分析一直是個很大的topic，我的理解就是：具體問題具體解決。為什么這么說呢？
每個公司技術設施，流程各方面都不一樣，每個技術同學的技術棧和擅長的點也不同，更不要提業務場景的巨大差異。
這些都會影響所謂的“性能分析”。那么如何解決這個問題，下面幾個點可以參考：
- 經驗主義：通過大量的試錯實踐來快速分析；
- 自上而下：出問題從請求發起端開始排查，然后到網關-應用層-中間件緩存隊列-DB乃至於操作系統配置；
- 從局部到整體：性能問題往往是多個原因引起的，一個個快速判斷排除，最終找到根因。
3、數據庫壓測有沒有什么好的建議？
1）選擇專業合適的數據庫壓測工具；
2）壓測場景一定要選擇合適的，比如：
- 典型的讀場景：包括條件查、全表差、多表關聯等；
- 典型的寫場景：比如insert、update等；
- 考慮特殊場景：比如分庫分表垂直拆分和數據同步等情況；
- 匹配業務場景：DB最終還是要支撐業務的，挑選典型的業務場景來壓測；
4、性能測試需要強烈的代碼能力么？
老實說，性能測試做的多了，到了深水區是需要代碼能力的。
但性能測試又是一個需要廣度和深度的領域，比較卷（自己卷自己），精力有限。
因此我更推薦能做到代碼走查、code review、熟悉編程語言的基礎和一些特性，能做到CRUD就差不多了。
最后補充一句，性能測試其實路子挺窄的，測試開發是未來的方向，不要過於追求技術（聽聽就好）。
5、kafka消費者服務怎么做性能測試和調優？
這個問題挺有意思，我曾經面試時候也被問到過，先不回答如何壓測和調優，先看看下面幾點：
- 消息隊列的原理&生產者和消費者的特點（發送和訂閱消費）&隊列的特性（先進先出）；
- 具體的業務場景和壓測需求是什么？這個需要具體且明確；
想明白上述幾點，壓測和調優實際上就不是難題了（凡爾賽了）。。。。。。
其實有個更有意思的問題：如果生產環境MQ積壓了，需要快速恢復業務，你會怎么做？提問的同學可以考慮下這個問題，也許面試會問到哦。。。
6、大數據平台性能測試工具推薦哪些？側重集群性能方面？
- 首先，壓測工具的選型和特點，是否支持所謂大數據平台的協議或者特點；
- 其次，壓測需要的大量測試數據，是個需要考慮解決的問題；
- 然后，集群可以承載更大的負載，如何用工具發起這么大的負載（看低一點）；
提問的同學，可以自己思考並嘗試下。。。
7、目前工作中，壓測環境更新維護成本特別高，有沒有環境維護方便建議優化的點？
記得昨天回答這個問題的時候，我提到了下面幾點：
- 是否有CICD制品庫等比較成熟的技術體系？
- 環境管理維護是否有規范的的操作流程和明確的責任邊界？
- 自動化和審批流是否比較高效？
其實這個問題說到根本，就是單獨的壓測環境和生產如何等比配置、DDL變更及時性、代碼分支、快速發布擴容機制、壓測前的check機制（提測准入標准）等問題。
推薦看看這篇文章：線下環境為何不穩定？
8、壓測和生產環境不是同等配置，是否有方案或公式在結論中給出本次性能環境結果能否滿足上線要求？
首先回答問題：沒有方案和公式來證明測試結果能滿足線上要求！
昨天的分享中有提到過，線上線下環境的差異性帶來結果的不確定性，以及如何描述一個性能問題。如果環境配置等前置條件都不滿足，又怎么能保證數據的正確性呢？
- 性能測試的目的就是：探測瓶頸+容量規划；
- 壓測環境的壓測只能用來衡量系統的處理能力（TPS&RT&成功率等）；
- 新服務上線壓測主要是發現並解決明顯性能問題（沒加索引&慢SQL&緩存命中率&OOM&死鎖&超賣）；
- 長遠來說性能測試是穩定性保障的一個環節或者說一個部分。
結語
相比於3.20那一次的答疑，這次的有些問題，我反而沒有給出明確的答案，因為它們本身就沒有標准答案。
很多問題或者遇到的疑惑，需要大家自己去探索。正如我在分享的最后一個topic里講的：成長是一個閉環，需要學習-實踐-試錯-復盤-不斷優化。
上述的答疑中留了一些問題，相關同學如果感興趣，可以嘗試思考如何解決它們。
如果有機會，我們下次再見！
