這是 SOFA 的故事，或者也會是你的故事

「你能不能跟我講講 SOFA 的故事？」

「SOFA 的故事很特別也很日常 ，跟你說說 SOFA 的故事，或者也會是你的故事。」

初心：技術應該是要解決實際問題的

螞蟻金服不是爲了作技術自己而作技術，而但願用技術來解決社會當下和將來的問題。若是說用金字塔結構來描繪數字金融的社會價值，在塔頂的就是數字金融能在全球範圍內帶來更多平等的機會。

程立（螞蟻金服 CTO）強調：「對螞蟻金服或者阿里巴巴來講，首先咱們是很是的理想主義和願景驅動，當肯定能夠給全世界帶來更多平等的機會時，這必定指引咱們的方向。可是咱們也是一個很是現實主義的公司，當遇到具體問題的時候，會看怎麼可以很好的繞過當下的障礙，從而走到要走向的將來。在遇到具體的現實問題的時候，也不會採起很是僵硬的方式。具體問題確定是要具體分析的，可是咱們的願景不會變，也不會把所謂的價值觀變成教條。商業上的可持續發展，對咱們來講很是重要，若是咱們商業上都不能可持續發展，就走不到將來。」

技術創新都是被逼出來的

螞蟻金服自研 SOFA 一樣如此。SOFA 走的是一條跟傳統金融行業不一樣的分佈式架構之路。要基於不可靠的硬件系統實現金融級的性能和可靠性，要應對支付寶這樣的超大規模互聯網金融應用，有不少難題要解決。螞蟻金服構建了一整套處理金融級交易的分佈式架構與平臺，在金融級的一致性要求和海量併發處理能力上達到了很好的平衡，並在快速容災恢復、彈性伸縮能力、多地多活高可用保證能力和按需供給的精細化資源調度能力方面沉澱了豐富的實踐經驗。

中間件，是與操做系統和數據庫並列的傳統基礎軟件三駕馬車之一，也是難度極高的軟件工程。傳統中間件的概念，誕生於上一個「分佈式」計算的年代，也就是小規模局域網中的服務器/客戶端計算模式，在操做系統之上、應用軟件之下的「中間層」軟件。早期中間件的出現，是爲了解決日益複雜的PC服務器、網絡甚至不一樣地理位置機房之間等異構硬件環境中，支撐應用軟件的挑戰。與操做系統和數據庫不一樣，中間件並無一個明確的定義，一般來講包括消息、數據、遠程過程調用、對象請求代理、事務、構件等幾個部分。

隨着互聯網的快速發展，特別是雲計算在近十年的蓬勃進展，企業的IT環境發生了深入的變化：從過去基於局域網和城域網、單一城市地理範圍的分佈式計算環境（傳統企業），向基於互聯網和光纖網絡、全國甚至全球地理範圍的超大規模分佈式計算環境演進（互聯網企業）。在這個過程當中，軟件也向大規模互聯網服務和雲服務演化，不管是操做系統仍是數據庫都發生了深入的變化，中間件也在這個過程不斷演進和擴大本身的邊界。

中間件的發展表明着技術架構的升級和變遷，而這與企業組織模型和業務實踐息息相關。理論上，中間件向下屏蔽異構的硬件、軟件、網絡等計算資源，向上提供應用開發、運行、維護等全生命週期的統一計算環境與管理，屬於承上啓上的中間鏈接層，對企業來講着重要的價值。根據康威定律，軟件和系統架構設計，和企業的組織結構、業務流程和溝通方式息息相關，所以，隨着企業業務規模的超大規模和快速迭代發展，中間件質量和能力的高低就直接決定了企業技術架構的命運。特別是隨着數字商業的興起，過去不能被業務感知、不能爲最終用戶帶來直接價值的中間件，也成爲了數字業務的一部分。

螞蟻金服是一家旨在爲世界帶來平等金融服務的科技企業，做爲原生的數字企業和數字商業表明，螞蟻金服從2004年成立支付寶開始，在過去十多年的時間裏走出了一條自研的、面向超大規模互聯網金融應用的、金融級中間件技術體系。特別是自2008年雙十一以來，在每一年雙十一超大規模流量的衝擊上，螞蟻金服不斷突破現有技術的極限，在金融領域達到了史無前例的技術成就，特別是歷時十年自研的中間件技術能夠知足2017年雙十一25.6萬筆/秒的支付峯值、全天14.8億筆的支付，而2010年雙十一的支付峯值爲2萬筆/分鐘、全天1280萬筆支付。在過去幾年內，螞蟻金服自研的中間件技術所支持的支付峯值翻了750倍、全天支付筆數翻了115倍、交易更覆蓋全球225個國家和地區。

極限業務場景催生了極限的IT體系。螞蟻金服的金融核心技術部負責人趙尊奎（花名：妙才）說，他常常接待外部的金融機構負責人來參觀和了解螞蟻金服的IT體系，「看過的都表示不敢想象」。今天，螞蟻金服的軟件工程成就，已經把雙十一極限挑戰變成了新常態，而這套支撐螞蟻分佈式實踐的架構體系，稱之爲SOFA（Scalable Open Financial Architecture，簡稱 SOFA）。

SOFA 的誕生

SOFA 的關鍵詞包括：無限伸縮能力、一致性、秒級容災和極低成本而且作到極致，從而定義了新的「金融級分佈式架構」。

SOFA 的緣起

程立，花名魯肅，摩羯座，工號3896。2004年，支付寶剛剛有本身獨立的系統，基礎平臺還得靠外包團隊提供技術支持。而2004年2月，程立還在上海交大攻讀博士，一個偶然機會讓他接觸到阿里巴巴，並之外包架構師的身份協助支付寶網站的建設。一年合做下來，程立決定放棄博士學位，並於2005年2月正式加入支付寶。程立以嚴謹務實、邏輯嚴密，被螞蟻技術團隊的同事視做「神同樣的存在」。

▲ 螞蟻金服CTO 程立

做爲曾經的支付寶首席架構師、支付寶第一代架構設計者，以及支付寶史上最大危機——2008年1月1月停機發布17小時——的救火大隊長，能夠說若是說沒有程立，就沒有如今的支付寶。在螞蟻金服入門手冊《拾念》中，記載了支付寶史上最驚心動魄的17小時：2008年元旦，支付寶宣佈要停機8小時發佈「財務三期」，但各類意外接連出現，當時「財務攜款潛逃」、「溼抹布致使服務器宕機」的傳言滿天飛、沒有包裹送的快遞小哥發帖跪求支付寶快點回來，程立在關鍵時刻敲了近兩個小時的代碼，最終結束了17小時的停機發布。

程立講述了SOFA的誕生歷史：最先的支付寶系統，是由還不太會大系統開發的人員實現的，像程立剛從學校出來就作支付寶第一代架構，所以第一代系統很是簡單——就是一個簡單的應用，裝在一臺應用服務器上，使用一個數據庫，服務一個大客戶淘寶。一個簡單的系統，支撐了支付寶從2004年到2006年早期的發展。支付寶早期的系統架構雖然簡單，但好處是特別快，產品經理但願怎麼改、立刻改一下代碼就能實現了，好比說支付寶紅包，從需求提出到上線就四天的時間，可是到後面，這樣一個簡單系統沒法支撐更多的交易量，也不能支撐更加複雜的業務。

從2006年末開始醞釀，那時候支付寶面臨最大的一個問題是業務變得愈來愈複雜，而工程師數量愈來愈多，原來的系統被稱爲monolithic——即龐大的單體系統的意思。這個系統慢慢變得沒法裝載更多更復雜的業務邏輯，也不能讓那麼多工程師在一塊兒並行的工做。當時，支付寶但願能夠成百上千個項目並行進行，並且每一個工程師能夠不受干擾的工做，而當業務邏輯增長的時候，系統的複雜度不要成指數級上升。

因此，在2006年的時候，支付寶技術團隊要作對將來的技術架構作一個選擇，當時有兩派意見：一派意見是向銀行老大哥學習，老大哥已經走了十幾年，這條路必定是安全的；另外一派意見是走一條新的路，即用分佈式的架構去支撐將來的交易支付系統，而這條路在當時尚未人走過。這裏的分佈式架構，並非客戶端/服務器時代的面向企業級的小規模分佈式架構，而是在互聯網時代的超大規模分佈式架構。通過差很少大概一年左右的討論和思考以後，支付寶團隊作了一個決定，要走一條過去沒有人走過的路，因而啓動了支付寶第二代架構的建設，即支付寶技術系統的服務化。2007年開始，支付寶啓動了對交易系統、商戶系統、會員系統、支付清算系統的改造。

就在那一年，支付寶到大連招聘遇到了胡喜（花名：阿璽），他以前已經在前一家公司研究SOA以及OSGi相關技術，因而就加入支付寶團隊，幫助程立作下一代架構的轉變。胡喜回憶，他在2007年加入支付寶團隊的時候，研發人員都比較痛苦。當時的支付寶使用的是阿里巴巴的統一技術框架WebX。WebX是阿里自研發的一套基於JavaServlet API的通用Web框架，在阿里巴巴集團內部普遍使用，2010年末向社會開放源碼。WebX比較偏向於先後端融合的架構，能快速搭建一個網站，可是沒有考慮到業務發展到必定程度後的複雜度，怎麼更好的搭建後臺。例如，當時支付寶的一個電子錢包系統叫iWallet，每次系統啓動就得五六分鐘，開發人員出去抽根菸，回來後若是發現錯誤又得修改後從新啓動，開發人員天天不是在代碼編譯的過程中，就是重啓的過程中，一個系統包含了幾十個工程，十幾個團隊並行開發，項目併發也致使了不少的合併衝突和耗時，整個研發效率低下致使很難進行下去。因而，從那開始就着手研究解決支付寶整個架構的變化。

▲ 螞蟻金服副總裁、副CTO 胡喜

程立給當時要作的這套分佈式架構起了一個「SOFA」的名字，其背後有兩個含義：一是按照當時的技術趨勢，要作面向服務的架構，即ServiceOriented Architecture，但加入了金融業務，因此是Service Oriented Fabric Architecture；二是但願可以像沙發同樣，讓工程師能夠很是爽地工做。因此當時出於這麼簡單的考慮，就開始打造SOFA。所謂SOA和服務化改造，就是把企業的IT系統以「服務」的方式從新組織起來，再經過「服務總線」鏈接起來造成可插拔式的企業IT架構，這個架構就是SOA。這裏要注意的是，SOA實際上是一套面向傳統企業IT的架構思想，並且在SOA早期則只有理論框架而無具體的成功實踐。

第一代的SOFA其實就解決兩個問題：一是當要把系統變成分佈式的時候，怎麼有一個像「膠水」的機制也就是鏈接器，能夠把分佈式系統鏈接成一個總體；二是但願每個服務自己是組件化，因此當時第一代SOFA裏採用了OSGi（一套Java模塊化規範，容許應用程序使用精煉、可重用和可協做的組件構建），這樣每一個工程師能夠專一於各自的組件，最後又可以把這些組件拼裝在一塊兒成爲「服務」，再把「服務」拼裝在一塊兒成爲整個大系統。這一整套框架，就是第一代SOFA框架。

有了第一代SOFA技術架構以後，支付寶團隊就開始作很是關鍵的業務服務改造。首先是把支付寶全部用戶的核心帳務系統變成一個業務服務，從而能夠和其它業務組裝起來。可是把帳務拆出來之後，遇到一個更難的問題：怎麼解決分佈式服務一致性的問題，也就是分佈式事務問題。而在解決這個問題的時候，當時支付寶團隊冒了很大的風險，在啓動這個項目的時候還並不清楚怎麼解決最好，而當時能夠參考的行業技術趨勢就是SOA以及業界提出的幾個SOA框架。

SOA 業界那時候提出兩個 SOA 事務的標準：一個是基於 Atomic Transaction（原子性交易），叫WS-Atomic Transaction；另外一個是基於業務流程編排的事務，叫 WS-BusinessActivity；開源社區經過 JBoss 的TransactionServer 實現了這兩個參考標準下的事務。當時，支付寶的技術團隊就在想，可否用 JBoss 開源技術與這兩個標準去構建支付寶的核心交易和帳務？然而，項目開始後的不久，也就三個月左右的時間，當項目進行到一半的時候，發現這兩個當時業界的標準和開源實現卻根本不可能支持一個實際的應用。

緣由很簡單，一個最簡單的核心交易系統和核心帳務系統，進行最簡單的一個事務，也要通過十幾回的消息傳遞，其中任何一次消息傳遞若是中斷，那麼這個事務就失敗了，並且失敗之後，當時業界的 SOA 標準並無提出該怎麼恢復失敗的事務，同時任何一次交易都通過十幾回的消息傳遞的話，也致使整性能很是低。這樣一個系統若是最後發佈的話，實際上是不能支持支付寶當時的交易量。因此當項目進行到一半的時候，團隊就放棄了業界標準及其開源實現，必須找到本身的一條路。

當年，關於分佈式事務的一致性，業界另外一條路徑是基於兩階段事務標準（Prepare 階段與 Commit 階段）和開源分佈式實現 XA，但當時已經知道 PayPal 曾經走過這條路，結果是致使系統宕機一週，最後系統所有回滾。

因此那個時候，支付寶技術團隊就考慮可否本身提個標準，這樣一來就簡單了：首先是要解決分佈式一致性問題，必需要分佈式的提交協議，這個協議若是在數據庫層實現，效率會很是低下，由於數據庫層不懂任何的業務邏輯，只能以一種通用的方式去實現，從而致使沒法對上層的業務邏輯層進行優化，因此就想到把提交協議放在服務層。

「那個時候，咱們大的想法很簡單，既然支付寶系統已經拆成了一個個很是小規模的服務，那麼就讓這個服務自己具有事務的屬性，叫事務性服務。這樣一個個小的事務性服務就像一個個小石頭同樣，能夠裝到一個大的杯子裏，而後再設計一個分佈式的提交協議，把這一個個小的事務綁定成一個大的業務事務。而這個服務也不只是微服務，而實際上是一個微交易，把每個服務變成一個交易，再經過一個編排的框架，把每一個交易變成一個大的總體服務。」程立用比較形象的語言解釋瞭如今被稱爲螞蟻金服黑科技的分佈式事務XTS (eXtended Transaction Service)的由來。

有了這個思路，當時支付寶技術團隊就開始去作了。克服的第一個難點是把已經有的交易服務、帳務服務等，變成一個個交易型服務，這個難點當時就突破了；第二個難點是要實現一個可擴展（Scalable）的框架，去編排海量的事務，那就是 XTS。大概在2008年1月份，SOFA 項目就上線了，上線之後至今不斷打磨，一直到如今還支撐螞蟻金服整個的業務交易。

SOFA 的演進過程

從第一代到眼下的第五代，SOFA 的演進過程實際上是支付寶從最先的一個大型的業務與IT交織在一塊兒的單體系統，一邊拆金融業務系統（即後來的業務中臺）、一邊拆底層IT系統（即後來的數據中臺、計算中臺）的過程，在拆分的過程當中還要解決新出現的可擴展性、一致性問題等各類問題，同時不斷應付每一年都能擊穿系統極限的雙十一，還要把數據從原有系統一點一點「倒騰」到新系統裏、同時管理新增的海量數據，這樣一個極爲複雜的過程是怎麼進行的？有趣的是，這個過程的附加值之一，就是在無心中完成了去「IOE」，由於從單體系統拆分到互聯網分佈式系統，自己就是用PC服務器機房代替昂貴 IOE 設備的過程。

「整個過程能夠說一路狂奔。」楊冰後來回憶整個過程。「‘蘿蔔’就這麼幾個，坑那麼多，根本就填不過來的狀態。每一箇中間件產品連‘一個蘿蔔一個坑’都作不到，不少‘蘿蔔’是放在兩個三個坑裏面的狀態，你就想有多挑戰了。其次，每年都是翻一番的業務指標倒逼。整個團隊的狀態基本上是一年大促結束後，春節一過就開始密集準備下一年大促，一眨眼的功夫離雙十一就沒幾個月了，不少系統的技術改造可能要到六、7月份準備好，再所有升級上去，業務還在不斷變化，不停有新的想法冒出來，每一年就是這麼個狀態，基本都是開發飛機就把發動機給升級上去了。」

▲ 螞蟻金服中間件團隊負責人 楊冰

程立回憶，SOFA 早期的開發是徹底違背項目管理邏輯，在項目推動的過程當中既有研發平臺又有研發上層的業務系統，至關於把不少風險都導在一個項目裏面一塊兒作，SOFA 第一代項目就是靠團隊齊心合力，天天都會遇到新問題、天天都要去解決各類問題，但你們背後有必勝信念並且很是擁抱變化，勇於在項目的中後期把前期架構決定所有推翻掉，再用一套新的架構替代。「因此到 2008 年那次帳務三期的發佈，那次原定發佈8個小時，後來咱們發佈了17個小時，說明在項目發佈過程當中，仍是有不少問題沒有解決，但最後咱們硬生生把這個項目給發佈下去，並且成功了，如今回想起來，實際上是有一點後怕的。」程立笑說。

2008年以後，支付寶技術團隊開始肯定一個原則，即全部的發佈不得停機，必需要確保項目發佈沒有風險。其次，要結束全部的研究型項目，技術研究要把技術問題解決了，再用到商業系統裏面去。並且從2008年開始，每一個新技術都不會首先用到最核心的系統裏，而是會在相對邊緣的業務系統裏通過充分考驗之後，再用到核心系統裏。

在 SOFA 初期，能夠看到作交易和帳務這兩個項目的時候，業務系統開發人員與技術平臺的開發人員是不分的，不管是程立仍是胡喜，都是一下子寫業務交易的代碼，一下子寫下面的技術平臺代碼，工程師團隊也沒有嚴格區分。後來開始創建中間件團隊，楊冰基本上也是那個時候加入，分配一部分人專門研究底層技術，另外一部分人專門寫上面的應用系統架構，慢慢開始變得愈來愈正規了，包括對於新技術上線過程的灰度和控制，也會作得更好。

楊冰回憶他在2009年以剛畢業的研究生身份加入支付寶團隊的時候，當時服務化拆分的過程是程立、胡喜親自參與，一邊對WebX系統作服務化拆分，一邊胡喜寫了 SOFA 框架的原型，楊冰與後面加入的小夥伴就幫助不斷完善SOFA。「當時咱們還很初級，基本上是程立和胡喜帶着咱們去實現他們構想出來完整一套思想。當時雖然服務化和SOA 的概念很火，但業界的實踐遠沒有如今這麼豐富，不少實現機制都是摸着石頭過河。業務服務化拆分又是另一條主線，當時主要是程立、胡喜、倪行軍（花名苗人鳳，支付寶第一代首席架構師，螞蟻金服支付寶事業羣總裁）參與，這幾我的都是既寫框架代碼和組件代碼，又參與業務代碼拆分。當時支付寶全部的業務都在演進，支付寶架構團隊一方面在業務邏輯拆分和技術架構拆分的過程當中熟悉支付寶的業務，一方面在熟悉業務的基礎上思考如何從中抽象出可複用的代碼、數據和框架，以更好的支持將來的業務。因此當時就是一邊在作業務和技術的人肉拆分，一邊又把拆分的部分挪到新的框架中去承載。整個過程不是設計好了再搞，而是一邊作一邊搞。」

XTS 框架都是在那樣一個過程中寫出來的。由於在原先集中式架構是不會出現事務一致性的問題，拆分之後就出現了這樣的問題。當問題出現之後，就一邊拆一邊解這個問題。固然，解決的時候也不是人爲介入，而是構想出技術化的方案，甚至沉澱出來一套技術。那個時候，支付寶系統裏的 Oracle 數據庫還在用，小型機等高端傳統設備都在用，支付寶的業務系統包括會員、交易等被拆分出來後，就直接跑在 X86 架構上，這不只是物理形態和部署形態上的差別，更是由單體應用的開發模式變成 SOA 化的分佈式開發模式，這就是從 WebX 到 SOFA 的演進過程。帳務系統是最後一個從支付寶拆分下來的系統，隨着帳務系統的拆分紅功，IOE 設備也完全從支付寶系統裏下線。

在整個支付寶架構的改造以及 SOFA 的發展過程當中，關於中間件的基本構成和思想是有業界參照的，好比消息中間件、數據中間件、事務中間件等，但 SOFA 技術團隊要作面向超大規模互聯網金融交易的分佈化改造，而其中的黑科技諸如單元化，則是被業務倒逼出來，徹底沒有業界參考的實踐，「咱們找到的一些論文，一些概念，一些相似的作法，但當時支付寶的體量已經很大了，沒有人肯定這事兒真的能作成，並且是在金融這個高危的業務場景下」。

「套用螞蟻金服前 CEO 彭蕾的話，她曾提到過你們作的不少事情就是怎麼把馬雲的決定變成一個正確的決定，而咱們在整個中間件工程實現過程當中，也是相似的狀況。好比 SOFA3 時代的合併部署，當時胡喜提出這個概念的時候，內部爭論很是大，你們都以爲這件事情不靠譜，並且很難作、很是複雜，阻力很是大。最難的事情，是說服團隊。但最後你們仍是爲能作成這件事情，併爲公司節省下這多成本而感到驕傲」楊冰回憶。

爲了解決新的挑戰，螞蟻金服的中間件技術團隊想了各類辦法。楊冰爲單元化架構當中 RPC 調用設計的路由邏輯：對於各類業務系統，有的能夠升級、有的能夠改造、有的不行，那麼在 RPC 遠程服務調用時就會有五六種分支去決定究竟是本地優先、仍是要跨機房、仍是要根據業務的分庫分表作路由等等。這個邏輯極其複雜，在於既有同構機房、又有異構機房，而異構機房又要把通信收斂到一個代理，因此又會有代理的存在，致使很是複雜。而爲了收管無法升級的系統，甚至該系統的負責人都已經不在的狀況，就用一個相似於 Service Mesh 技術代理，去「假裝」這個服務。「整個架構是很漂亮的，可是工程實現中的每個細節都很複雜，全部的設計都充滿了架構的平衡的智慧。咱們在實現整個過程之後，再慢慢把徹底沒有必要的三四個路由邏輯去掉，變成比較規整的模式。基本是這樣的過程，由於不能把支付寶停下來。」

負責過 SOFA 體系中消息中間件的王磊（花名：文若）回憶，阿里從2008年開始辦雙十一，第一年只是試一下，因此沒有很大規模的宣傳，甚至連內部不少人都不知道。從2009年是開始支付寶和淘寶一塊兒參與雙十一，當時宣傳淘寶商城裏面全部的商品都是半價，可是由於2008年時候對雙十一的力量並無清楚的認識，到2009年那一年的時候就忽然出現了各類問題。王磊當時負責消息中間件，內部叫作Message Broker，屬於消息隊列：消息從上游應用經過消息中間件傳遞給下游的系統，包括當時還在使用的Oracle數據庫。「當時正在看這個活動的過程，甚至咱們本身也在買東西的時候，忽然DBA跑過來講要趕快對消息進行限流，由於下游的數據庫立刻就要撐不住了，數據庫的日誌空間立刻就要耗光了，若是耗光就會致使數據庫宕機，再啓動起來就是幾個小時之後的事情。當時咱們小組是三我的，之前歷來沒有快速對消息進行限流，最後就只能人工登陸上游應用的服務器上，而後在服務器上敲命令作流量控制，一條一條的敲下去，最後保住了下游系統沒有被沖垮。那個時候很遺憾，由於不是靠消息中間件去限流，其實是把上游發消息的應用‘殺’死了。後來，通過這件事情之後，咱們就下定決心要作一件事情，就是叫作一鍵限流，在中間件層面對於消息中心的一鍵限流能力，就是從那天開始建設的。」這樣的故事還有不少。「整個過程就像打怪升級，看到一個幹掉一個。」王磊的實踐，表明了整個 SOFA 團隊的工做狀態，也表明了 SOFA 與其它互聯網分佈式中間件的最大不一樣——沉澱了支付寶/螞蟻金服十多年來，整個業務與IT體系的最佳共享實踐。

就是這樣，SOFA 的演進伴隨着支付寶整個架構的演進而發展，程立回憶，第一代 SOFA 比較簡單，只是搭了一個框架和模型讓系統能夠運行，到後期系統運行中作了大量的優化，包括要解決通信的性能、最高效的容災、異地容災架構的建設、單元化改造、LDC 邏輯數據中心項目等，全部這些慢慢就沉澱在 SOFA 裏面。而 SOFA 則逐漸從解決分佈式服務和分佈式交易的問題，變成一個真正解決金融級系統構建的基礎架構問題，因此如今把 SOFA 更名，從原來的 Service Oriented FabricArchitecture 改成 Scalable Open Financial Architecture：這個框架是能夠真正解決金融級系統的異地多活的容災和擴展問題，並且 SOFA 的可擴展能力不只是處理更多的交易，還可容納更多的業務，可以讓幾千位工程師甚至將來上萬個工程師一塊兒協同工做的可擴展架構；Open的意思是但願這個框架相對可讓業務應用很是容易使用，又能與經典架構系統有機融合，SOFA 框架將來不但能夠編排螞蟻金服工程師本身寫的業務邏輯，並且能夠編排合做夥伴的業務邏輯，成爲一個完整的編排框架；Financial 則意味着 SOFA 必須是具有金融級屬性，能真正實現金融級的一致性、可用性和穩定性。

SOFA 的設計哲學

SOFA從第一代發展到第五代，是一個異常複雜而龐大的過程，程立總結SOFA的研發方法論和經驗時表示：在整個研發方法和流程上，螞蟻金服相對於來講是以互聯網的方式去作金融，由於螞蟻金服自己就是一個金融系統，在要求很是嚴格的同時，也但願有互聯網的迭代速度，在這個過程當中沉澱下來的經驗。

第一，注重架構的治理。螞蟻金服一直有一個架構師團隊，既有總架構師團隊，同時又把各個分域的架構師集合在一塊兒，始終保持螞蟻金服的架構在一張圖上。螞蟻金服架構的迭代演進也很是清晰，從一代、二代、三代、四代到如今的第五代架構，都有很是清晰的演進階段，這是從治理層面進行頂層設計的結果。

第二，關注技術的風險。螞蟻金服研發任何系統，要比其它互聯網公司多付出可能10%的努力，去保證系統風險的可控，因此螞蟻金服技術風險管控是嵌到流程裏面、控制在整個研發生命週期裏面，從而實現了很是好的控制。固然，螞蟻金服的研發效能團隊也會把控，讓研發人員儘可能簡單、儘可能智能化。

第三，系統優化是在高度分佈化的前提下實現的。螞蟻金服是比較少有的、幾千人工做在一條業務流程上面，最核心支付流程從前端到後端分了不少層、每層裏面有不少功能，在這個過程當中可以保證很是好的分佈和集成效率以及質量，就變得很是關鍵。因此從整個項目管理的需求、分析、分解，到每一個團隊去實現，最後再作高效的集成、迭代發佈，有很是多經驗沉澱在研發部署運維平臺上。螞蟻金服的研發部署運維平臺通過多代的變化，有段時間也引進了IBM等供應商的整套方法和工具，用了兩年左右時間後發現徹底不適合螞蟻金服工做方式和速度，因此轉向自研的平臺，並不斷輕量化。但也不是外界的開源模式，由於也不適用於螞蟻金服的狀況。

第四，螞蟻金服中間件團隊的另外一個共識，Design for failure，即假定在任何狀況下底層都有不可靠的風險存在。對金融IT系統來講，任何的底層硬件臨時故障或網絡抖動都有可能被放大到資金損失或總體服務穩定性層面。對於支付寶這樣體量的互聯網應用，從設計之初就把高可靠、高可用、高性能的能力要轉到中間件層和數據庫層去保證。下面的IaaS必需要簡單，就是容許底層硬件能夠掛掉，掛掉之後由中間件和數據庫層負責。爲何會這麼作？這是由業務的容忍程度決定的，無法沉到底下的IaaS層，但也沒有必要讓每一個寫業務代碼的人都本身編寫一套代碼，因此就沉澱到中間件層。

中間件會被全部人用到、會影響全部的系統，像螞蟻金服如今有幾千個系統和上萬個微服務、幾千號研發人員，怎麼能使在中間件層作的每一項工做都能使總體架構都能平滑升級，而不要讓業務系統受影響，怎麼創建跟其餘開發人員之間的鏈接，如何平衡效率和運維，這是中間件的挑戰。

被問到SOFA 跟別的微服務平臺有什麼不一樣，楊冰舉了個例子「若是有兩套架構在頂層設計的時候，一套將平衡傾向了「成本最優」，一套則傾向了「風險最小」，在實現過程當中就會有千百次設計決策會依據這個大原則作出「架構平衡」，到最後出來的架構會徹底不一樣，就像 CAP 理論中的平衡同樣，什麼樣的業務決定着會孵化出什麼樣的技術，技術最終仍是爲業務服務的。

總結

創新都是被逼出來的，螞蟻金服自研SOFA一樣如此。SOFA走的是一條跟傳統金融行業不一樣的分佈式架構之路。要基於不可靠的硬件系統實現金融級的性能和可靠性，要應對支付寶這樣的超大規模互聯網金融應用，有不少難題要解決。螞蟻金服構建了一整套處理金融級交易的分佈式架構與平臺，在金融級的一致性要求和海量併發處理能力上達到了很好的平衡，並在快速容災恢復、彈性伸縮能力、多地多活高可用保證能力和按需供給的精細化資源調度能力方面沉澱了豐富的實踐經驗。

隨着 2015 年科技開放戰略的啓動，螞蟻金服技術的團隊面對的不只僅是內部業務，還有更加複雜多變的外部業務場景和技術挑戰。之前，技術團隊是一個被被業務倒逼的支持型組織，如今已經逐步向一個驅動業務的學習型組織和創新型組織轉變。「昨天的最好表現是今天最低的要求，因爲雙11在技術上已經成爲常態化工做，知足交易業務已經成爲了最基本的要求，因此咱們要看到更遠的將來、準備迎接更強的挑戰。」楊冰的話，從一個側面解釋了螞蟻金服技術團隊對開拓更遼闊數字金融世界邊界的期待。

「謝謝分享，你會一直作技術嗎？」

「會的。」

長按關注，獲取最新分佈式架構乾貨

歡迎你們共同打造 SOFAStack https://github.com/alipay