簡介： 架構師一定要有技術的廣度。大家一定要學會積累，積累到一定的程度以後，你會做到無師自通。
先自我介紹一下，我叫道延， 2014年進入阿里，在阿里通訊呆了接近兩年。2016年底到了業務平臺，當時玄難找我的第一件事就是要解決大促的問題，第二件事就是解決安全生產的問題。
我帶著這個命題進入業務平臺，來做後續一系列的事。今天趁這個機會，和大家分享一下，關於這件事和這件事背後的一些想法，以及我對架構師的一些思考。
我對技術架構的理解
1.第一點就是頂層設計。國家每5年有五年計劃，這其實就是在國家整個層面的一個非常清晰的頂層架構設計，這裡面對國民經濟重大建設專案和生產力進行宏觀的架構設計，它也是一種架構設計。在這裡面，要做什麼事要定義的非常清楚，要達到什麼樣的結果也要定義的非常清楚。
雙11的保障也是需要設計的。雙11本身是一個業務的活動事件，因為規模比較大，所以需要很多的技術來支撐這個東西。技術裡面我們可能要考慮低成本、高效率、高穩定，並且還要引入一些更多的新技術來支撐，也要把這些東西整合好，架構設計好，讓它很潤滑、很流暢地保證我們的業務。
阿里目前單元化架構達到一個什麼目標呢？透過部署異地單元將生產流量完整執行在千里之外的獨立機房，連續性的執行業務。這幾句話裡面包含了非常多的關鍵點，一個是異地，第二個是千里之外，第三個是獨立，第四個是連續性。
單元化架構的總設計師是老畢，因為我們這塊業務跟單元化的架構是非常相關的，所以要對它完成的掌握和吃透才能往下走。
3.第三大塊是應用架構，目前我們中臺裡面做的比較多的叫星環，星環說白了，它想達到架構的本質目的就是將單純的程式碼共建模式，抽象成橫向和縱向的業務包模式，做到業務與業務隔離，業務與平臺隔離。
這背後帶來的問題是什麼？我們原來產生用共建的方式支撐了50多個BU的會員、商品、交易、營銷、資金、支付、庫存逆向等等業務，其實每個裡面都是遍地開花的if else。然後程式碼的合併也難，開發也難，測試也難，上線也難，整個過程都很痛苦。所以我們當時在2015年開始一直在做星環的架構，就是讓這些東西不那麼痛苦，慢慢的解決這個問題。當然了現在我們又用了新的痛苦點。
架構師的角色關於架構師的角色，我來說說自己的想法。
1.第一個是形散而神不散。架構其實是每個應用線每個業務線都有。有些技術同學本身就是有架構師的這種角色。阿里很早以前是專門有架構師崗位，專門的去做架構，但是做著做著架構師就做沒了。因為很不接地氣，它沒有解決具體、真實、實際的問題。但現在可能更多的看到了，其實很多平臺很多應用裡面都會有一些架構師的角色，他們是在抽象這些技術問題，解決這些問題。所以第一點是行散神不散。優秀的技術同學一直在用架構的意識，解決實際的技術和業務問題，這就跟普通的技術同學有本質的區別。他不光是解決這一個問題，他可能解決這一類問題，用架構的思想去解決問題。
2.第二塊是前瞻性。為什麼你能解決這個問題，並且能解決這一類問題？一定是你要看的多，你要想的多，這需要大量的實踐和知識的積累，並且是站在過去的肩膀上。
阿里電商系統很早就開始建立了，我們這一代一代人在裡面去做架構，都是站在前一代人的肩膀上。要去看前一代人為什麼要這麼設計，去想或跟他去聊，吸取他好的地方。現在可能遇到新的問題，透過其他的方法來解決一些新的問題，需要有實踐和知識的積累。
接觸更多的人和事，用新方法解決新問題。這個很關鍵。不能只看程式碼看一個月，要找真實的業務方，你的上游，你的下游，你的合作伙伴。比如說做雙11，我是2016年12月份到業務平臺，我花了整整三個月，跟每年雙11的大隊長、重要人去聊雙11。他們是怎麼理解，怎麼來思考的，他們認為什麼地方有問題。我再找他們要一些建議：我應該怎麼去做。跟他們聊的過程中才知道我們需要做什麼樣大促，要把握什麼是關鍵點，這都是一些寶貴的財富。
3.第三點是解決複雜問題。好的架構師都在解決複雜的問題。只有複雜的問題，它才需要更多不一樣的技術或更新的技術徹底解決。高併發高可用是我們阿里電商面臨的基本面問題，但是架構師要有不一樣的高併發和高穩定性的解決思路。
當前最緊急的問題，比如說使用者體驗、提升效率、低成本。這些問題其實是非常複雜的。很多同學都想解決這個問題，很多種方法都在解決，但是整體來說效果不是特別明顯。因為它鏈路太長了，鏈路長代表影響的業務和影響的人更多，你必須得換一種新的思路來考慮這個問題。同時使用者分層，內部的技術人員增多，其實我們最終要化為一句話：要把解決複雜問題定義為架構師的一個典型角色。
架構師需要什麼樣的能力架構師需要什麼樣的能力？我參考了很多外面一些同學的分享，總結出來其實就是發現問題、分析定義問題、解決問題。
發現問題對區域性和全域性的問題需要有發現的眼光，更應該有發現未發生問題的能力，哪些是需要治標，哪些需要治本，這個是發現問題的基本判斷力。現在系統可能沒什麼大問題，但你要有發現的眼光，這些問題如果不解決，未來業務可能遇到更嚴重的問題。架構師看問題的眼光和別人不一樣，不要只看見這一個問題，還要看見這個問題背後是什麼，這一類問題背後是什麼，我怎麼能用抽象的方法解決一類問題。想好了以後，我就把當前的這個問題先解決掉，其他的問題用抽象的方式去解決它。
定義和分析問題阿里不缺解決問題的同學，但是缺定義問題的同學。你怎麼知道這是個問題，並且把這個問題定義清楚。需要將發現的問題進行抽象和歸納，定義出問題的基本要素，同時定義出問題的短期和長期方案，推進技術整體的進步。
定義問題這個要求非常高。你們平時在解決業務技術問題的時候，也要去分析和定義問題的一些能力，把一個問題定義清楚了，可以真正的能推動業務往前進。
解決問題是制定問題的實施路徑和解決方案，協同團隊和上下游，推進問題的解決。架構要解決的問題一定不是一個區域性問題，一定是一個全域性問題。架構師一定會碰到各種各樣的角色和鏈路，他要有這個能力去定義問題的解決方案和實施路徑，同時要協同團隊。他不能悶頭做事，真的要抬頭，並且是要有良好的溝通能力，跟所有的同學達成共識才能往前進。
第一點就是溝通能力非常關鍵。你怎麼把這個問題說清楚，切中問題的點，同時也能幫助上下游帶來實際的效果。第二點是架構需要能救火，但不僅僅是救眼前的火，應該救未來的火，架構師救火能力要很強。
我來阿里之前在做一個CRM的系統。剛開始前幾年一直在做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 月底被阻礙了兩次，第三次如果再沒辦法開展下去，這個事情就徹底的結束了。我們當時把整個團隊召集到一起，互相打氣：一定要幹成。遇山開道、遇水架橋，有什麼問題丟擲來，大家一起來解決，要有決心，更要果斷。