我叫道延， 2014 年加入阿里，在阿里通信工作了近兩年。2016 年年底加入業務平臺團隊，當時 Leader 找我的第一件事就是要解決大促的問題，第二件事就是解決安全生產的問題。

我帶著這個命題進入業務平臺，開始了后面的故事。今天趁這個機會，和大家分享一下關于這件事和這件事背后的一些想法，以及我對架構師的一些思考。

我對技術架構的理解

第一點是頂層設計。國家每 5 年有五年計劃，這其實就是在國家整個層面的一個非常清晰的頂層架構設計，這里面對國民經濟重大建設項目和生產力進行宏觀的架構設計，本質上也是一種架構設計。在這里面，要做什么事要定義的非常清楚，要達到什么樣的結果也要定義的非常清楚。

雙 11 的保障也是需要設計的。雙 11 本身是一個業務的活動事件，因為規模比較大，所以需要很多的技術來支撐這個東西。技術里面我們可能要考慮低成本、高效率、高穩定，并且還要引入一些更多的新技術來支撐，也要把這些東西整合好，架構設計好，讓架構可以流暢地支撐業務。

第二點是物理架構。我們有單元化架構，當然很多公司也有類似的架構。但是阿里的單元化架構與其他架構相比有一些本質的區別。

阿里目前單元化架構達到一個什么目標呢？通過部署異地單元將生產流量完整運行在千里之外的獨立機房，從而連續性的運行業務。這幾句話里面包含了非常多的關鍵點，一個是異地，第二個是千里之外，第三個是獨立，第四個是連續性。

單元化架構的總設計師是畢玄，因為我們這塊業務跟單元化的架構非常相關，所以要對它完全掌握和吃透才能往下走。

第三大點是應用架構，目前中臺里面做的比較多的叫星環，星環想達到架構的本質目的是將單純的代碼共建模式，抽象成橫向和縱向的業務包模式，做到業務與業務隔離，業務與平臺隔離。

這背后帶來的問題是什么？我們原來產生用共建的方式支撐了 50 多個 BU 的會員、商品、交易、營銷、資金、支付、庫存逆向等業務，其實每個里面都是遍地開花的 if else，這就導致代碼的合并也難，開發也難，測試也難，上線也難，整個過程都很痛苦。所以在 2015 年做星環的架構時，就是讓這些東西不那么痛苦，慢慢的解決這些問題。

架構師角色

關于架構師的角色，我來說說自己的想法。

第一點是形散而神不散。架構其實是每個業務線都有，有些技術同學本身也是架構師的角色。阿里很早以前是專門有架構師崗位，專門的去做架構，但是做著做著架構師就做沒了。因為很不接地氣，它沒有解決具體、真實、實際的問題。但現在，阿里的架構師崗位逐漸增加了，他們的價值在于抽象這些技術問題，解決這些問題。所以第一點是形散神不散。優秀的技術同學一直在用架構的意識，解決實際的技術和業務問題，這就跟普通的技術同學有本質的區別。他不光是解決這一個問題，他可能解決這一類問題，用架構的思想去解決問題。

第二點是前瞻性。為什么你能解決這個問題，并且能解決這一類問題？一定是需要你看的多，想的多，這背后是大量的實踐和知識的積累，并且是站在過去的肩膀上。

阿里電商系統很早就建立了，我們這一代一代人在里面去做架構，都是站在前一代人的肩膀上。要去看前一代人為什么要這么設計，去想或跟他去聊，吸取他好的地方。現在可能遇到新的問題，通過其他的方法來解決一些新的問題，需要有實踐和知識的積累。

接觸更多的人和事，用新方法解決新問題，這個很關鍵。不能只看代碼看一個月，要找真實的業務方，你的上游、下游、合作伙伴。比如說做雙 11，我是 2016 年 12 月到業務平臺，我花了整整三個月，跟每年雙 11 的大隊長、重要人去聊雙 11。他們是怎么理解，怎么來思考的，他們認為什么地方有問題。我再找他們要一些建議：我應該怎么去做。跟他們聊的過程中才知道我們需要做什么樣的大促，要把握什么是關鍵點，這都是一些寶貴的財富。

第三點是解決復雜問題。好的架構師都在解決復雜的問題。只有復雜的問題，它才需要更多不一樣的技術或更新的技術來徹底解決。高并發高可用是阿里電商面臨的基本問題，但是架構師要有不一樣的高并發和高穩定性的解決思路。

當前最緊急的問題，比如說用戶體驗、提升效率、低成本等，這些問題其實是非常復雜的。很多同學都想解決這個問題，很多種方法都在解決，但是整體來說效果不是特別明顯。因為它鏈路太長了，鏈路長代表影響的業務和影響的人更多，你必須得換一種新的思路來考慮這個問題。同時用戶分層，內部的技術人員增多，這就倒逼我們去把復雜的問題簡化，所以我會把解決復雜問題定義為架構師的一個典型角色。

架構師需要什么樣的能力

架構師需要什么樣的能力？我參考了外面一些同學的分享，總結出來其實就是發現問題、分析定義問題、解決問題。

發現問題

對局部和全局的問題需要有發現的眼光，更應該有發現未發生問題的能力，哪些需要治標，哪些需要治本，這是發現問題的基本判斷力。現在系統可能沒什么大問題，但你要有發現的眼光，這些問題如果不解決，未來業務可能遇到更嚴重的問題。架構師看問題的眼光和別人不一樣，不要只看見眼前這一個問題，還要看見這個問題背后是什么，這一類問題背后是什么，我怎么能用抽象的方法解決一類問題。想好了以后，我就把當前的這個問題先解決掉，其他的問題用抽象的方式去解決它。

定義和分析問題

阿里不缺解決問題的同學，但是缺定義問題的同學。你怎么知道這是個問題，并且把這個問題定義清楚。需要將發現的問題進行抽象和歸納，定義出問題的基本要素，同時定義出問題的短期和長期方案，推進技術整體的進步。

定義問題這個要求非常高。大家平時在解決業務技術問題的時候，也需要具備分析和定義問題的能力，把一個問題定義清楚了，可以真正推動業務往前進。

解決問題需要實施路徑和解決方案，協同團隊和上下游，推進問題的解決。架構要解決的問題一定不是一個局部問題，一定是一個全局問題。架構師一定會碰到各種各樣的角色和鏈路，他要有這個能力去定義問題的解決方案和實施路徑，同時要協同團隊。他不能悶頭做事，真的要抬頭，并且要有良好的溝通能力，跟所有的同學達成共識才能往前進。

第一點就是溝通能力非常關鍵。你怎么把這個問題說清楚，切中問題的點，同時也能幫助上下游帶來實際的效果。第二點是架構師需要能救火，但不僅僅是救眼前的火，應該救未來的火，架構師救火能力要很強。

我來阿里之前在做一個 CRM 系統。后來我要解決很多業務的問題，要把它抽象出來，去做業務問題下面的基礎平臺。再后來發現基礎平臺的問題如果要解決得更徹底，還要做下面的中間件，這樣層層深入就會把整個鏈路打通看懂。

從 2017 年到業務平臺以后，我學到了很多，包括它的系統鏈路是什么樣的，數據鏈路是怎么樣的，整個調用鏈路是怎么樣的，它和底層的關系是什么樣的，可能遇到什么樣的問題？現在可能出現這個問題，再往后運行是不是會出現其他的問題。通過救火的過程，一次次積累對系統的了解。所以，每一次過去的積累對于解決現在的問題還都有很大的幫助，每一次問題的解決又能讓自己對全局有更深的理解。

架構師的挑戰

第一點是全局式的視角。比如看到“會員”這個業務功能，你不能僅僅看到這個功能本身，你要看到會員上面的業務是什么，誰在用會員，這叫全局。同時，會員用得最多的是導購和交易，登錄僅僅是會員本身一個很小的業務功能而已。基于會員，我們有導購、有交易，把這些東西要串起來看明白，就能完整的認識到會員到底提供了什么，一定要有一個全局視角。

第二點是技術廣度。阿里的技術特別復雜，能入職到阿里來，把阿里的整個技術棧完整摸一遍的同學真的是很了不起。以單元化架構為例，我們可能需要了解端，有 iOS、安卓、PC，還要了解 CDN、網絡、接入層、服務發現、服務路由、HSF 等。數據庫包括儲存同步、多點寫，還有消息中間件等。這些技術和產品其實平時同學們都在用，但架構師不僅在用，架構師真的是要去把玩，徹底了解透徹這些東西，這是關鍵點。

給大家舉個例子，像數據庫組成的強同步，對我們后續技術架構演進和業務的改進都有極大的影響，這個時候大家要對數據庫有一個全局的認識。

2009 年 Oracle 數據庫用得非常多。我當時不是做數據庫相關的，但是為了把 Oracle 數據庫研究透，去學了非常多 Oracle 數據庫相關的內容。了解里面的邏輯，知道它的開發態、運行態、管理態等。知識都是有延續的，后來到了阿里，可能花很短的幾個小時就能把現在阿里的數據庫吃透。

技術的廣度非常依賴于積累。你一定要帶著問題去想，這個時候你才有記憶力，有了積累，慢慢的你技術的廣度就會越來越深。你要了解數據庫，你必須對下層的網絡了解，所以我們要對網絡、CDN 有更進一步的認識。

2009 年，我大概花了兩年的時間學習網絡，對交換機、路由器、骨干網、城域網，運營商怎么建網，自建的 IDC 怎么建網有了比較全面的了解，包括每天跟網絡怎么交互，為什么重傳高？為什么延時高，TCP/IP 第 4 層的下面 IP 第 3 層是怎么操作的，IP 下面的 MAC 層是怎么操作的，大家都要深入了解一下。

這些積累最能體現出價值的就是在救火的時候。我去救火時根本不會用現在那些平臺化的工具，直接上手用 TCP 代碼抓原始發文，馬上能分析出很多問題。這就是平時的積累，慢慢的你就會對全局有認知。

2019 年整個核心系統上云的時候，同樣跟技術的廣度有關系，我們上云發生了什么變化？整個底座到云上去了，計算、存儲、網絡全到云上去了，那要了解云啊。在 2018 年的時候，我基本把阿里云的云產品都了解了一遍，這時就會對阿里云的網絡、技術有本質的了解。

架構師一定要有技術的廣度。大家一定要學會積累，積累到一定程度以后，你會做到無師自通。比如你了解網絡、數據庫，然后你又了解了磁盤30%，當這些知識逐漸成體系了，你是有能力去消化和打通不同技術點背后的相關性，對于你的個人能力的提升和認知層面的提升有巨大的幫助。

第三點是持續的學習。每時每刻都在發生技術的升級和變革，只有持續不斷的學習，才能對老的架構有新的認識，對于老的問題產生新的解法。要了解業界最近在發生什么變化，這個領域最關鍵的項目和人在做什么，學習他們的技術，學習他們的論文。我以前每天大概 2 到 3 個小時是用來學習，這幾個小時的學習時間是我最放松的時間，不用去想太多事。

學習也不是說去瞎學，一定要有體系化的。首先跟你工作相關的，要體系化的去學習，從最下到最上體系化去學習，學習完了以后你會有新的不一樣的認識。把你的想法可以向你的團隊說出來，向你的主管說出來。

還有就是要去看論文。跟數據相關的，OLTP 和 OLAP 都有非常好的論文。看了論文以后再看其他人對論文的理解。一定要去看一些比較好的東西，跟工作相關的都可以去看，每天去學習。每天花 2 到 3 個小時去學習，三年以后你就知道自己跟別人完全不一樣。有人說過：在一個行業你能付出 1 萬個小時，你會跟別人形成本質的區別。但是在我們這個領域，1000 個小時就形成差別。

第四點是業務理解。這個一定要到實踐中去，不是業務離不開架構，而是架構離不開業務，業務、架構、技術要三位一體才能達到最佳的效果。我們平時學習、實踐的過程就在磨刀，但你不能說你天天在磨刀，總得要用這個刀。這就是跟業務結合起來，用不一樣的思路解決實際的業務問題，會帶來更低的成本、更高的效率。

最后是結果。要將技術的先進性轉化為業務的先進性，忘掉屁股。這個“忘掉屁股”就是你做很多事情不是你一個人能搞定的，復雜、越大的事情是要協同更多的人。如果你就是為了你自己，比如說 KPI 去做事，我告訴你，這個事情做一次兩次可以，但后面就沒人跟你配合。你一定要忘掉屁股，才能慢慢的把這個事情做成，真正做到你想要的結果。

遇山開道、遇水架橋，這講的是決心。很多時候問題確實很難解決，也需要協調更多的人。很多人可能會放棄。我們最近在做架構的升級，用國產化芯片，從底到上全鏈路的。如果有一方配合不到位，這事情就很難推進了。從 4 月份一直到 7 月底被阻礙了兩次，第三次如果再沒辦法開展下去，這個事情就徹底的結束了。我們當時把整個團隊召集到一起，互相打氣：一定要干成。遇山開道、遇水架橋，有什么問題拋出來，大家一起來解決，要有決心，更要果斷。