3月26日，51CTO訓練營邀請滴滴出行的***架構師李令輝和大家分享《架構設計之大道至簡》。他主要跟大家聊了聊他眼中架構師的道和術，以及滴滴出行所經歷的一些坎坷和寶貴經驗。

嘉賓介紹

[[165040]]

李令輝  滴滴出行 ***架構師

李令輝，滴滴出行***架構師，移動互聯網資深從業者，對移動互聯網技術發展趨勢以及技術團隊的組建有獨道見解。他具有多年互聯網架構的設計經驗，擅長高性能高并發高可用的架構設計工作，主導了滴滴打車技術迭代中的核心服務架構升級。

架構師的道和術

李令輝認為架構師這個行業有道和術，通過對道的理解，自然衍生出術。作為一個架構師，每次面臨設計，面臨問題的時候，你會有很多選擇，這些選擇是術的選擇，比如是用Java來實現還是用PHP來實現，具體采用那個框架等等。其實這些細節真的沒有那么重要，架構師真正要進行道的選擇，那就是如何讓整個事情的實現越來越復雜，還是越來越簡單。 

作為一個架構師，他最重要的工作是讓事情的實現越來越簡單，大道至簡。如果你有了大道至簡這個思維方式后，你看很多事情的視角就會變化。你會發現它們有共同的特點，通過一個方法可以解決一類問題。一個事情變簡單是非常有價值的，簡單意味著容易被別人讀懂，你不容易忘記它，甚至忘記了，重新學習也不難，改造起來很容易，發現問題的時候也一針見血，一眼就會看穿所有的問題。

做架構，什么叫做架構?架構本身是為了滿足我們人類的需求，人的腦子沒有想象的那么好使，我們只能面對一個相對來說簡單和單一的問題。架構的特點就是讓我們每個脆弱的人在處理問題的時候永遠是面臨一個或幾個簡單的問題，而不是很復雜的問題，也就是分而治之，降低管理的復雜度。

架構服務于什么?組織結構設計了軟件系統，同時架構服務于組織結構。這個聽著有點怪，但是事實就是這樣，有什么樣的組織結構，就會設計出什么樣的軟件系統。你會發現，如果兩個人屬于兩個團隊，他們同時在開發一個系統的時候，時間長了之后，他們自然會把它拆成兩個系統，A系統和B系統，或者是A模塊和B模塊的依賴關系。你會發現，在BAT這種大的公司里，每個團隊和團隊的接口之間還是蠻清晰的，很少有兩個團隊之間說，我們都負責一個東西，我提交的時候要通知你，你的團隊不要碰我的團隊的代碼。所以說，如果你想讓一個系統越來越內聚，那么你就把維護這個系統的人放到一個團隊里，讓他們向一個老板匯報，讓他們的KPI目標一致，因為這將符合你的最終目的。

當然，如果你希望他們把這兩件事情作為兩個相對獨立的事情來做，好處是可以一部分人專注于某一個事情，另一部分人專注于另一個事情，那么你就把他們拆成兩個團隊，你都不需要在架構上做太多的事情。所以架構設計是服務于組織結構的，如果你希望你的組織結構向一個你想要發展的方向去走。你就應該讓你設計的軟件架構和你的組織架構，和你未來想要的組織架構，盡量的一致。

架構師是干什么的?

架構師這個職業，嚴格來說，不止是一個知識，你要摔過很多坑，你要見識過很多組織的情況，你要做過很復雜的系統，最主要的是失敗的經驗，然后對應的解決方案，特別是其中糾結的經驗。只有這樣，你才知道在實際的生產環境和開發環境中，你該如何取舍。 

架構師的工作職責，***個是解決問題。你必須得解決所有的技術問題。第二個是提高效率，面對快速的迭代和市場的快速變化，如何低成本的去追上發展趨勢，去滿足用戶需求，是一門大學問。工作中，懂得如何提高研發的效率，提高組織結構的效率，提高產品迭代的速度，將是你打敗競爭對手的核心競爭力。第三是架構師要不斷地應對變化。因為市場是變化的，組織機構和業務形態是變化的，用戶的需求是變化的，所以架構師要不斷跟著這個產品發展思考，我們下一步該往哪個方向走，該怎么去組織我們的團隊，該怎么組織軟件的結構等。

2014年面臨的兩大挑戰和解決辦法

下面是李令輝分享的兩個實際的案例，是滴滴在2014年面臨的兩個挑戰。***個挑戰是level-0的服務，這個服務非常重要，如果掛了，整個滴滴就會停服。無論你是司機還是乘客，你的APP就用不了了。

第二個挑戰是滴滴一上線，就是一個關系到生活，國計民生的應用，它從一上來就幫助大家省錢，給大家創造財富。所以，它一開始就是一個帶錢的應用，對大部分互聯網人來說，相對是一個比較陌生的領域。

level-0服務面臨的***個問題是沒有任何安全測試，也沒有集成測試，全是拿用戶的操作測試。第二問題是性能特別差。第三個問題是已有代碼沒有人維護了。更可怕的是，它里面用到了很多奇怪的，現在不太常見的技術，比如說阿帕奇。 

作為架構師解決問題，不喜歡只解決一個問題，而是希望解決一類問題，考慮的核心訴求是什么呢?就是***別掛，第二是要能工作。所以當MySQL堵塞的時候，或者任何東西堵塞的時候，程序都不再請求他，直接返回一個值，因為程序大部分請求是不依賴于存儲的。

還有一個比較討厭的地方，它依賴于B源的存儲，這個存儲既不是開源的，也不是公司內部開發的，這個存儲不太可控，經常網絡一抖動，就發生寫入失敗。往往對同一個寫，ABC寫三次，A失敗了，B成功了，C又失敗了。***讀出的值，是隨機的，很可怕。

下面，我們看看滴滴怎么解決寫入失敗的問題，他們是保持無狀態。這是怎么實現的呢?用戶登錄的時候，程序拿時間窗、手機號、一個密鑰(這個密鑰是根據你的手機號找到的唯一密鑰)放在一起，簽個名，然后算出一段驗證碼發給用戶，只要用戶這一分鐘返回該驗證碼，程序就可以允許該用戶登錄，不依賴任何存儲。后來說這個也不行，用戶可能沒有那么快登錄回來。變通的方法是用戶試過去五分鐘的驗證碼，只要任何一次成功，用戶就可以登錄。 

做完上述這些調整后的戰績如何呢?***個，QPS到九千的時候還沒有任何感覺，到一萬的時候，稍微有點延時提高，從平均不到5毫秒的延時到10毫秒左右，其實也沒什么太大關系。因為100毫秒也是可以接受的。

再就是部署，部署變的非常容易，一個binary，它是鏡像的，然后加一個配置文件就可以上線了。可用性到了100%。99%的請求不依賴任何存儲，日志收集通過網絡實現。

這是李令輝跟大家分享的***個案例，滴滴是怎么解決遇到的問題和取得哪些成果。下面談下實施過程中，大家需要注意的細節。

首先，***要定一個比較瘋狂的目標，給大家一些士氣和沖的動力。團隊管理者定目標切忌不要定長目標，因為人的士氣，一鼓作氣，再而衰，三而竭。第二是不要太相信大團隊。做任何突擊的事情，***是兩三個人，超過這個數字，效率肯定很低。第三不要太盲目相信一些權威的意見，其實那些專家都不是你，不是那么值得相信，你可以借鑒，你可以聽取，但你要盲目的完全照搬沒有任何意義，因為你的團隊只有你自己清楚，你自己的能力，你所面臨的問題，也只有你自己清楚。

再就是在一些適當的環境中，動態語言的優勢沒有那么明顯。一個相對來說靈活性差一些，約束比較強的工程性語言會給你更多的幫助。雖然程序員的個體效率可能會有下降，但就團隊的整體效率來說，會有明顯的提升。 

下面我們談下滴滴支付面臨的第二個問題，滴滴的支付系統有兩套代碼，兩個系統。我們來說說它有什么問題。***個問題是存在多套代碼。多套代碼有什么問題呢?***問題是出了問題，工程師不知道出在哪里。第二是工程師解決了一個問題，也不知道有沒有全部解決。第三個是工程師的測試量都要大一倍，不止一倍。第四是這兩套代碼中一定有一套有問題，甚至兩套都有。

第二個問題是和業務耦合在一起。在早期的時候，滴滴并沒有人專職去開發支付，因為剛上線的時候，只是一個叫車平臺，不帶支付，用戶拿現金支付就可以。但是后來支付就作為一個普通的應用來開發了，這就有一個很大的問題。你作為一個工程師，不會把它當做一個單獨的系統來對待，這本身并沒有什么問題，問題就在于因為它是一個人開發的，或者是一伙人開發的，當它需要改動一個功能的時候，并沒有按照系統的邊界去劃分，而是怎么省事怎么來。比如說要對這些用戶進行一個補貼，或者是當金額超過多少去補貼，正常來說，你不應該在支付系統做，為什么?因為支付系統就是收錢付錢的。這個地方改動越少越好，因為不能有錯，但你想，代碼那么多處，你哪知道哪是匯聚點?大家都會改到共同的出口和入口，那就是支付模塊，因為所有的訂單都會流轉到這里。運行一段時間，你會發現支付系統在原有的系統中非常的冗余和龐大，所有的功能都耦合在里面，甚至還有免單邏輯。

這個問題你說是工程師的問題嗎?不是，從工程師的角度來說，任務很多，他永遠要選擇最快的路，***的方式去解決，能改一處，不改多處，這都是從軟件工程學到的，沒有錯。所以，工程師在這處做修改，很快就生效，他就覺得非常***，但是過了很長時間再看這個支付代碼呢?就會發現這哪是支付系統呀!什么邏輯都有，這里面還要判斷車型，判斷這個人，還要判斷他有沒有券，他的券是什么時候的，他有沒有免單，各種邏輯，是一個面條型的代碼。更可怕的是再加新的功能或者是冗余判斷的時候，你甚至不知道在哪里加，也不知道該刪掉哪些，因為好像都有用。為什么會這樣?就是因為你的組織結構的邊界沒有劃分好。

第三個問題是，支付對一致性的要求要遠遠高于其他邏輯。解決辦法是架構師需要了解事務隔離的級別，增加對一致性的理解。

第四個問題是擴展性非常差。日常代碼的實現需要能夠捕捉異常、處理事務。

第五個問題是一個系統性的問題了，依賴于單庫事務。后來滴滴把單庫事務去掉了，不再依賴事務。

***就不說什么性能差，代碼臟亂差了，這個是互聯網長期存在的問題。

滴滴的支付團隊嘗試怎么解決上述問題的呢?***，他們做了最重要的事情，給這個項目命了一個名，叫Phoenix。因為滴滴要涅槃重生，因為不重生可能就燒沒了，他們必須要重生，所以項目名稱是Phoenix。他們定了Phoenix要做的事情，互聯網公司講究的是快，什么都要快，其實想清楚比部署要快更重要，因為經常會發現想清楚是不用做，想的快比做的快更重要。正確的溝通組織結構，不是一個簡簡單單的技術問題，要順勢而為。 

所以，他們當時抽象了一套支付原語，什么叫支付原語呢?李令輝設計了像MySQL那樣協議類的東西，沒有那么復雜。在云服務PASS的時代，合作方會提供給你一整套解決方案，你調用對方的接口就可以。后面的一套東西太復雜了，滴滴做起來不值得。

第二是獨立的團隊。李令輝當時就意識到，組織結構決定了實現的方式，所以他們用獨立的團隊去做支付，不摻在原來的業務團隊里。

第三，使用Java來做開發。為什么要用新語言呢?PHP真的招不到合適靠譜的人。當時滴滴還沒有和快的合并，主要是PHP架構，但是***這個服務是用Java做的，因為Java在支付領域是非常成熟的實踐，世界上非常大的支付，包括支付寶、京東支付、銀聯的網銀在線，包括PayPal，都是Java開發的，你可以確定Java一定能解決這個問題。然后，支付團隊就孵化，保證團隊間的隔離，去事務，這是他們的前提。 

通過幾番的改動和艱苦的努力，滴滴實現了用很少的機器，其實不到十臺，撐住全公司的業務。第二個是全年無宕機，沒有任何一次主動的事故。除去外部系統，微信支付掛掉和支付寶掛掉不算在內。第三，無宕機無事故，事故和宕機不太一樣，滴滴單臺宕掉過，但是不影響服務。第四沒有回滾，這個非常重要，在2015年，他們沒有一次上線的代碼出現問題回滾。第五就是接入了滴滴公司所有的產品線。

了解更多訓練營內容： http://x.51cto.com