支付寶程立：解讀架構重構的三個階段
原創IT架構師經常遇到的一個情況是：隨著企業業務的不斷發展，組織結構、業務需求和數據種類的不斷變革，原有的系統架構不再適應新的需求，必須要做全新的架構重建。這是一個復雜而系統的工程，和日常開發工作中的代碼重構相比，全局系統架構重構的難度、成本與風險會高許多，也缺乏普適的方法和成熟的工具的支持。
作為支付寶的***架構師，程立從2004年支付寶建設伊始就服務于該團隊，如今，支付寶已從最初的不足十人的技術團隊發展為擁有1000余技術人員的大集體，交易筆數也從每天1萬筆增長到1000萬筆。這樣的發展速度和規模對于支付寶的系統架構提出了很高的要求，幾年間，支付寶系統也經過了多次的架構重建。
10月23日，在QCon杭州2011全球企業開發大會的《***架構師的架構觀》專場上，程立與大家分享了他作為***架構師的一些心得和經驗。
架構重構的三個階段
程立說，架構重構通常會經歷三個階段：“壞味道”驅動的局部架構重構、基于規劃驅動的全局架構重構、和關于組織的整體的架構能力的重構。
支付寶現在是以第二階段“基于規劃驅動的全局架構重構”為主，但同時***階段的工作也在進行。至于“關于組織的整體的架構能力的重構”，難度比較大，仍是他們在探索和努力的方向。
在演講中，程立首先介紹了識別“架構壞味道”的幾個判斷標準，包括：研發效率不足，系統不穩定，新業務難以支持等。他同時提供了一些判定的細節依據(具體內容網友可在51CTO下載頻道下載程立演講的PPT和錄音http://down.51cto.com/data/270838)。
程立表示，在識別出“壞味道”并決定要做架構重構的時候，架構師應該制定一套機制，以判定新設立的架構方案是否適用。
不過，盡管有了各種評判標準和風險控制措施，基于壞味道的局部重構仍有它的風險，當系統需求達到一定程度之后，就需要來一次全局重構。
理解大規模系統，需要更宏觀的架構模型。它需要架構師有對業務、數據、應用、技術的多個視角，能描述多個視角之間的關系，并自頂向下，分而治之。
全局架構的運作對架構團隊提出了更高的要求。有時，你會發現原有的組織結構已經不適應這種新的工作方法，這時候，就需要在組織層面進行一些改進，這就是“更深層次的架構重構—架構組織與架構過程重構”。這一過程通常需要企業進行不斷的嘗試，找到最適合自己的方法。在支付寶，程立介紹說，他們嘗試了多種方式之后，最終確定了“架構委員會”的方法來統籌全局架構。“架構委員會”里會分為一個個的小項目運作，原來的“虛擬架構”的方式被弱化了，成為信息交流分享的平臺。
架構師和PM是密切協作關系
做架構重構時要非常小心，以免數據遺失造成損失，這是所有架構師都非常明確的一點。然而，有一個問題卻常常被忽略，那就是對于數據質量的處理。有一些數據可能并不直接涉及到系統運行，但是一旦你要對系統進行深入的數據挖掘和數據分析，你就會發現它們的重要性。由于遺失他們并不會對系統運行造成影響，有些架構師對此并不重視。從企業發展來看，這是很不利的。那么，如何避免這種現象的發生呢?
在回答51CTO記者提問時，程立表示“數據架構中要完整的考慮所有的問題，不能說運行中的數據才是數據。要看到全局架構組織的重要性，它不是單方面關注，不是只關注現在系統的運行，必須各個方面的人都有”。做全局架構是非常考驗架構師“理解力”的一個工作，需要架構團隊集思廣益，并借助各種工具來分析判斷，以免遺漏任何一個關鍵點。程立說“我們可能有的重構，發現數據倉庫的連接中斷了，這邊變更一個字段那邊沒有同步更新，這是整個團隊一個錯誤的問題。當你發現這樣問題，你必須加到你架構過程里去控制。確保這樣的問題不會再出現”。
然而，即使你開始的時候考慮的很周全，隨著企業業務的發展，新的需求不斷進來，可能一段時間后，你發現原來的架構“又”不夠用了那該怎么辦呢?程立表示，原有架構跟不上業務需求的發展，這是經常遇到的問題。開始的時候，我們可能通過不斷的“打補丁”來解決這一問題，而到一定階段之后，“補丁”已經不夠用了，那就需要再做一次重構。據程立介紹說，在支付寶，這項工作是被架構團隊作為一個常規工作存在的，每個季度，自上而下和自下而上都會提出一些架構評估的項目。評價委員會會對這些提議進行評估，看它的價值，看它的風險，確定優先級。如果通過的話就會發起立項。“基本上我們會有30%季度資源會持續放在這個事情上去”，程立說。
據程立介紹，支付寶架構團隊實際上只有五六位專職架構師，對于每一次架構建設的協作和進度掌控，都是有架構師團隊和PM來共同完成的。“架構師和PM是一個密切協作關系”，程立對51CTO記者說，“大型架構有很多PM來支持這個項目，可能會有一個項目群來掌握架構的進度，整個項目的進度”。針對有的朋友擔心架構會不會與系統底層脫節的問題，程立說“架構和底層不脫節，關鍵是團隊不能脫節”。
【編輯推薦】
