原帖地址：
http://www.infoq.com/cn/articles/chengli-arch-agile-soa;jsessionid=C638EC13BCDA6E361A4DD74BFC2D601E
程立談架構、敏捷和SOA實踐
作者 霍泰穩 發布于 2008年7月17日 上午1時43分
據支付寶公司官方數據，截止到2008年5月6日，使用支付寶的全球用戶已經超過8000萬，支付寶每日交易總額超過3.5億人民幣，日交易筆數超過150萬筆。看到這兒，我想很多軟件開發者朋友可能會問的問題是：這么龐大的支付平臺是誰設計的，如何設計的，有什么經驗和教訓？在2008年5月份阿里巴巴舉辦的第二屆網絡工程師俠客行大會上，InfoQ中文站有幸認識了支付寶首席架構師程立先生，并邀請其分享了軟件架構設計心得，對當前熱門技術的看法，以及在自己團隊中對這些熱門技術的實踐經驗等。
InfoQ中文站：請給InfoQ中文站的讀者介紹一下您自己。
程立：InfoQ中文站的讀者，大家好，我叫程立，來自支付寶架構團隊。和大家一樣，我也是InfoQ的忠實讀者。從2004年起，我開始參與淘寶網與支付寶系統的建設，并于2005年正式加入支付寶，此后一直從事支付寶系統的研發工作。現階段，我的興趣在于適合電子支付行業的敏捷、高可用、可伸縮的面向服務架構與開放架構。非常高興InfoQ中文站提供了這樣的機會，讓我能夠代表支付寶的工程技術人員和大家進行交流，希望這樣的交流能增進我們的相互了解。
InfoQ中文站：支付寶技術架構的發展過程是什么樣的？
程立：三年多前的支付寶系統只有一個應用程序，而今天，僅僅在你點擊支付寶支付按鈕的一瞬間，取決于你選擇支付方式，很可能調動了數十個獨立的系統同時為你提供服務：有的幫你聯系銀行，有的幫你支付貨款，有的推進你的交易，有的幫你聯系商家發貨，有的警惕地盯著這一切，為這個過程保駕護航……支付寶系統從一個樸素的輕量級Java應用程序，發展到現在由很多自主的服務系統構成的全分布式系統，是一個朝著明確的方向、邁著小而快的步伐、與業務齊肩并進的發展過程。這個過程大致分為兩個大的階段。
第一階段是基于良好的業務邊界，將一根粗煙囪似的應用程序拆成若干個細一些的煙囪。這種切分方式，可以使應用程序間的通信盡量小，只有少量的頁面跳轉與組合，以及基于JMS的異步消息交換。這種簡單的分布就帶來一些相當直接的好處，如單個系統的復雜性降低了，研發的并行度提高了，每個系統可以單獨進行伸縮。公共的業務，比如賬務與交易的處理等，被實現成可共享的類庫，打包在每一個應用程序中，這樣，可以仍然使用單數據源上簡單、低成本的本地事務來保證業務處理所要求的原子性、一致性、隔離性與持久性。在這個階段，新業務只要是自成體系的，都盡量作為單獨的應用程序實現。
在第二階段，為了使業務核心更加專業化，前端應用能夠輕裝上陣，我們將原來類庫形式的業務核心一個接一個地拿出來，做成了自主的服務系統。這是一個充滿業務與技術挑戰的過程。僅從技術架構上說，為了使服務能夠快速構建、靈活擴展，我們研發了組件式平臺，使服務自身能夠通過插件式體系進行靈活擴展；為了提供電子支付業務所要求的嚴格事務一致性、快速響應與高并發處理能力，發展了分布式服務系統中事務協調技術；我們也發展了企業服務總線技術，以提供統一、易于功能擴展、滿足各種服務質量要求與集成模式的服務通信機制。每個服務系統連同它操作的數據都是一個自主的業務單元、系統單元與研發單元，很好地支持了業務模型創新、系統伸縮、研發組織小型化與專業化。
總體說來，雖然發展速度較快，但支付寶的技術架構仍然處于一個布局與打基礎的階段，對技術高度重視的態度，和緊緊抓住“服務”不放、持續小步快跑的執行策略，使我們在這個階段打下了一個良好的發展基礎。面對前方業務發展的巨大空間，架構與技術大有用武之地，在這里歡迎有志之士加入我們，共同開拓未來。
InfoQ中文站：請談一談您對架構的認識。
程立：老子說“道生一、一生二、二生三、三生萬物”。在業務愿景的技術實現過程中，假設“道”為愿景、一為方向、二為戰略的話，三就應該是架構了，架構既出，萬物化生可矣。戰略是整體的、長期的，讓架構直接承接戰略，帶來的最大好處是可以得到一個整體的可持續發展的系統平臺。而如果只是讓架構從屬于項目或者產品，很可能產生的系統也是煙囪型的，短視的。
這是支付寶公司內部對架構的定位。作為技術人員，常常遇到的問題是“提供一個X產品，它的流程為Y，高峰期處理量達到Z。”；也有一些問題的提法有所不同，比如“我們希望進入X市場，Y是我們的主要價值點，這個市場未來三年可能有Z倍的增長，系統能幫我們做什么？”。在我所在的團隊中，第二類問題總是由架構師出馬，而第一類問題，只要X、Y、Z不太離譜，基本不需要架構師操心。當然，如果現有架構難以支撐這個需求的話，那架構師也是責無旁貸的。
InfoQ中文站：一個成功的架構應該具備什么特點？
程立：架構必須能夠達到功能與質量要求，以合理的研發、運行與管理成本產生使客戶滿意的系統，這是一個基本要素，否則是不及格的。但僅僅滿足功能與質量要求的架構，還談不上成功。
在長距離賽跑中，能夠讓系統以輕松的步伐始終跑在業務前面，是成功架構的一個顯著特點。為了支持這幾年業務的快速發展，支付寶的每個重要子系統都歷經了若干個大的版本升級。這些升級有些是沿著事先規劃好的迭代式發展路線進行的，在保持整體架構穩定的情況下，通過增加功能、擴展數據模型、引入新的處理模式、不斷地擴展著功能與性能，持續給予業務強勁的支撐；但也有一些系統的升級則是接近于返工，架構重新設計、代碼重寫、數據模型重新設計、已有數據大遷移。路遙知馬力，雖然這些系統在上線的當時都達到了功能與質量要求，但時間可以判定架構成功與否。
成功架構的另一個顯著特點是能夠對公司的核心競爭力形成有力的支撐。最近，馬云先生在一次公開演講中，舉了一個例子，沃爾瑪要增加一萬個買家，需要買面積巨大的地，需要買很多的設備，需要很多的倉儲；而淘寶只需要增加一臺電腦就可以了。這個優勢是商業模式帶來的，但其背后，是需要有一個高度可伸縮的技術架構來支撐的。
InfoQ中文站：如何最大限度避免一個架構設計的失敗？
程立：首先說點外因，架構設計的失敗不全是架構師的責任。假如一個企業戰略不清，或者雖然定義了清晰的戰略，但沒有很好的溝通機制讓架構師了解戰略，很難設計出全局上下一盤棋、富有生命力的架構。當發現看不清全局、看不清未來時，架構師應該設法多溝通、推動改進。如果始終推而不進、溝而不通，就該考慮換個舞臺去發展了。不過，對于處于創業期的企業，這一條不大適用，這類企業中，架構發展與業務發展在開始階段往往是一個快速犯錯、快速調整的試錯過程，這樣的企業走向成功的同時，也常常能夠培養出好的架構師。
在做架構設計時必須以業務為本。不是說讓架構師去摳業務的枝節，比如流程中的某個環節究竟應該有幾個分支、或者某個業務參數應該是多少，而是將精力放在理解業務本質，看清不同業務之間的關系上。在一個業務思想混亂的頭腦中產生的系統也一定是結構模糊、行為混亂的。
業務清晰之后，架構師就像導演讀透了劇本，可以在腦海中構思與創作了。擬定時空結構、選擇風格樣式、物色演員、規劃每一幕的內容以及幕與幕之間的銜接等等。待一切可以在頭腦中栩栩如生、流暢地上演之后，架構其實就出來了。這一步工作做得是好是壞，主要取決于架構師長期以來積累的能力、知識與素養，沒有太多的捷徑。
有幾個算不上新鮮的經驗還是值得提一下。首先，架構師要建立自己的QA工具，比如一個質量檢查表，能夠全方位地從研發、運行、管理等維度，對架構的質量屬性進行客觀地評估，這個檢查表中各項指標的值范圍與權重需要針對實際情況進行個性化定制。到了一個新環境中的架構師往往需要一個適應期，在這個適應期中除了熟悉新公司的現有業務與系統之外，很重要的一個工作就是調整原來的質量評估體系，使之新公司的業務相匹配。其次，在架構師頭腦中的虛擬舞臺上，演員是一個個系統，對每種系統的能力與特性的理解會決定他構思出來的劇情在真實上演時能在多大程度上符合期望，這需要在實踐中關注并積累，如果引入了全新的演員，一定得讓他試鏡。還有一個是習慣問題：不要把腦海中出現的第一個設計當作最終版本，只要時間允許，要多創作幾個版本，其間多與同事討論、做些換換腦筋的事，避免陷于某種定式跳不出來。這需要架構師養成習慣，也需要公司研發流程的支持，比如讓架構師盡量早地介入項目，有充分的時間醞釀與斟酌。
最后，架構設計不可能不犯錯，因此很重要一點是當發現架構設計有錯誤時，一定不要嘗試掩蓋或者固執地堅持自己的錯誤，調整得越早，付出的代價就越低。好的企業一定有一個非常寬容的氛圍、允許犯錯并且鼓勵及時改正。我曾經有過幾次在開發已經進行到三分之一甚至更久時，發現架構設計有嚴重缺陷的經歷，由于及時調整，加上團隊的理解與配合，最終項目仍然取得成功，因此對這一點感受很深。
InfoQ中文站：在支付寶的技術團隊中，也采用了敏捷的方法，請談談這方面的經驗。
程立：支付寶的研發體系是從自身實際出發制定的，既要保障產品的高品質，又要保持對業務變化的快速響應，加上協調多個團隊高度并行開發的需要，整套研發體系是一個精心設計的嚴謹結構，也是比較重量型的。但我們還是可以從中找到敏捷方法中的一些重要元素。
首先談談迭代。這里，以我所熟悉的支付寶架構團隊的研發模式舉一些例子。之前提到，支付寶技術架構是采用與業務發展齊肩并進的策略，這個過程就像給F1比賽中的賽車換輪胎，所有架構改進的實施必須安全、快速，盡量不打斷正常的產品研發的節奏。因此，在確定技術架構的基本發展方向或者基礎設施產品的藍圖之后，我們會將研發工作切分成很短的迭代，每一個迭代的目標明確，一般只解決少數幾個技術問題。
以引入企業服務總線為例，第一個迭代的任務是調研，目標是概念驗證與產品選型；第二個迭代是試水，我們選擇了一個新的業務產品作為服務總線應用的小白鼠，當時的目標是解決高可用部署模式問題、以及集成邏輯的統一管理問題，架構師進入到該項目中，通過服務總線提供該產品與其它系統的集成方案，這個迭代與新產品發布的同時完成；以后的迭代是一系列推廣使用的迭代，幾次之后，我們完全替換了原來不夠靈活的商用JMS服務器集群，并且整個技術團隊可以不依賴架構組使用服務總線了；再以后的迭代是服務總線的自身的改進，如QoS的改進、服務治理功能的增加等等。采用這種方式，每一次迭代都有實際可運行的產出，并且其結果可以作為選擇下一輪迭代目標的依據。以這種模式，架構發展以一種穩健的方式小步快跑著。但與有些敏捷方法學建議的固定迭代時長有些不同，當“搭順風車”時，是宿主項目的規模決定迭代的時長。
保證高效的溝通是另一個重要的問題，這通常是采用我們俗稱為“閉關”的形式來解決的。項目上到一定規模，就會包下一個會議室，項目經理、架構、系分、開發、測試等人員都會坐在一起，保持溝通的高效率，也減少不必要的干擾。對于長周期的項目、或者需求難以在初期完全確定時，在一個項目內部也設計一些迭代，開發人員增量地交付功能，測試并行進行功能驗證，暢通無阻的溝通以及項目經理在場的協調管理是這種工作模式能夠順暢運轉的關鍵。
InfoQ中文站：阿里巴巴和淘寶網的很多架構也是基于SOA的，請談一下選擇和實施SOA的前因后果。
程立：支付寶早期的單一應用程序架構只存在了很短一段時間就受到了挑戰。
首先對這種架構發起挑戰的是團隊組織結構與分工的變化。隨著業務領域的拓展，并行的項目越來越多，研發團隊也迅速擴大，為了使團隊更好地配合業務，走向專業化，我們內部開始按照業務線分組。跨組之間的溝通成本的提高要求必須將各自負責的系統嚴格切開，降低相互間的耦合度。
另一個挑戰與支付寶業務特點密切相關。作為互聯網上的新型服務，必須快速變化才能滿足需要，曾經有很長一段時間，我們保持每周兩次的新版本發布速度；而作為電子支付服務，它又必須絕對可靠、高度可用。為了解決這個穩定與快速的矛盾，我們必須將系統中的業務核心獨立出來，由專業的團隊、通過更嚴格的研發體系來支持它的發展；前端應用程序則繼續以互聯網速度高速發展。
業務、技術、管理上同時提出了解耦的需要，而“服務”很好地統一了這三者，所以，選擇SOA作為技術架構的發展方向是很自然的。
現在，我們已經圍繞著公司的基礎業務建設了幾大核心服務系統，并且搭建了以 ESB 為骨干、以服務框架為基礎的面向服務基礎設施。太極拳中講究腰功，拳論中說“腰為主宰，腰為軸，刻刻留意在腰間”。這些核心服務以及配套的基礎設施很像支付寶系統的“活腰”，它們的高可靠與高可用性是支付寶系統整體穩定性的基礎，它們的靈活性與可重用性支持前端業務有條不紊地創新、整合與優化，它們的可伸縮性保證了系統能夠支撐持續的快速業務增長。
InfoQ中文站：現在你們也對外開放了很多服務，在架構設計上有做特殊的考慮，或者經驗嗎？
程立：支付寶很早就提供了外部API，為互聯網上的電子商務提供安全交易與資金流解決方案。現在支付寶已有上百個開放的API服務，連接了數十萬大大小小的商戶系統。
我們覺得設計開放API平臺的思路與基于SOA原則進行架構設計很相似：業務上，需要理順業務關系、劃分清晰的企業業務邊界、并制定業務處理規范；從技術上說，需要制定統一的技術標準、建設統一的通信基礎設施。由于新產品會不斷推出，因此，支付寶在內部建立了一個API容器，方便擴展新產品。將SOA搬到互聯網上，SOA體系中固有的一些問題，如安全性、可靠性、接口契約的穩定性等問題就會被放大，在架構設計與標準制定時，必須很好地考慮這些問題。
出于安全與合規的需要，支付寶在制定API的業務規范與技術標準時，特別關注身份與安全體系；安全與方便是一對矛盾，為了更好地處理這兩者的關系，支付寶在架構上支持靈活的安全體系，可以根據業務特性與商戶個性需要，在安全性與方便性之間進行折衷。
互聯網上系統交互的非可靠性與交易與支付類業務的可靠性要求之間也是一對矛盾，因此，接口標準與統一的通信基礎設施中我們針對可靠性進行了專門的設計。
從接口契約穩定性上說，我們當時的做法是將技術標準設計成允許API接口增加新參數，提供版本參數，提供API接口的個性化配置能力，允許商戶定義一部分API上交換的數據與處理行為等。
隨著支付寶業務領域不斷拓展，原來的從需求->解決方案->產品->API的方式，周期太長，已經難以快速滿足大量合作伙伴的需求。因此，支付寶現在正在由產品式的開放轉向平臺式服務的開放，通過加強開放基礎設施的建設，向合作伙伴提供更基礎、更可重用、更體系化的服務，達到與合作伙伴充分協同，建設繁榮、共贏的電子商務生態圈的目標。同時，開放的業務服務與開放的技術平臺也正在推動支付寶的業務與技術架構向前發展，對構建更大規模的分布式系統、更大規模的并行研發模式都帶來了積極而深遠的影響。
InfoQ中文站：我們知道，支付寶的架構平臺中采用了不少開源系統，為何作此選擇？
程立：除了支付寶與阿里巴巴集團自主研發的很多基礎系統與開發框架、以及一些商業系統之外，支付寶也使用了很多優秀的開源軟件。具有蓬勃的生命力的開源軟件對支付寶的技術體系是一個很重要的補充。
在某些領域，一些開源軟件幾乎已經是事實的標準了，它們的高質量也是經過社區的嚴格考驗的，比如Spring和它的POJO編程模型。通過使用這些開源軟件，不但讓系統可以在開始階段就站在一個比較高的起點上，而且對于加入團隊的新同事，一開始就可以在一個相對熟悉的環境下工作。
在另一些尚未形成標準的領域，在產品選型階段，我們一般會在開源系統與商業產品間進行細致地選型，必須能夠滿足業務所要求的主要功能特性與關鍵質量要求。在同樣能夠滿足主要功能特性與關鍵質量要求的前提下，誰具有良好的可擴展性，誰更簡單，誰具有長期發展的生命力，誰有好的服務支持，都是最后做出選擇的重要因素。其中，可擴展性往往是一個選擇的關鍵因素。基于社區集體貢獻模式的開源軟件在可擴展性方面往往做得很好。當業務發展到一定階段，在技術上一定會有大量個性化的需求，所選擇的系統必須能夠支持快速滿足這些需求。開放的源代碼也使我們在問題響應時，具有更大的主動性。隨著開源系統走向商業化運作，在服務支持方面也開始做得更好，這些都進一步增加了開源系統的競爭力。
InfoQ中文站：請談一下當前架構師所面臨的挑戰。
程立：“瞻前”、“顧后” ――這是我現在體會到的最大挑戰。
先談談“瞻前”。當業務個性不明顯、業務規模也不大時，架構師還是有很多容易模仿的定式與先例的。但當業務的個性與規模到達一定階段時，一定會有一些別人從未遇到過的非常困難的問題需要你去解決。作為站在企業技術金字塔塔尖上的一群人，當過去的經驗用不上，搜索引擎也不能向你提供任何有用的答案，只有獨立去思考，去做出重大決定時，如果沒有充分的準備，對企業對個人都是巨大的風險。這需要架構師建立未雨綢繆的意識，不斷推演未來可能的變化并思索應對之策，持續而有方向地積累知識、發展能力，建立廣泛的技術交流圈子，并且“顧后”。
再談談“顧后”。架構師的另一個重要的職責是發掘團隊中的好苗子，幫助他們，使他們趕上并超越自己。無論這一點是否寫入你的KPI，這樣做都是必須的。站在架構師的立場看，架構必須有一個好的技術梯隊一層層傳遞下去，才能夠有效、持續地貫徹執行，如果只是架構師們沖在前面，背后空了一大片，架構永遠只能停留在藍圖上。站在企業的立場看，企業真正的技術實力，不在于已經有怎樣的系統或者平臺，而在于是否有一個強大而有生命力的技術團隊，通過快速復制架構師的技術與經驗，可以幫助發展并壯大這樣的團隊，而企業整體技術實力的提升也促進了架構師提升。
程立，支付寶（中國）網絡技術有限公司。2004年開始參與淘寶網與支付寶系統的建設，2005年起進入支付寶，一直從事于互聯網電子支付系統的研發工作。現任支付寶首席架構師，專注于電子支付系統的分布式服務架構與開放架構。
注：支付寶數據架構師馮大輝，InfoQ中文站編輯郭曉剛、賴翥翔和劉申對本文亦有貢獻
相關活動：7月26日QClub杭州站──程立與您分享“當SOA遭遇現實”的心得