華為云首席架構師顧炯炯：敢為人先，探索架構創新之路如何走

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架構是容易被理解、簡單的；

架構是穩定的，能對未來的發展趨勢做出足夠的前瞻性判斷，適應需求的變化；

架構考慮同類產品的需求，易于其他產品復用；

架構和現有人力、物力、資金、交付時間等條件匹配；

架構不能是一錘子買賣，它必須是容易維護和管理。

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

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

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

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

- 業務功能方面

以華為云的公有云為例，整體是云服務商通過互聯網或企業物理專線，在自建或租用的數據中心內搭建資源池，并開發部署多樣化的平臺層、業務層的軟件。

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

-非業務功能方面

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

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

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

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

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

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

架構設計做到開放易用的同時，也要把握住其中的邊界，比如“API是否做到各云服務及其內部各微服務解耦所要求的自聲明式，不包含內部實現狀態信息；是否在屏蔽架構內部實現細節的同時，完整覆蓋必要的輸入與輸出參數?！?/p>

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

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

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

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

架構的迭代總是與技術的演進齊頭并進，從大型機時代的單體架構到PC時代逐漸形成的分布式架構“雛形”，如今越來越多的企業開始采用開放的分布式架構，也通過借鑒互聯網的成功經驗，將傳統單體軟件架構拆分為運行態充分解耦的微服務架構。

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

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

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

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

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

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

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

“這個過程我們稱之為Regionless化?！?/p>

顧炯炯進一步解釋道，“把困難留給自己，我們來完成調度策略，屏蔽底層資源調度的復雜性，用戶不再需要自己選擇地理Region，得以享受全局服務的全球部署能力?！?/p>

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

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

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

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

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

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

“不過未來我們想實現像用水、電一樣的精細化計量計費和動態調度云資源，還需要引入AI、大數據等技術形成閉環?！?/p>

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

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

總結：

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

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

往期回顧

【第3期】：華為云首席產品官方國偉：沒有人擁有看到未來的水晶球，云上突圍之路如何走？

【第2期】：華為“天才少年”在研究什么？看謝凌曦揭秘千億參數盤古大模型

【第1期】：華為云官網負責人明哥：我們是如何做到門面不倒，8個月挑戰業界翹楚？

API 上云必讀 架構設計

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。