作者 | 道延 責編 | 張文
來源 | 轉載自阿里巴巴中間件(ID:Aliware_2018)
我叫道延, 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 月底被阻礙了兩次,第三次如果再沒辦法開展下去,這個事情就徹底的結束了。我們當時把整個團隊召集到一起,互相打氣:一定要干成。遇山開道、遇水架橋,有什么問題拋出來,大家一起來解決,要有決心,更要果斷。
“面向對象就是一個錯誤!”
好的架構不是設計出來的,是逐步演進出來的.