從2005年開始，支付寶的技術架構經曆了“煙囪型”、“麵向服務型”、“雲平台型”三個時期。
“煙囪”是一個形象的比喻，支付寶的第一代架構就像一個個獨立的“煙囪”。沒有基礎架構可言，做一個業務就豎起一個“煙囪”，“煙囪”之間的關聯性不大，每做一個新業務就要將一個煙囪進行手動改造，而支持主要業務的“大煙囪”經曆了無數次的改動。
2005~2006年，支付寶業務發展得很快，任何一個商業想法，從產生到提供給用戶使用的時間都是按天來計算的，如每年“雙十一”大促時的支付寶紅包，就是程立用四天時間做出來的。
應該說，第一代“煙囪型”的係統較好地滿足了小團隊開發、業務快速試錯的需求，但是這個架構不能支持大團隊的分布式研發。在“煙囪型”的技術架構下，每當開發新的產品和功能時，隻能允許所有人在一個係統裏去寫代碼，與此同時，它的部署也是集中的，核心係統就是一個集群，數據庫也隻有一個。因此，隨著業務量的上升，這樣的數據庫和集群都會達到極限。
從2006年開始，支付寶的技術團隊意識到，“煙囪”架構無法支持支付寶未來業務的發展，如果要繼續拓展業務，必須先把架構分布化，建立底層服務架構，讓專業模塊做專業的事情。當時，分布式係統在互聯網界的應用並不罕見，規模較大的互聯網公司係統都分布化了，但是對於金融係統而言，分布化是沒有先例的。這是因為金融係統要求高穩定性和高安全性，任何改進都要先保證用戶賬目上的錢分毫不差。在係統數據分離之後，保證係統之間業務處理的一致性就成了核心的問題。
這時，程立剛從技術團隊的主力架構師升至首席架構師，團隊主管要求他不必寫代碼了，而是專注去“畫大圖”，為團隊的未來發展指明方向。可是對程立來說，這是一個完全不同的任務。整整一個季度的時間，他沒有畫出一張令自己滿意的“大圖”，kpi考核隻得了3.25分，程立甚至一度想辭職。
程立所要畫的“大圖”，就是支付寶二代的架構。
後來，到了2007年初，程立的腦子裏漸漸產生了一個想法。與此同時，業界的技術也逐漸成熟，特別是大規模soa係統[3]中的分布式事務處理標準逐漸明晰，程立就和同事一起，從2007年上半年開始準備將支付寶的係統做分布式的改造，現在看來就是把支付寶的架構改成一個分布式服務和分布式架構。
程立選擇先拿交易服務來開刀，首先將最複雜的交易服務重構，使交易服務變成“微服務”，這樣就能將它拿出來和其他事務打交道，同時還要保持事務和核心虛擬賬戶業務的一致性。為了解決這個事務問題，他們使用了ws-transaction服務規範[4]。
2007年5月，項目正式啟動。支付寶的技術團隊分為幾撥人：一撥人寫分布式事務的底層框架，一撥人設計新的核心的交易係統，還有一撥人做分布式事務的框架。兩個月後，開發完工，係統運轉了起來，一切看上去似乎都很正常。
但當程立從係統的複雜度去審視時，他發現了一個問題，原本非常簡單的處理過程，現在卻變得異常複雜。比如，僅一個消息處理，分布係統之間的消息就有10~20個，如果這樣，係統上去是要“死人”的。
進退之際，他想起了自己在2005年做支付寶三期時的經驗：如果係統存在問題，就不要抱任何僥幸心理，要敢於麵對問題，查找原因，從頭再來。項目團隊經過反複思考之後，決定把前麵的架構推翻重做。
後來，程立又想到了一個簡單的架構，他要求同事按照新架構開發。在團隊的支持下，到9月底，開發工作全部完成。2007年“十一”長假，他提前三天回來，把代碼重新檢查了一遍，又加了很多的監控日誌。“十一”過後，新係統順利發布。
二代架構在支付寶技術發展過程中是很關鍵的一步，因為新係統將原來的大係統拆開了，在當時這個項目叫作“交易服務化”。有“交易服務化”作為基礎，後來支付寶又做了賬務三期。做完賬務三期之後，核心賬務係統也分布化了。從2007年開始，支付寶陸續用了三年左右的時間對整個係統進行分布化。
這樣，支付寶就夯實了分布式事務的基礎設施，核心賬務可以分布，核心交易也可以分布，所有的業務都可以分開來做。結果是，支付寶的係統可以伸縮了，每一個係統都是分布式的，如果遇到業務峰值，就可以增加資源。幸運的是，當支付寶的二代架構做完後不久，淘寶就開始搞“雙十一”大促了。
支付寶的第二代架構為第三代架構“雲支付”奠定了良好的基礎，因為如果使用雲計算，係統首先要分布，隻有這樣才能用很多小型機器、雲資源作為支撐。
但二代架構過渡到三代架構的過程並非一帆風順，在二代架構完成後，雖然支付寶把係統拆開了，但是如何讓新業務長在複雜的分布式係統上是一個非常複雜的問題，在業務很多的情況下，係統會變成一張複雜的網。
支付寶技術團隊想到把業務進行拆分和梳理，從而將係統變成一個邊界明晰的雲服務平台。比如，係統裏有一個支付服務的平台，它的作用是對外提供支付服務，任何一個業務需要用到支付時，直接對接就可以，這樣支付的功能馬上就可以調用了。類似地，會員服務的係統、運營服務的係統與營銷服務的係統紛紛搭建出來，各種服務像“水、電、煤”一樣能夠即需即用。
總之，第三代雲支付架構能夠完成兩方麵的改造。一方麵是在底層使用雲計算技術，另一方麵是在上層把服務變成雲服務，這樣建立在其上的業務就可以很快地生長。
從二代架構過渡到三代架構，支付寶又花了三年時間，在此期間，支付寶開始自主研發中間件、數據庫、大數據平台。正是這個雲計算的架構，支撐了近幾年淘寶大促的交易，也使後來的“雙十一”能夠平穩地進行。
用程立的話說，如果這個事情做得晚一點，這幾年的“雙十一”大促就別想挺過來了。不僅如此，雲服務的三代架構也為今天螞蟻金服的發展奠定了堅實的基礎，現在的螞蟻金融雲就是建立在這個架構的基礎之上的。螞蟻金服對此並不滿足，現在已經開始研發第四代架構，這是一個適應目前數據開放、互聯、全球化的架構。
“煙囪”是一個形象的比喻，支付寶的第一代架構就像一個個獨立的“煙囪”。沒有基礎架構可言，做一個業務就豎起一個“煙囪”，“煙囪”之間的關聯性不大，每做一個新業務就要將一個煙囪進行手動改造，而支持主要業務的“大煙囪”經曆了無數次的改動。
2005~2006年，支付寶業務發展得很快，任何一個商業想法，從產生到提供給用戶使用的時間都是按天來計算的，如每年“雙十一”大促時的支付寶紅包，就是程立用四天時間做出來的。
應該說，第一代“煙囪型”的係統較好地滿足了小團隊開發、業務快速試錯的需求，但是這個架構不能支持大團隊的分布式研發。在“煙囪型”的技術架構下，每當開發新的產品和功能時，隻能允許所有人在一個係統裏去寫代碼，與此同時，它的部署也是集中的，核心係統就是一個集群，數據庫也隻有一個。因此，隨著業務量的上升，這樣的數據庫和集群都會達到極限。
從2006年開始，支付寶的技術團隊意識到，“煙囪”架構無法支持支付寶未來業務的發展，如果要繼續拓展業務，必須先把架構分布化，建立底層服務架構，讓專業模塊做專業的事情。當時，分布式係統在互聯網界的應用並不罕見，規模較大的互聯網公司係統都分布化了，但是對於金融係統而言，分布化是沒有先例的。這是因為金融係統要求高穩定性和高安全性，任何改進都要先保證用戶賬目上的錢分毫不差。在係統數據分離之後，保證係統之間業務處理的一致性就成了核心的問題。
這時，程立剛從技術團隊的主力架構師升至首席架構師，團隊主管要求他不必寫代碼了，而是專注去“畫大圖”，為團隊的未來發展指明方向。可是對程立來說，這是一個完全不同的任務。整整一個季度的時間，他沒有畫出一張令自己滿意的“大圖”，kpi考核隻得了3.25分，程立甚至一度想辭職。
程立所要畫的“大圖”，就是支付寶二代的架構。
後來，到了2007年初，程立的腦子裏漸漸產生了一個想法。與此同時，業界的技術也逐漸成熟，特別是大規模soa係統[3]中的分布式事務處理標準逐漸明晰，程立就和同事一起，從2007年上半年開始準備將支付寶的係統做分布式的改造，現在看來就是把支付寶的架構改成一個分布式服務和分布式架構。
程立選擇先拿交易服務來開刀，首先將最複雜的交易服務重構，使交易服務變成“微服務”，這樣就能將它拿出來和其他事務打交道，同時還要保持事務和核心虛擬賬戶業務的一致性。為了解決這個事務問題，他們使用了ws-transaction服務規範[4]。
2007年5月，項目正式啟動。支付寶的技術團隊分為幾撥人：一撥人寫分布式事務的底層框架，一撥人設計新的核心的交易係統，還有一撥人做分布式事務的框架。兩個月後，開發完工，係統運轉了起來，一切看上去似乎都很正常。
但當程立從係統的複雜度去審視時，他發現了一個問題，原本非常簡單的處理過程，現在卻變得異常複雜。比如，僅一個消息處理，分布係統之間的消息就有10~20個，如果這樣，係統上去是要“死人”的。
進退之際，他想起了自己在2005年做支付寶三期時的經驗：如果係統存在問題，就不要抱任何僥幸心理，要敢於麵對問題，查找原因，從頭再來。項目團隊經過反複思考之後，決定把前麵的架構推翻重做。
後來，程立又想到了一個簡單的架構，他要求同事按照新架構開發。在團隊的支持下，到9月底，開發工作全部完成。2007年“十一”長假，他提前三天回來，把代碼重新檢查了一遍，又加了很多的監控日誌。“十一”過後，新係統順利發布。
二代架構在支付寶技術發展過程中是很關鍵的一步，因為新係統將原來的大係統拆開了，在當時這個項目叫作“交易服務化”。有“交易服務化”作為基礎，後來支付寶又做了賬務三期。做完賬務三期之後，核心賬務係統也分布化了。從2007年開始，支付寶陸續用了三年左右的時間對整個係統進行分布化。
這樣，支付寶就夯實了分布式事務的基礎設施，核心賬務可以分布，核心交易也可以分布，所有的業務都可以分開來做。結果是，支付寶的係統可以伸縮了，每一個係統都是分布式的，如果遇到業務峰值，就可以增加資源。幸運的是，當支付寶的二代架構做完後不久，淘寶就開始搞“雙十一”大促了。
支付寶的第二代架構為第三代架構“雲支付”奠定了良好的基礎，因為如果使用雲計算，係統首先要分布，隻有這樣才能用很多小型機器、雲資源作為支撐。
但二代架構過渡到三代架構的過程並非一帆風順，在二代架構完成後，雖然支付寶把係統拆開了，但是如何讓新業務長在複雜的分布式係統上是一個非常複雜的問題，在業務很多的情況下，係統會變成一張複雜的網。
支付寶技術團隊想到把業務進行拆分和梳理，從而將係統變成一個邊界明晰的雲服務平台。比如，係統裏有一個支付服務的平台，它的作用是對外提供支付服務，任何一個業務需要用到支付時，直接對接就可以，這樣支付的功能馬上就可以調用了。類似地，會員服務的係統、運營服務的係統與營銷服務的係統紛紛搭建出來，各種服務像“水、電、煤”一樣能夠即需即用。
總之，第三代雲支付架構能夠完成兩方麵的改造。一方麵是在底層使用雲計算技術，另一方麵是在上層把服務變成雲服務，這樣建立在其上的業務就可以很快地生長。
從二代架構過渡到三代架構，支付寶又花了三年時間，在此期間，支付寶開始自主研發中間件、數據庫、大數據平台。正是這個雲計算的架構，支撐了近幾年淘寶大促的交易，也使後來的“雙十一”能夠平穩地進行。
用程立的話說，如果這個事情做得晚一點，這幾年的“雙十一”大促就別想挺過來了。不僅如此，雲服務的三代架構也為今天螞蟻金服的發展奠定了堅實的基礎，現在的螞蟻金融雲就是建立在這個架構的基礎之上的。螞蟻金服對此並不滿足，現在已經開始研發第四代架構，這是一個適應目前數據開放、互聯、全球化的架構。