如何看待架構設計中的性能目標
最近參加的一次架構評審中，就性能目標的理解，有些同學的觀點很是特別，Ivan記錄下來與大家討論。考慮到敏感性，文中隱去了針對方案其他部分的討論。
該次評審的架構方案，簡單來說是為了提升幾個系統的報表查詢效率，而技術方案的核心是要增加某款資料庫的聯機服務集群，因為本文的重點不在於論述該資料庫的原理，為避免造成讀者對這款產品的誤解，我們給這個資料庫產品取個化名」DBX「。對方案進行講解的主要是兩位同學，我們稱為A君和B君。
該方案要解決的是目前報表查詢的效率問題，現狀是報表查詢大多延遲會在1分鐘以上，相當多的報表查詢延遲在5分鐘以上。方案提出的優化目標是，所有報表查詢要實現300tps/10秒延遲，從而提升用戶體驗。方案提出了三種措施，一是優化SQL，能夠批量完成的數據加工盡量不放在聯機查詢中；二是新建DBX集群，剝離聯機查詢服務，因為目前使用的DBX集群，同時承擔了批量和聯機任務，在批量尚未結束的情況下，聯機服務無法獲得更多的資源，從而大大降低了處理能力；三是升級DBX版本，廠商稱新版本中會提供更好的工作負載管理能力。
三項措施的核心是搭建新的DBX集群，一個焦點問題就落在了該資料庫的選型上。從DBX的架構特點上看，要達到方案設定的性能目標，Ivan還是有些擔心的。首先是處理能力和擴展性，雖然它是分散式架構，但在由於主節點是單點ACTIVE且要承載實際的工作負載，這意味著橫向擴展能力是受單機容量影響的。而本次方案的目標是支持多系統的報表查詢，未來希望擴展到所有報表查詢系統。其次是混合負載管理能力，因為目前已經涉及了跨系統的上千張報表，覆蓋了不同業務條線，業務重要性一定存在差異，同時由於不同項目組實現這些報表，SQL編寫水平參差不齊，質量差的代碼會浪費系統資源，這就要求DBX必須具備一定的混合負載管理能力（或者說是多租戶管理能力），而從目前在生產環境運行情況看，這正是DBX的一個缺陷。A君告訴大家DBX已經推出了新版本，可以更好的管理混合負載，大家可以放心，廠商說能夠管好。
討論到對tps和延遲的擔心時，有評委希望能夠看到更多產品架構分析或是壓測數據來支持這個目標的可行性。A君告訴我們其實100tps就可以了，這些報表沒有那麼頻繁的查詢，而B君的一句話更讓人大跌眼鏡，」10延遲達不到就達不到吧，20秒又怎麼樣，1分鐘又怎麼樣？「 此言真的是讓人震驚。一個系統的性能目標是否可以達成，是衡量系統架構設計是否成功的最重要指標，如果目標可以無限妥協，那對架構設計的任何討論都變得毫無意義。
這裡Ivan揣測一下，之所以能有這種言論，大概是因為這原本也就不是他們的設計目標。以最粗暴的方式來看，在一個性能表現不佳的集群（原規模40台）上增加十幾台機器，性能是不是會有提升，大概率是會的吧，資源投入多了嘛。我們再進一步，從物理上拆分出一個聯機集群，物理資源徹底隔離只做聯機查詢，這樣聯機查詢性能是不是能提升，幾乎是一定的吧。OK就這麼干吧。提升到什麼程度？大概就是比原來好就行吧。一定要個性能的目標嗎？我們來寫一個吧。咦？居然有人質疑，那我讓一下好了，你們可不要太過分哦。
對於一個不是太糟糕的系統，增加硬體資源大概率是能夠提升性能表現的。可這種粗放的方案，對所有參與者來說都是一種不光彩的記錄，如果總是能夠接受這樣的方式，架構師還有存在的必要嗎？而此時方案提出方的挑戰邏輯大體是這樣，你覺得不行你來呀，你不能只做評委，你也不能只是告訴我還有哪些的備選產品，你得幫我協調機器，你來做測試，總之你來完成這個任務呀。你做不到吧？我明明有辦法可以解決問題，你不同意，你就是阻礙生產力提升，我要去告訴老闆。
也許是存在操作層面的困難，此時作為一個應急方案是各方更能接受的選擇，但往往這種應急又會成為永久性方案的一個代名詞，原因在於最終方案的相關工作可能不會再有人去完成。這也算是架構評審的一個小小困局吧，不知道你是否也遇到過，歡迎有興趣的朋友留言。
很久以前，曾聽一位前輩告誡過，技術人員是要有「技術良知」的，哪怕是你處於售前的角色，也要緊守技術人員的底線，不要去過分配合某些銷售的吹噓，否則即使能夠僥倖贏得當前訂單，也會失去大多數客戶的信任。
這麼多年過去了，今天，突然想起了這個「技術良知」，好像又有了新的理解。
PS. 壓力測試應該在什麼階段進行？
討論過程中，某同學亂入了一個問題，壓力測試什麼時候都要求在架構評審前完成了？
當然，通常一個集成的解決方案（或者說是系統）壓力測試是無法在架構評審的階段完成的。原因是架構評審階段，系統仍然處在設計階段，開發尚未啟動或者剛剛啟動，一般沒有可運行的程序，尤其是對於瀑布式開發過程。
我們要說清楚壓力測試的對象是誰？集成系統和單一產品，是兩個完全不同的概念。在使用成熟產品時，業界對產品能力有共識，評審中也就不會再要求通過測試數據來說明，而這可能造成了某些開發者的錯覺。而本例中的DBX，就聯機處理能力和多租戶管理能力而言，都未得到過廣泛確認，在這種情況下獨立產品的壓測數據是需要的，而獨立技術產品應為與業務無關，也是具備測試條件的。
TAG:金融數士 |