程立談架構(gòu)、敏捷和SOA實踐

作者 霍泰穩(wěn) 發(fā)布于 2008年7月17日 上午1時43分

社區(qū)

Architecture,

Agile,

SOA

主題

SOA平臺,

企業(yè)級敏捷

標簽

SOA實施

據(jù)支付寶公司官 方數(shù)據(jù)，截止到2008年5月6日，使用支付寶的全球用戶已經(jīng)超過8000萬，支付寶每日交易總額超過3.5億人民幣，日交易筆數(shù)超過150萬筆。看到這 兒，我想很多軟件開發(fā)者朋友可能會問的問題是：這么龐大的支付平臺是誰設計的，如何設計的，有什么經(jīng)驗和教訓？在2008年5月份阿里巴巴舉辦的第二屆網(wǎng) 絡工程師俠客行大會上，InfoQ中文站有幸認識了支付寶首席架構(gòu)師程立先生，并邀請其分享了軟件架構(gòu)設計心得，對當前熱門技術(shù)的看法，以及在自己團隊中 對這些熱門技術(shù)的實踐經(jīng)驗等。

InfoQ中文站：請給InfoQ中文站的讀者介紹一下您自己。

程立：InfoQ中文站的讀者，大家好，我叫程立，來自支付寶架構(gòu)團隊。和大家一樣，我也是InfoQ的忠實讀 者。從2004年起，我開始參與淘寶網(wǎng)與支付寶系統(tǒng)的建設，并于2005年正式加入支付寶，此后一直從事支付寶系統(tǒng)的研發(fā)工作。現(xiàn)階段，我的興趣在于適合 電子支付行業(yè)的敏捷、高可用、可伸縮的面向服務架構(gòu)與開放架構(gòu)。非常高興InfoQ中文站提供了這樣的機會，讓我能夠代表支付寶的工程技術(shù)人員和大家進行 交流，希望這樣的交流能增進我們的相互了解。

InfoQ中文站：支付寶技術(shù)架構(gòu)的發(fā)展過程是什么樣的？

程立：三年多前的支付寶系統(tǒng)只有一個應用程序，而今天，僅僅在你點擊支付寶支付按鈕的一瞬間，取決于你選擇支付 方式，很可能調(diào)動了數(shù)十個獨立的系統(tǒng)同時為你提供服務：有的幫你聯(lián)系銀行，有的幫你支付貨款，有的推進你的交易，有的幫你聯(lián)系商家發(fā)貨，有的警惕地盯著這 一切，為這個過程保駕護航……支付寶系統(tǒng)從一個樸素的輕量級Java應用程序，發(fā)展到現(xiàn)在由很多自主的服務系統(tǒng)構(gòu)成的全分布式系統(tǒng)，是一個朝著明確的方 向、邁著小而快的步伐、與業(yè)務齊肩并進的發(fā)展過程。這個過程大致分為兩個大的階段。

第一階段是基于良好的業(yè)務邊界，將一根粗煙囪似的應用程序拆成若干個細一些的煙囪。這種切分方式，可以使應用程序間的通信盡量小，只有少量的頁面跳 轉(zhuǎn)與組合，以及基于JMS的異步消息交換。這種簡單的分布就帶來一些相當直接的好處，如單個系統(tǒng)的復雜性降低了，研發(fā)的并行度提高了，每個系統(tǒng)可以單獨進 行伸縮。公共的業(yè)務，比如賬務與交易的處理等，被實現(xiàn)成可共享的類庫，打包在每一個應用程序中，這樣，可以仍然使用單數(shù)據(jù)源上簡單、低成本的本地事務來保 證業(yè)務處理所要求的原子性、一致性、隔離性與持久性。在這個階段，新業(yè)務只要是自成體系的，都盡量作為單獨的應用程序?qū)崿F(xiàn)。

在第二階段，為了使業(yè)務核心更加專業(yè)化，前端應用能夠輕裝上陣，我們將原來類庫形式的業(yè)務核心一個接一個地拿出來，做成了自主的服務系統(tǒng)。這是一個 充滿業(yè)務與技術(shù)挑戰(zhàn)的過程。僅從技術(shù)架構(gòu)上說，為了使服務能夠快速構(gòu)建、靈活擴展，我們研發(fā)了組件式平臺，使服務自身能夠通過插件式體系進行靈活擴展；為 了提供電子支付業(yè)務所要求的嚴格事務一致性、快速響應與高并發(fā)處理能力，發(fā)展了分布式服務系統(tǒng)中事務協(xié)調(diào)技術(shù)；我們也發(fā)展了企業(yè)服務總線技術(shù)，以提供統(tǒng) 一、易于功能擴展、滿足各種服務質(zhì)量要求與集成模式的服務通信機制。每個服務系統(tǒng)連同它操作的數(shù)據(jù)都是一個自主的業(yè)務單元、系統(tǒng)單元與研發(fā)單元，很好地支 持了業(yè)務模型創(chuàng)新、系統(tǒng)伸縮、研發(fā)組織小型化與專業(yè)化。

總體說來，雖然發(fā)展速度較快，但支付寶的技術(shù)架構(gòu)仍然處于一個布局與打基礎的階段，對技術(shù)高度重視的態(tài)度，和緊緊抓住“服務”不放、持續(xù)小步快跑的 執(zhí)行策略，使我們在這個階段打下了一個良好的發(fā)展基礎。面對前方業(yè)務發(fā)展的巨大空間，架構(gòu)與技術(shù)大有用武之地，在這里歡迎有志之士加入我們，共同開拓未 來。

InfoQ中文站：請談一談您對架構(gòu)的認識。

程立：老子說“道生一、一生二、二生三、三生萬物”。在業(yè)務愿景的技術(shù)實現(xiàn)過程中，假設“道”為愿景、一為方 向、二為戰(zhàn)略的話，三就應該是架構(gòu)了，架構(gòu)既出，萬物化生可矣。戰(zhàn)略是整體的、長期的，讓架構(gòu)直接承接戰(zhàn)略，帶來的最大好處是可以得到一個整體的可持續(xù)發(fā) 展的系統(tǒng)平臺。而如果只是讓架構(gòu)從屬于項目或者產(chǎn)品，很可能產(chǎn)生的系統(tǒng)也是煙囪型的，短視的。

這是支付寶公司內(nèi)部對架構(gòu)的定位。作為技術(shù)人員，常常遇到的問題是“提供一個X產(chǎn)品，它的流程為Y，高峰期處理量達到Z。”；也有一些問題的提法有 所不同，比如“我們希望進入X市場，Y是我們的主要價值點，這個市場未來三年可能有Z倍的增長，系統(tǒng)能幫我們做什么？”。在我所在的團隊中，第二類問題總 是由架構(gòu)師出馬，而第一類問題，只要X、Y、Z不太離譜，基本不需要架構(gòu)師操心。當然，如果現(xiàn)有架構(gòu)難以支撐這個需求的話，那架構(gòu)師也是責無旁貸的。

InfoQ中文站：一個成功的架構(gòu)應該具備什么特點？

程立：架構(gòu)必須能夠達到功能與質(zhì)量要求，以合理的研發(fā)、運行與管理成本產(chǎn)生使客戶滿意的系統(tǒng)，這是一個基本要素，否則是不及格的。但僅僅滿足功能與質(zhì)量要求的架構(gòu)，還談不上成功。

在長距離賽跑中，能夠讓系統(tǒng)以輕松的步伐始終跑在業(yè)務前面，是成功架構(gòu)的一個顯著特點。為了支持這幾年業(yè)務的快速發(fā)展，支付寶的每個重要子系統(tǒng)都歷 經(jīng)了若干個大的版本升級。這些升級有些是沿著事先規(guī)劃好的迭代式發(fā)展路線進行的，在保持整體架構(gòu)穩(wěn)定的情況下，通過增加功能、擴展數(shù)據(jù)模型、引入新的處理 模式、不斷地擴展著功能與性能，持續(xù)給予業(yè)務強勁的支撐；但也有一些系統(tǒng)的升級則是接近于返工，架構(gòu)重新設計、代碼重寫、數(shù)據(jù)模型重新設計、已有數(shù)據(jù)大遷 移。路遙知馬力，雖然這些系統(tǒng)在上線的當時都達到了功能與質(zhì)量要求，但時間可以判定架構(gòu)成功與否。

成功架構(gòu)的另一個顯著特點是能夠?qū)镜暮诵母偁幜π纬捎辛Φ闹巍Ｗ罱R云先生在一次公開演講中，舉了一個例子，沃爾瑪要增加一萬個買家，需要 買面積巨大的地，需要買很多的設備，需要很多的倉儲；而淘寶只需要增加一臺電腦就可以了。這個優(yōu)勢是商業(yè)模式帶來的，但其背后，是需要有一個高度可伸縮的 技術(shù)架構(gòu)來支撐的。

InfoQ中文站：如何最大限度避免一個架構(gòu)設計的失敗？

程立：首先說點外因，架構(gòu)設計的失敗不全是架構(gòu)師的責任。假如一個企業(yè)戰(zhàn)略不清，或者雖然定義了清晰的戰(zhàn)略，但 沒有很好的溝通機制讓架構(gòu)師了解戰(zhàn)略，很難設計出全局上下一盤棋、富有生命力的架構(gòu)。當發(fā)現(xiàn)看不清全局、看不清未來時，架構(gòu)師應該設法多溝通、推動改進。 如果始終推而不進、溝而不通，就該考慮換個舞臺去發(fā)展了。不過，對于處于創(chuàng)業(yè)期的企業(yè)，這一條不大適用，這類企業(yè)中，架構(gòu)發(fā)展與業(yè)務發(fā)展在開始階段往往是 一個快速犯錯、快速調(diào)整的試錯過程，這樣的企業(yè)走向成功的同時，也常常能夠培養(yǎng)出好的架構(gòu)師。

在做架構(gòu)設計時必須以業(yè)務為本。不是說讓架構(gòu)師去摳業(yè)務的枝節(jié)，比如流程中的某個環(huán)節(jié)究竟應該有幾個分支、或者某個業(yè)務參數(shù)應該是多少，而是將精力放在理解業(yè)務本質(zhì)，看清不同業(yè)務之間的關系上。在一個業(yè)務思想混亂的頭腦中產(chǎn)生的系統(tǒng)也一定是結(jié)構(gòu)模糊、行為混亂的。

業(yè)務清晰之后，架構(gòu)師就像導演讀透了劇本，可以在腦海中構(gòu)思與創(chuàng)作了。擬定時空結(jié)構(gòu)、選擇風格樣式、物色演員、規(guī)劃每一幕的內(nèi)容以及幕與幕之間的銜 接等等。待一切可以在頭腦中栩栩如生、流暢地上演之后，架構(gòu)其實就出來了。這一步工作做得是好是壞，主要取決于架構(gòu)師長期以來積累的能力、知識與素養(yǎng)，沒 有太多的捷徑。

有幾個算不上新鮮的經(jīng)驗還是值得提一下。首先，架構(gòu)師要建立自己的QA工具，比如一個質(zhì)量檢查表，能夠全方位地從研發(fā)、運行、管理等維度，對架構(gòu)的 質(zhì)量屬性進行客觀地評估，這個檢查表中各項指標的值范圍與權(quán)重需要針對實際情況進行個性化定制。到了一個新環(huán)境中的架構(gòu)師往往需要一個適應期，在這個適應 期中除了熟悉新公司的現(xiàn)有業(yè)務與系統(tǒng)之外，很重要的一個工作就是調(diào)整原來的質(zhì)量評估體系，使之新公司的業(yè)務相匹配。其次，在架構(gòu)師頭腦中的虛擬舞臺上，演 員是一個個系統(tǒng)，對每種系統(tǒng)的能力與特性的理解會決定他構(gòu)思出來的劇情在真實上演時能在多大程度上符合期望，這需要在實踐中關注并積累，如果引入了全新的 演員，一定得讓他試鏡。還有一個是習慣問題：不要把腦海中出現(xiàn)的第一個設計當作最終版本，只要時間允許，要多創(chuàng)作幾個版本，其間多與同事討論、做些換換腦 筋的事，避免陷于某種定式跳不出來。這需要架構(gòu)師養(yǎng)成習慣，也需要公司研發(fā)流程的支持，比如讓架構(gòu)師盡量早地介入項目，有充分的時間醞釀與斟酌。

最后，架構(gòu)設計不可能不犯錯，因此很重要一點是當發(fā)現(xiàn)架構(gòu)設計有錯誤時，一定不要嘗試掩蓋或者固執(zhí)地堅持自己的錯誤，調(diào)整得越早，付出的代價就越 低。好的企業(yè)一定有一個非常寬容的氛圍、允許犯錯并且鼓勵及時改正。我曾經(jīng)有過幾次在開發(fā)已經(jīng)進行到三分之一甚至更久時，發(fā)現(xiàn)架構(gòu)設計有嚴重缺陷的經(jīng)歷， 由于及時調(diào)整，加上團隊的理解與配合，最終項目仍然取得成功，因此對這一點感受很深。

InfoQ中文站：在支付寶的技術(shù)團隊中，也采用了敏捷的方法，請談談這方面的經(jīng)驗。

程立：支付寶的研發(fā)體系是從自身實際出發(fā)制定的，既要保障產(chǎn)品的高品質(zhì)，又要保持對業(yè)務變化的快速響應，加上協(xié)調(diào)多個團隊高度并行開發(fā)的需要，整套研發(fā)體系是一個精心設計的嚴謹結(jié)構(gòu)，也是比較重量型的。但我們還是可以從中找到敏捷方法中的一些重要元素。

首先談談迭代。這里，以我所熟悉的支付寶架構(gòu)團隊的研發(fā)模式舉一些例子。之前提到，支付寶技術(shù)架構(gòu)是采用與業(yè)務發(fā)展齊肩并進的策略，這個過程就像給 F1比賽中的賽車換輪胎，所有架構(gòu)改進的實施必須安全、快速，盡量不打斷正常的產(chǎn)品研發(fā)的節(jié)奏。因此，在確定技術(shù)架構(gòu)的基本發(fā)展方向或者基礎設施產(chǎn)品的藍 圖之后，我們會將研發(fā)工作切分成很短的迭代，每一個迭代的目標明確，一般只解決少數(shù)幾個技術(shù)問題。

以引入企業(yè)服務總線為例，第一個迭代的任務是調(diào)研，目標是概念驗證與產(chǎn)品選型；第二個迭代是試水，我們選擇了一個新的業(yè)務產(chǎn)品作為服務總線應用的小 白鼠，當時的目標是解決高可用部署模式問題、以及集成邏輯的統(tǒng)一管理問題，架構(gòu)師進入到該項目中，通過服務總線提供該產(chǎn)品與其它系統(tǒng)的集成方案，這個迭代 與新產(chǎn)品發(fā)布的同時完成；以后的迭代是一系列推廣使用的迭代，幾次之后，我們完全替換了原來不夠靈活的商用JMS服務器集群，并且整個技術(shù)團隊可以不依賴 架構(gòu)組使用服務總線了；再以后的迭代是服務總線的自身的改進，如QoS的改進、服務治理功能的增加等等。采用這種方式，每一次迭代都有實際可運行的產(chǎn)出， 并且其結(jié)果可以作為選擇下一輪迭代目標的依據(jù)。以這種模式，架構(gòu)發(fā)展以一種穩(wěn)健的方式小步快跑著。但與有些敏捷方法學建議的固定迭代時長有些不同，當“搭 順風車”時，是宿主項目的規(guī)模決定迭代的時長。

保證高效的溝通是另一個重要的問題，這通常是采用我們俗稱為“閉關”的形式來解決的。項目上到一定規(guī)模，就會包下一個會議室，項目經(jīng)理、架構(gòu)、系 分、開發(fā)、測試等人員都會坐在一起，保持溝通的高效率，也減少不必要的干擾。對于長周期的項目、或者需求難以在初期完全確定時，在一個項目內(nèi)部也設計一些 迭代，開發(fā)人員增量地交付功能，測試并行進行功能驗證，暢通無阻的溝通以及項目經(jīng)理在場的協(xié)調(diào)管理是這種工作模式能夠順暢運轉(zhuǎn)的關鍵。

InfoQ中文站：阿里巴巴和淘寶網(wǎng)的很多架構(gòu)也是基于SOA的，請談一下選擇和實施SOA的前因后果。

程立：支付寶早期的單一應用程序架構(gòu)只存在了很短一段時間就受到了挑戰(zhàn)。

首先對這種架構(gòu)發(fā)起挑戰(zhàn)的是團隊組織結(jié)構(gòu)與分工的變化。隨著業(yè)務領域的拓展，并行的項目越來越多，研發(fā)團隊也迅速擴大，為了使團隊更好地配合業(yè)務，走向?qū)I(yè)化，我們內(nèi)部開始按照業(yè)務線分組。跨組之間的溝通成本的提高要求必須將各自負責的系統(tǒng)嚴格切開，降低相互間的耦合度。

另一個挑戰(zhàn)與支付寶業(yè)務特點密切相關。作為互聯(lián)網(wǎng)上的新型服務，必須快速變化才能滿足需要，曾經(jīng)有很長一段時間，我們保持每周兩次的新版本發(fā)布速 度；而作為電子支付服務，它又必須絕對可靠、高度可用。為了解決這個穩(wěn)定與快速的矛盾，我們必須將系統(tǒng)中的業(yè)務核心獨立出來，由專業(yè)的團隊、通過更嚴格的 研發(fā)體系來支持它的發(fā)展；前端應用程序則繼續(xù)以互聯(lián)網(wǎng)速度高速發(fā)展。

業(yè)務、技術(shù)、管理上同時提出了解耦的需要，而“服務”很好地統(tǒng)一了這三者，所以，選擇SOA作為技術(shù)架構(gòu)的發(fā)展方向是很自然的。

現(xiàn)在，我們已經(jīng)圍繞著公司的基礎業(yè)務建設了幾大核心服務系統(tǒng)，并且搭建了以 ESB 為骨干、以服務框架為基礎的面向服務基礎設施。太極拳中講究腰功，拳論中說“腰為主宰，腰為軸，刻刻留意在腰間”。這些核心服務以及配套的基礎設施很像支 付寶系統(tǒng)的“活腰”，它們的高可靠與高可用性是支付寶系統(tǒng)整體穩(wěn)定性的基礎，它們的靈活性與可重用性支持前端業(yè)務有條不紊地創(chuàng)新、整合與優(yōu)化，它們的可伸 縮性保證了系統(tǒng)能夠支撐持續(xù)的快速業(yè)務增長。

InfoQ中文站：現(xiàn)在你們也對外開放了很多服務，在架構(gòu)設計上有做特殊的考慮，或者經(jīng)驗嗎？

程立：支付寶很早就提供了外部API，為互聯(lián)網(wǎng)上的電子商務提供安全交易與資金流解決方案。現(xiàn)在支付寶已有上百個開放的API服務，連接了數(shù)十萬大大小小的商戶系統(tǒng)。

我們覺得設計開放API平臺的思路與基于SOA原則進行架構(gòu)設計很相似：業(yè)務上，需要理順業(yè)務關系、劃分清晰的企業(yè)業(yè)務邊界、并制定業(yè)務處理規(guī)范； 從技術(shù)上說，需要制定統(tǒng)一的技術(shù)標準、建設統(tǒng)一的通信基礎設施。由于新產(chǎn)品會不斷推出，因此，支付寶在內(nèi)部建立了一個API容器，方便擴展新產(chǎn)品。將 SOA搬到互聯(lián)網(wǎng)上，SOA體系中固有的一些問題，如安全性、可靠性、接口契約的穩(wěn)定性等問題就會被放大，在架構(gòu)設計與標準制定時，必須很好地考慮這些問 題。

出于安全與合規(guī)的需要，支付寶在制定API的業(yè)務規(guī)范與技術(shù)標準時，特別關注身份與安全體系；安全與方便是一對矛盾，為了更好地處理這兩者的關系，支付寶在架構(gòu)上支持靈活的安全體系，可以根據(jù)業(yè)務特性與商戶個性需要，在安全性與方便性之間進行折衷。

互聯(lián)網(wǎng)上系統(tǒng)交互的非可靠性與交易與支付類業(yè)務的可靠性要求之間也是一對矛盾，因此，接口標準與統(tǒng)一的通信基礎設施中我們針對可靠性進行了專門的設計。

從接口契約穩(wěn)定性上說，我們當時的做法是將技術(shù)標準設計成允許API接口增加新參數(shù)，提供版本參數(shù)，提供API接口的個性化配置能力，允許商戶定義一部分API上交換的數(shù)據(jù)與處理行為等。

隨著支付寶業(yè)務領域不斷拓展，原來的從需求->解決方案->產(chǎn)品->API的方式，周期太長，已經(jīng)難以快速滿足大量合作伙伴的需 求。因此，支付寶現(xiàn)在正在由產(chǎn)品式的開放轉(zhuǎn)向平臺式服務的開放，通過加強開放基礎設施的建設，向合作伙伴提供更基礎、更可重用、更體系化的服務，達到與合 作伙伴充分協(xié)同，建設繁榮、共贏的電子商務生態(tài)圈的目標。同時，開放的業(yè)務服務與開放的技術(shù)平臺也正在推動支付寶的業(yè)務與技術(shù)架構(gòu)向前發(fā)展，對構(gòu)建更大規(guī) 模的分布式系統(tǒng)、更大規(guī)模的并行研發(fā)模式都帶來了積極而深遠的影響。

InfoQ中文站：我們知道，支付寶的架構(gòu)平臺中采用了不少開源系統(tǒng)，為何作此選擇？

程立：除了支付寶與阿里巴巴集團自主研發(fā)的很多基礎系統(tǒng)與開發(fā)框架、以及一些商業(yè)系統(tǒng)之外，支付寶也使用了很多優(yōu)秀的開源軟件。具有蓬勃的生命力的開源軟件對支付寶的技術(shù)體系是一個很重要的補充。

在某些領域，一些開源軟件幾乎已經(jīng)是事實的標準了，它們的高質(zhì)量也是經(jīng)過社區(qū)的嚴格考驗的，比如Spring和它的POJO編程模型。通過使用這些 開源軟件，不但讓系統(tǒng)可以在開始階段就站在一個比較高的起點上，而且對于加入團隊的新同事，一開始就可以在一個相對熟悉的環(huán)境下工作。

在另一些尚未形成標準的領域，在產(chǎn)品選型階段，我們一般會在開源系統(tǒng)與商業(yè)產(chǎn)品間進行細致地選型，必須能夠滿足業(yè)務所要求的主要功能特性與關鍵質(zhì)量 要求。在同樣能夠滿足主要功能特性與關鍵質(zhì)量要求的前提下，誰具有良好的可擴展性，誰更簡單，誰具有長期發(fā)展的生命力，誰有好的服務支持，都是最后做出選 擇的重要因素。其中，可擴展性往往是一個選擇的關鍵因素。基于社區(qū)集體貢獻模式的開源軟件在可擴展性方面往往做得很好。當業(yè)務發(fā)展到一定階段，在技術(shù)上一 定會有大量個性化的需求，所選擇的系統(tǒng)必須能夠支持快速滿足這些需求。開放的源代碼也使我們在問題響應時，具有更大的主動性。隨著開源系統(tǒng)走向商業(yè)化運 作，在服務支持方面也開始做得更好，這些都進一步增加了開源系統(tǒng)的競爭力。

InfoQ中文站：請談一下當前架構(gòu)師所面臨的挑戰(zhàn)。

程立：“瞻前”、“顧后” ――這是我現(xiàn)在體會到的最大挑戰(zhàn)。

先談談“瞻前”。當業(yè)務個性不明顯、業(yè)務規(guī)模也不大時，架構(gòu)師還是有很多容易模仿的定式與先例的。但當業(yè)務的個性與規(guī)模到達一定階段時，一定會有一 些別人從未遇到過的非常困難的問題需要你去解決。作為站在企業(yè)技術(shù)金字塔塔尖上的一群人，當過去的經(jīng)驗用不上，搜索引擎也不能向你提供任何有用的答案，只 有獨立去思考，去做出重大決定時，如果沒有充分的準備，對企業(yè)對個人都是巨大的風險。這需要架構(gòu)師建立未雨綢繆的意識，不斷推演未來可能的變化并思索應對 之策，持續(xù)而有方向地積累知識、發(fā)展能力，建立廣泛的技術(shù)交流圈子，并且“顧后”。

再談談“顧后”。架構(gòu)師的另一個重要的職責是發(fā)掘團隊中的好苗子，幫助他們，使他們趕上并超越自己。無論這一點是否寫入你的KPI，這樣做都是必須 的。站在架構(gòu)師的立場看，架構(gòu)必須有一個好的技術(shù)梯隊一層層傳遞下去，才能夠有效、持續(xù)地貫徹執(zhí)行，如果只是架構(gòu)師們沖在前面，背后空了一大片，架構(gòu)永遠 只能停留在藍圖上。站在企業(yè)的立場看，企業(yè)真正的技術(shù)實力，不在于已經(jīng)有怎樣的系統(tǒng)或者平臺，而在于是否有一個強大而有生命力的技術(shù)團隊，通過快速復制架 構(gòu)師的技術(shù)與經(jīng)驗，可以幫助發(fā)展并壯大這樣的團隊，而企業(yè)整體技術(shù)實力的提升也促進了架構(gòu)師提升。

---

程立，支付寶（中國）網(wǎng)絡技術(shù)有限公司。2004年開始參與淘寶網(wǎng)與支付寶系統(tǒng)的建設，2005年起進入支付寶，一直從事于互聯(lián)網(wǎng)電子支付系統(tǒng)的研發(fā)工作。現(xiàn)任支付寶首席架構(gòu)師，專注于電子支付系統(tǒng)的分布式服務架構(gòu)與開放架構(gòu)。

注：支付寶數(shù)據(jù)架構(gòu)師馮大輝，InfoQ中文站編輯郭曉剛、賴翥翔和劉申對本文亦有貢獻