獲得國家科技獎是一種什麼體驗？

這是一個頗為凡爾賽的話題，但這位華為Fellow確實有話語權。9年前，因在通訊技術創新和產業化上做出突出貢獻，顧炯炯獲得了國家科學技術進步獎，他也是華為為數不多的最高技術等級專家，代表著華為的最強技術戰力。

如今的顧炯炯，作為華為雲的首席架構師，全域性操盤著雲服務的整體架構，從架構層面帶領華為雲實現技術和商業上的突破。

從軟體工程師到資深架構師，顧炯炯一路走來積累了豐富的架構經驗。本期華為雲社群《雲享人物·大咖面對面》採訪到這位華為內部員工眼中的“顧大師”，讓我們一起了解頂級架構師如何思考問題，如何打破常規、持續不斷的創新，如何帶領團隊構建“向上捅破天，向下扎到根”的競爭力。

揭開架構師的“神秘面紗”

在談架構前，顧炯炯講了一個故事。

任何一座建築拔地而起前，都要由建築師規劃好頂層的藍圖設計，確定建築的整體設計美學風格。土木工程師結合力學、材料學等專業知識形成可指導施工的設計圖紙，最後交由施工隊伍完成具體的建造工作。

整個流程和雲服務產品的構建類似，架構師在其中扮演的角色相當於其中的建築師，以及土木建築工程師的角色。

這也是顧炯炯給出他對自己的定位，在華為雲，他既要負責架構競爭力的規劃工作、架構創新方案設計及落地開發，還要協調各個雲服務產品下的技術方案評審和爭議仲裁，以及公共治理架構的制定維護。

看似宏觀又抽象的工作背後，也許會有人疑惑，為什麼架構師要去承擔這些工作，雲服務架構的目的又是什麼？

在公有云領域，除底層的計算儲存等基礎實施之外，上面還有包羅永珍的產品線，比如PaaS平臺、AI、IoT、音影片等等，它們彼此之間的依賴關係錯綜複雜，並涉及到不同業務領域、軟體技術元件與生態，運維管理工具的選型等，所以要構建一個類似線上網際網路業務一樣可運營、可持續敏捷低代的架構體系。

當建立了這種全棧雲的體系後，就需要一個既能掌控整體又洞悉區域性瓶頸，並依據具體業務場景給出解決方案的團隊領導型人物，這也是顧炯炯要承擔的角色定位。

他形容，“如果將每個雲服務都看作一個積木，架構師就要完成積木搭建過程，定義每個積木的形狀大小、積木之間的介面、協同及組合，從而進一步形成更大的可以滿足特定功能的‘積木’。”

那麼，宏觀的架構設計背後，是否有極具價值的方法論，讓後來者得以遵循這樣的規律，避開一些坑，少走一些彎路？

設計架構前，需要明白的重要規律

康威定律裡提到，最合適的軟體架構，永遠是與該軟體架構所解決或服務的領域業務架構，甚至組織與流程架構最匹配的。

所以在著手設計架構前，首先對業務有深入的理解，明確雲服務是線上可消費的數字化產品，而架構要解決產品的成本投入和產出問題，並服務好使用資源的使用者、雲服務運維人員等相關利益人。

這其中的挑戰在於當架構師進行頂層架構設計時，會出現跨服務領域的衝突。此時架構師並不需要深入每一個服務領域裡面，對所有技術瞭如指掌，但至少得清楚這些服務的業務層面要解決的核心技術挑戰。

基於自身經驗，顧炯炯提出，一個系統架構首先必須確保其所承載的商業目標可以達成， 也即從商用成功的目標“以終為始”反推，可以大體描摹出一個優秀的架構。

首先架構必須是完整的，它能滿足基本的業務功能需求；其次是對諸如可靠性、可用性、可運維、安全性等非功能性需求有合適的權衡取捨；最後要確保整個結構設計是可實現的。

如顧炯炯所說，“沒有一個完美的架構可以解決所有問題，也沒有一個架構是長期不‘腐爛’的，藍圖畫的再美，如果不能交付都是不切實際。”

在此基礎之上，一個優秀的架構往往具備以下五個關鍵特性：

• 架構是容易被理解、簡單的；
• 架構是穩定的，能對未來的發展趨勢做出足夠的前瞻性判斷，適應需求的變化；
• 架構考慮同類產品的需求，易於其他產品複用；
• 架構和現有人力、物力、資金、交付時間等條件匹配；
• 架構不能是一錘子買賣，它必須是容易維護和管理。

為了更具象地呈現架構設計的邏輯，顧炯炯以華為雲的架構為例做了細分拆解，解讀這種分而治之、層層分解細化的架構是如何一點點搭建起來的。

經驗之談，揭開華為雲架構設計的奧秘

一個完整的架構設計落地，必然存在一個將其自頂向下、分而治之的架構逐步分解細化、反饋修正的過程。

顧炯炯會從兩個維度來考慮具體的架構設計：業務功能，以及非業務功能的質量屬性（可靠/可用性、安全性、效能）。

• 業務功能方面

以華為雲的公有云為例，整體是雲服務商透過網際網路或企業物理專線，在自建或租用的資料中心內搭建資源池，並開發部署多樣化的平臺層、業務層的軟體。

再透過Web UI或API，以雲服務產品的形式提供給企業使用。 這些全棧雲服務產品又可進一步細分為：雲平臺、雲服務、雲運營與計費系統、雲運維監控與故障管理系統等，透過定義它們之間的API介面，並依此類推，將雲服務、雲運營計費，雲運維工具等子系統進一步進行架構拆解與細分。

• 非業務功能方面

諸如架構的解耦、韌性、安全性、可用性都至關重要。以華為雲的微服務解耦為例，它支援無資料庫及表物件的直接共享；對外API符合自宣告、自包含特徵的同時做到不對外暴內部的實現細節；各雲服務既鼓勵共享開發元件與平臺，也不排斥解耦雲服務選擇最適合的開發語言與技術元件。

顧炯炯強調，雲架構一定要執行態解耦，因此在做整體架構規劃的時候，更需要明確好頂層架構的邊界和互動關係。 在這樣的框架下，各個產品服務一方面能夠保持自己松耦合的靈活性，另一方面也必須遵從統一的治理架構開展各自競爭力的構建。

在這其中，架構師既要從“為什麼要這樣做”、“要做哪些功能”、“能構建什麼樣的差異化競爭力”等偏服務產品的宏觀視角收集架構規劃與設計的原始輸入，又要防止一頭扎進技術實現與開發細節的討論上，“只顧埋頭拉車，不顧抬頭看路”。與此同時，架構師還要從偏研發的開發實現視角判斷如何進行領域服務架構的設計與劃分。

所以，架構師既要有全域性掌控能力，又能洞悉區域性的技術實現細節。

在確定滿足業務功能的邏輯架構後，下一步再考慮底層可以選用何種技術支撐該架構， 到這一階段才涉及到具體開發語言、元件、工具的實施選擇。整個架構設計的展開則可以參考業界通用方法論：4+1架構檢視。

當然，架構設計的重點不僅聚焦於複雜軟體系統的內部構成設計。需要注意的是，API串聯了整個架構和外部世界：雲服務可以透過API被呼叫，也可用API支撐開發更復雜的應用，更高效地構建行業應用解決方案。所以雲服務API本身的開放性、易用性顯得極為關鍵， 而且考慮到使用API的是普通開發者，在開放架構設計時更要慎重思考如何讓他們更容易且高效的使用、組合API能力。

架構設計做到開放易用的同時，也要把握住其中的邊界，比如“API是否做到各雲服務及其內部各微服務解耦所要求的自宣告式，不包含內部實現狀態資訊；是否在遮蔽架構內部實現細節的同時，完整覆蓋必要的輸入與輸出引數。”

顧炯炯強調，“如今雲計算、網際網路領域對開源軟體、生態的開放性及快速迭代演進能力更為看重，因此決定了部分服務API不一定完全基於業務領域驅動的架構設計模型，有時架構邊界與API設計也會打上開源生態的烙印。”

比如計算、儲存、網路服務層的Openstack、K8S，大資料/AI層的Hadoop/Spark, Tensoflow/Caffex/MXnet等，都是華為雲堅持架構開放性、易用性的同時保持與開源生態的相容幷蓄。

敢為人先的架構創新：Regionless和柔性計算

從一個普通的技術工程師到首席架構師，顧炯炯經歷了架構迭代演進的黃金時期，他回憶道：

架構的迭代總是與技術的演進齊頭並進，從大型機時代的單體架構到PC時代逐漸形成的分散式架構“雛形”，如今越來越多的企業開始採用開放的分散式架構，也透過借鑑網際網路的成功經驗，將傳統單體軟體架構拆分為執行態充分解耦的微服務架構。

當一切應用都生於雲，長於雲，雲架構的迭代也會進入一個新的階段。新的故事，自然有新的敘事方法。圍繞雲原生2.0，顧炯炯提出了八個關鍵趨勢：分散式雲，混合排程，應用驅動基礎設施，存算分離與資料治理自動化，可信、平民化DevOps，基於軟匯流排的異構整合，多模態可迭代AI模型，全方位立體式雲安全。趨勢的詳細解讀參見：華為雲首席架構師獨家分享：雲原生2.0架構設計的8大關鍵趨勢-雲社群-華為雲

當然，架構師不僅要有洞察整體技術趨勢的敏銳力和全域性視角，還得具備一點大膽的想象力，敢於向一成不變的模式提出挑戰，打破既有格局，找到驅動新一輪成長的重要機會點。

這是顧炯炯在架構師崗位這麼多年來的心得感悟，他也一直探索能夠構建華為雲差異化競爭力的機會路徑。

Regionless：引入全域排程能力，挑戰傳統資源排程模式

以當下資料中心資源池分配不均衡的問題為例，為積極落實碳達峰碳中和要求，發改委提出了“東數西算”工程。對於公有云廠商來說，資源的均衡分配在架構層面提出了難題：如何解決東西地區的平滑引流， 讓使用者在幾乎無感知的情況下，將業務負載從東部城市平滑地遷移到西北部，比如華為雲剛剛建好的烏蘭察布資料中心。這其中涉及到地區層面的架構分層以及全域排程，乃至東部和西部資源的定價差別等等。

顧炯炯認為，由於當前很多服務分層理念的設計都沿襲傳統方式，一以貫之的模式讓資源的排程難以做到真正的平衡。這種時候，如果架構師“沒有獨立思考和質疑的能力，是很危險的。”

“每個雲服務廠商面臨的實際挑戰不一樣，唯傳統是瞻不一定正確。”顧炯炯舉例，通常情況下，使用者購買資源前都是先選Region（地區），而他們對雲服務的全球部署、網路拓撲的連線並沒有整體概念，所以雲廠商需要為使用者揭開迷霧，將資源的分佈、價格、使用現狀一一呈現出來。在架構設計上打破Region級服務的約束，引入全域排程能力，基於對算力成本最最佳化、特定雲服務及業務負載接入時延，以及應用/應用群之間的通訊耦合關係，為使用者提供最佳選擇。至於具體雲服務的資源例項發放到哪一個地理區域，完全由雲的智慧排程系統動態確定。

“這個過程我們稱之為Regionless化。”顧炯炯進一步解釋道，“把困難留給自己，我們來完成排程策略，遮蔽底層資源排程的複雜性，使用者不再需要自己選擇地理Region，得以享受全域性服務的全球部署能力。”

柔性計算：真正如用水、電一樣使用雲資源

如前所述，架構師要具備一點點反叛的勇氣，並能另闢蹊徑提出更好的解決方案，顧炯炯從架構出發提出了Regionless，試圖解決地區資源分配不均衡的痼疾。同時，他將目光瞄向了大多數人會忽略的一個問題：提高伺服器的CPU利用率問題。

“業界大部分公有云廠家都存在一個通病：有上百萬臺伺服器，但每臺伺服器的平均CPU利用率可能只有2成左右。”這個資料可能出乎很多人的意料，但現實就是如此。之前華為雲在許多數學家的幫助下，將資源分配率已普遍提高到80%甚至達到90%。然而分配率並不等於利用率：大量的計算資源雖然售賣並分配給使用者，但這些售出的計算資源中有效使用率只有1/4左右，近3/4的計算資源其實並未轉化為租戶可消費、可使用的“雲資源”。

顧炯炯表示，雖然彈性計算是主流，但並不代表它是最好的模式。使用者購買虛擬機器和容器不是最終目的，關鍵在於其中的資源能否支撐上層的應用負載，至於具體使用了多少則需要動態度量的。為此，他提出了一個概念：柔性計算。

顧炯炯打了個比方，“目前的彈性計算的計費模式，就像按照家用電器的額定最大功率乘以使用時長來計算電費，柔性計算則是按照家裡電錶的實際用電量度量收費。”

柔性計算不僅僅具備彈性的特徵，保證了橫向的資源擴充套件，而且它也能實現縱向資源規格的可大可小。目前，消費者雲已經在內部驗證了柔性計算的能力，可以在不改變上層業務的前提下提高利用率，實現效能的倍增。

“不過未來我們想實現像用水、電一樣的精細化計量計費和動態排程雲資源，還需要引入AI、大資料等技術形成閉環。”

顧炯炯強調這不僅是形式上的引入，它們會改變現在資源分配的基本邏輯：不再用資源去匹配資源，而是用動態負載匹配底層的物理\虛擬的資源。 使資源分配的依據從靜態固定的虛擬機器、容器規格，轉變為可在一定範圍內時刻動態改變CPU、記憶體利用率的“應用負載例項”。

從雲原生2.0下的八大架構趨勢，到Regionless和彈性計算的架構創新，這些都是顧炯炯身為首席架構師最常思考的問題：如何透過架構創新給使用者帶來差異化的價值。他也始終堅信 “即便既有模式已經很好，也不妨對它們提出一些質疑，也許會發現新的機會點。”

總結：

雲與IT領域的技術可謂一日千里，因此架構師在這個行當裡就好比“逆水行舟，不進則退”。架構師肩上的擔子也很重，他要做好一個大系統的架構規劃及各項重大方案設計權衡與最終落地，同時又能不囿於一些技術的細枝末節，有所取捨。這種全域性性的視野和敏銳的洞察力，再加上開闊的創造力和想象力，也是顧炯炯從一個普通技術工程師走上首席架構師的關鍵。

最後，附上顧炯炯總結的架構師能力清單，和開發者共勉： 10年經驗總結，華為fellow教你如何成為一名優秀的架構師？-雲社群-華為雲

關注@華為雲，瞭解更多資訊