先自我介紹一下，我叫道延， 2014年進入阿里，在阿里通訊呆了接近兩年。2016年末到了業務平臺，當時玄難找個人第一件事就是要解決大促的問題，第二件事就是解決安全生產的問題。數據庫
我帶着這個命題進入業務平臺，來作後續一系列的事。今天趁這個機會，和你們分享一下，關於這件事和這件事背後的一些想法，以及我對架構師的一些思考。安全
我對技術架構的理解
1.第一點就是頂層設計。 國家每5年有五年計劃，這其實就是在國家整個層面的一個很是清晰的頂層架構設計，這裏面對國民經濟重大建設項目和生產力進行宏觀的架構設計，它也是一種架構設計。在這裏面，要作什麼事要定義的很是清楚，要達到什麼樣的結果也要定義的很是清楚。微信
雙11的保障也是須要設計的。雙11自己是一個業務的活動事件，由於規模比較大，因此須要不少的技術來支撐這個東西。技術裏面咱們可能要考慮低成本、高效率、高穩定，而且還要引入一些更多的新技術來支撐，也要把這些東西整合好，架構設計好，讓它很潤滑、很流暢地保證咱們的業務。網絡
2.第二大塊是物理架構。 你們在阿里可能都據說過，咱們有一個比較有名的單元化架構，其實不光阿里有單元化架構，不少公司都有相似的架構。好比微信。阿里和他們的單元化架構其實有一些本質的區別。架構
阿里目前單元化架構達到一個什麼目標呢？經過部署異地單元將生產流量完整運行在千里以外的獨立機房，連續性的運行業務。這幾句話裏面包含了很是多的關鍵點，一個是異地，第二個是千里以外，第三個是獨立，第四個是連續性。併發
單元化架構的總設計師是老畢，由於咱們這塊業務跟單元化的架構是很是相關的，因此要對它完成的掌握和吃透才能往下走。less
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 月底被阻礙了兩次，第三次若是再沒辦法開展下去，這個事情就完全的結束了。咱們當時把整個團隊召集到一塊兒，互相打氣：必定要幹成。遇山開道、遇水架橋，有什麼問題拋出來，你們一塊兒來解決，要有決心，更要果斷。
【阿里巴巴中間件】專一於微服務、容器服務、Serverless……等雲原生熱門話題。 關注同名公衆號獲取更多精彩內容和福利！