4月的一個周五傍晚，剛剛結(jié)束一場語音會議的明哥，拿起桌上的咖啡，一口灌了下去。同時，翻了翻攤在右手邊的筆記本，可能在思考即將拋給他的一些問題。

在華為已經(jīng)工作第15個年頭的他，目前是華為云官網(wǎng)研發(fā)團隊的技術(shù)負責人，看護著華為云對外的“門面”。

作為技術(shù)管理者，明哥有個小習慣，“每天給自己留一些靜默時間，在這段時間內(nèi)，盡量不處理郵件、工作信息，能夠做一些代碼開發(fā)、review、技術(shù)研究的工作?！?/p>

他還習慣把事務(wù)性的工作都安排在前半周，后半周能有相對完整的時間，和團隊的架構(gòu)師、設(shè)計師系統(tǒng)討論比較大的技術(shù)方案。

在鉆研技術(shù)這塊，明哥喜歡往下走，去看它的底層運行機制，它的源碼。他也是 “一萬個小時定律”的擁躉者，始終堅信積累足夠的時間和精力，一定能在技術(shù)上有所建樹，觸類旁通。

所以，他能和團隊僅用半年多的時間，完成一次幾乎不可能的挑戰(zhàn)。

再難，官網(wǎng)“門面”不能倒

在華為南京研究所露天長梯的二層平臺上，一直豎著一塊海報板：二戰(zhàn)中被打得像篩子一樣、渾身彈孔累累的伊爾2飛機，依然堅持飛行，終于安全返回。

兩年前的下午，明哥雙手環(huán)胸站在辦公室的落地窗前，緊緊盯著這塊海報，思緒卻停在十分鐘前接到的任務(wù)上：他的團隊需要在有限的時間內(nèi)，完成官網(wǎng)內(nèi)容生產(chǎn)平臺的全部自研重構(gòu)，且達到業(yè)界領(lǐng)先的水平。

這是一次走出技術(shù)舒適圈的挑戰(zhàn)，放棄他們非常熟悉的技術(shù)架構(gòu)，一切從頭開始，好比明明有一條高速公路通往終點，但是你不能走，你得自己新建一條。

這期間，華為云官網(wǎng)團隊既要保證日常業(yè)務(wù)的正常運轉(zhuǎn)，按部就班解決各種業(yè)務(wù)需求，又要抽調(diào)出足夠的人手搭建新的內(nèi)容平臺，時間緊、人手少、任務(wù)重。

在不斷的技術(shù)研討，重寫代碼，驗證測試后，項目的最小可用版本完成了showcase，彼時大家都很有成就感，也覺得終于能緩一緩了。然而一個更緊急的任務(wù)再次拋向他們：為了快速催熟產(chǎn)品，接下來的大促期間將直接使用自研系統(tǒng)。

此時離大促還有兩個月，開發(fā)團隊除了要分出一部分兵力生產(chǎn)頁面（為了確保用戶體驗，頁面要全新設(shè)計），還要補齊高并發(fā)、高可用、安全可信等產(chǎn)品化所必須的能力。通常，這樣的能力一般至少需要3到6個月，才能打磨完善的差不多。

明哥和團隊只有背水一戰(zhàn)，那段時間里，任務(wù)板上寫滿了被拆分的工作細節(jié)，新的方案不斷覆蓋舊的版本，會議室里坐陣的技術(shù)專家走了一波，又新來一波……大家拒絕妥協(xié)，一門心思埋頭往前沖。

比如，為了保證生產(chǎn)出來的頁面在任何情況下都不能丟，設(shè)計團隊翻閱了大量資料，與安全、可用性、性能專家多次討論和原型驗證，然后選擇了最‘冗余’的方案，最終成功應對多次突發(fā)情況，經(jīng)受住了大促的考驗。

歷時8個月，從項目啟動到第一個基于自研的內(nèi)容生產(chǎn)頁面誕生，官網(wǎng)團隊交出了一份漂亮的成績單。

“挑戰(zhàn)非常大，但我們成功了?！?/p>

與此同時，他們還“順帶”開發(fā)了一個PQP頁面質(zhì)量平臺，負責自動檢查頁面上線前的內(nèi)容質(zhì)量，包括頁面的404、敏感字詞、中英文單詞的拼寫、圖標的設(shè)計元素是否符合規(guī)范等等。

從接手華為云官網(wǎng)開始，質(zhì)量就是懸在明哥頭上的達摩克利斯之劍。用他的話說，“質(zhì)量這個東西，不出問題的時候大家不會覺得多重要，但凡發(fā)生問題，就會成為眾矢之的，所謂善戰(zhàn)之將無赫赫之功?！?/p>

如何保證頁面質(zhì)量穩(wěn)定，這一點往往是不少前端技術(shù)人員忽視的?！拔覀冋易稍児?，合作伙伴問了一圈，大家都沒有這樣的工具，更多的是靠流程保證，比如發(fā)現(xiàn)問題通知oncall，再逐層找到負責人。雖然管理手段能夠運行下去，但效率太低了?！?/p>

所以，將這種“人拉肩扛”的問題處理方式，轉(zhuǎn)化為工具能力，做成平臺去賦能，再貫穿到整個頁面的發(fā)布流程，是一件成就感與挑戰(zhàn)并存的事情。

當前，PQP平臺已在華為內(nèi)部“開源”，包括華為官網(wǎng)在內(nèi)的80多個網(wǎng)站都已經(jīng)接入，用于看護網(wǎng)站的內(nèi)容質(zhì)量。

談及質(zhì)量，不僅是頁面內(nèi)容的質(zhì)量，還有官網(wǎng)穩(wěn)定性的質(zhì)量。試想，12306的每一次崩潰，后面是多少用戶的吐槽罵聲。

為了維護華為云官網(wǎng)的穩(wěn)定性，他們也針對高可用做了多層保障，比如多副本的容災備份，數(shù)據(jù)多活等等，在全球4個地區(qū)的6個機房都安置了華為云官網(wǎng)的服務(wù)器，并且采購了4家不同的CDN廠商規(guī)避可能出現(xiàn)的任何主客觀風險。構(gòu)建多個逃生通道，一鍵完成流量的快速切換。就像剝洋蔥一樣，剝開一層里面依然保證完好無缺。

“華為云官網(wǎng)是我們的門面，控制臺、后臺服務(wù)或許可以掛，但官網(wǎng)就像上甘嶺的那面旗幟，哪怕是個光桿司令，我也不能倒，一定要豎在那里。”

云原生藏在業(yè)務(wù)里

門面不能倒，為了這個目標，華為云官網(wǎng)的架構(gòu)以及生產(chǎn)發(fā)布流程也在不斷優(yōu)化完善中。

以前端框架為例，React性能強大且靈活，Angular有豐富的組件，Vue簡潔易構(gòu)建，選起來頗有些亂花漸欲迷人眼。

明哥也曾陷入選擇何種技術(shù)框架的糾結(jié)中，團隊經(jīng)過一番討論，選擇了一個折中的方式——他們和web能力中心定下原則：基礎(chǔ)能力團隊維護一套主流技術(shù)框架和組件庫，各業(yè)務(wù)團隊有自己的選擇權(quán)，可以直接使用，也可以根據(jù)需要選擇其他技術(shù)棧，但核心是遵從統(tǒng)一的設(shè)計規(guī)范，達到即使不同技術(shù)棧生產(chǎn)的頁面也能讓用戶無感知差異的效果。 正所謂好馬配好鞍，讓開發(fā)人員根據(jù)各自看護的業(yè)務(wù)特性找到最匹配的框架。

但問題隨之而來，如何將這些新、老技術(shù)棧，以及不同技術(shù)框架生產(chǎn)的頁面放在一起呈現(xiàn)給用戶？

華為云引入了微前端框架，讓各個小團隊，不同的技術(shù)棧都能共生。 微前端的目的是低耦合，它把各模塊之間的影響降到最低，各模塊能按需使用不同的技術(shù)棧，從而降低技術(shù)棧切換的成本，確保產(chǎn)品平滑過渡，避免一刀切帶來的質(zhì)量風險。

同時，所有的服務(wù)都部署在容器里的，一切皆代碼。諸如應用程序、中間件、底層操作系統(tǒng)都被打包成標準的包，不管在什么環(huán)境，什么時候部署，模塊都是一樣的，不會出現(xiàn)因為系統(tǒng)、中間件版本、配置不一致引發(fā)的研發(fā)環(huán)境和生產(chǎn)環(huán)境狀態(tài)不同的情況。這也是持續(xù)交付、快速迭代的基礎(chǔ)。

從人拉肩抗的低效率開發(fā)，到如今標準的頁面發(fā)布流程，華為云官網(wǎng)的架構(gòu)也進入到一個新的階段：后臺采用微服務(wù)架構(gòu)，前端采用微前端架構(gòu)，頁面上線遵守標準的DevOps流程，化繁為簡，充分利用技術(shù)的特性，破除實際業(yè)務(wù)的瓶頸。

舉個例子，以前的網(wǎng)站開發(fā)不管是頁面功能，還是頁面內(nèi)容的變化，都繞不開發(fā)人員，網(wǎng)頁上任何一個細微的變化都得去修改html代碼或者CSS腳本。這種情況下，隨便修改一個字，開發(fā)需求排下來，小半個月過去了。

為了讓大家都能得到“解脫”，所以有了頁面生產(chǎn)平臺，可以讓業(yè)務(wù)人員自助完成頁面修改；有了可視化搭建，拖拽組件即可完成所見即所得的網(wǎng)頁制作；有了系統(tǒng)的內(nèi)容質(zhì)量檢測平臺，能夠保證頁面的安全上線。通過IT化，讓所有上線動作都高效可控，打通官網(wǎng)內(nèi)容DevOps的最后一環(huán)。

這也是明哥對于云原生的理解，“云原生本身并不能算一套架構(gòu)，它更像是一個定義，一套方法論。 打開來看，云原生無非這幾個關(guān)鍵元素：微服務(wù)、DevOps、持續(xù)交付、容器化?！?/p>

目前，DevOps方面，華為云有一套統(tǒng)一的發(fā)布流水線平臺，所有服務(wù)均通過這個平臺發(fā)布到生產(chǎn)環(huán)境；持續(xù)交付方面，華為云官網(wǎng)有65%左右的特性是通過按特性獨立發(fā)布的，每周都會有幾百個特性發(fā)布到生產(chǎn)環(huán)境上。

讓子彈再飛一會兒

康威定律里曾提到，組織的架構(gòu)決定了整體的技術(shù)架構(gòu)。由于華為云的前端和后端組織相對分離，雙方各司其職，技術(shù)溝通中難免會產(chǎn)生一些小的摩擦。不過，當前端技術(shù)浪潮洶涌而來之時，它也在試圖用技術(shù)去彌合人為原因造成的各種溝通問題。

以Node.js為例，通俗點說它是運行在服務(wù)端的JavaScript，可以讓懂JS的前端人員寫出簡單的后端服務(wù)，完成一些接口的拼裝?！巴ㄟ^Node.js，如果一個程序員針對一個簡單的需求，從前端到后端都由他自己來實現(xiàn)，由于省去溝通成本以及同步版本發(fā)布的動作，效率能提升30%?！?/p>

明哥表示，這就是我們常說的“大前端”、“全棧開發(fā)者”。而全棧能力就是消解一些組織團隊互相配合產(chǎn)生的損耗，減少損耗，自然可以給開發(fā)效率、模式帶來質(zhì)的提升。

談到開發(fā)效率的提升，時下大火的Serverless正在掀起一場云計算領(lǐng)域的革命，這場風暴也波及到了前端，對于此，明哥顯得謹慎很多。

Serverless勾勒了一個不需要搭建環(huán)境、部署中間件，沒有特定使用場景、業(yè)務(wù)類型，只需部署代碼的世界。這是技術(shù)人員的“烏托邦”，但明哥認為當前的Serverless技術(shù)有一定的局限性。開發(fā)團隊不可能只使用一種技術(shù)或者組件，而不少技術(shù)或者框架，是需要在中間件、操作系統(tǒng)層面進行分析調(diào)優(yōu)工作，Serverless目前沒有達到這個靈活性和適配性。

華為云官網(wǎng)團隊也嘗試過應用Serverless提高開發(fā)效率，比如把一些后臺執(zhí)行不敏感、可用性要求較低的服務(wù)部署上去，再通過定時器觸發(fā)，也能達到一定效果。但是只要涉及到全場景，尤其是多部件的解決方案，就不會考慮首選Serverless服務(wù)。

“可能我比較謹慎，有先進或者新的技術(shù)，習慣性觀察一陣子，讓子彈再飛一會， 技術(shù)成熟穩(wěn)定后再跟上，那個時候也不晚?！?/p>

明哥在技術(shù)棧選擇這條路上也走過不少彎路，他認為，前端團隊選擇技術(shù)棧一定要結(jié)合實際業(yè)務(wù)需求，再去觀察技術(shù)棧的生態(tài)是不是持續(xù)演進中，人云亦云、好高騖遠不可取，如果沒有合適的，寧愿自研也好過妥協(xié)。

沖破技術(shù)標簽，視野決定高度

回望前端技術(shù)的迭代，可以說是瞬息萬變，新的框架、組件庫層出不窮，新的編程語言一波波襲來……

涉獵不同技術(shù)棧的明哥一直在思索，技術(shù)的目的是什么？在建設(shè)華為云官網(wǎng)的過程中，他似乎找到了答案。

以JAVA為首的后端技術(shù)棧，在幾十年的迭代中，無論是技術(shù)語言，還是框架都趨于穩(wěn)定。相較之下，前端還朝著技術(shù)成熟曲線的峰頂狂奔中，未來也會逐漸從百花齊放過渡到一兩個成熟穩(wěn)定框架一統(tǒng)江山，一步步補全整個生態(tài)的階段。

目前一些主流框架本質(zhì)上也是大同小異，選擇一個領(lǐng)域或者技術(shù)棧深耕，愈往下探，愈會發(fā)現(xiàn)其中的一致性規(guī)律。

大浪淘沙中，明哥認為比較有潛力和探索空間的三個技術(shù)方向是沉浸式、智能化以及低碼化。

首先是沉浸式的效果，所見即所得的前端正在追求更豐富的展現(xiàn)和互動形式。比如工業(yè)制造領(lǐng)域的仿真模擬，可以對孿生的數(shù)字模型進行各種測試驗證。同樣，在前端領(lǐng)域，也能把產(chǎn)品可視化地呈現(xiàn)在網(wǎng)站上，讓用戶直觀地感知解決方案的運作模式。

說到這里，他在空氣中比劃了一下，“你想象把后臺看不見摸不著的一些組網(wǎng)解決方案搬到前臺，方案中的流程、數(shù)據(jù)流動都是可以看得到的，很神奇， 但也非?？简灪蠖藬?shù)據(jù)和前端渲染能力的結(jié)合，不過我們正在努力?！?/p>

第二個是智能化，一方面華為云官網(wǎng)團隊會在搜索和推薦中進一步優(yōu)化智能算法和策略，達到精準的千人千面智能化推薦，提升用戶的注冊轉(zhuǎn)化率；另一方面，團隊會在內(nèi)容的智能生產(chǎn)方面，包括文章、圖片、廣告等，做出更多的探索，協(xié)助運營人員、業(yè)務(wù)人員生產(chǎn)出更高質(zhì)量的內(nèi)容。

第三個方向是低碼化，現(xiàn)在多數(shù)業(yè)務(wù)人員可以自主生產(chǎn)簡單的頁面，涉及一些復雜頁面才有開發(fā)人員介入。以后，無論是面向運營人員，還是最終用戶，越來越多的頁面、接口、流程都會通過低碼化或者無碼化的方式實現(xiàn)。

前端新技術(shù)的出現(xiàn)，最終目的還是為了能夠響應業(yè)務(wù)，快速地解決生產(chǎn)、運營的需求，這也是所有技術(shù)都在探索的方向。

到了這個階段，大前端的范疇也在擴充，明哥也更習慣站在架構(gòu)師的角度去看面前呈現(xiàn)的這些網(wǎng)頁，觀察它們背后的一系列邏輯。“但凡涉及到用戶可感知的內(nèi)容，其實都是大前端要關(guān)注的，對于前端人員來說，前端不僅是一個技術(shù)，它更像是一個目的?！?/strong>

最開始，前端這個概念在業(yè)界比較模糊，前端人員都自嘲“切圖仔”，也沒有現(xiàn)在流行的三大框架，混沌初開，大家都摸著石頭過河。

這個時代已經(jīng)一去不復還，如今的前端人員，技術(shù)是基礎(chǔ)，在此之上的思維和視野則決定了技術(shù)的高度。

“比如大家常常在論壇上為哪個編程語言最好而爭得面紅耳赤。其實，囿于一個技術(shù)的優(yōu)劣，就是在給自己貼標簽。就像有的前端人員會糾結(jié)技術(shù)路線，認為寫頁面看不到發(fā)展空間，這是把自己困在‘前端’的標簽里?！?/p>

“如果你的定位是一個簡單的開發(fā)，一項技能足矣。但想要成長，得學會跳出那個圈子，換種思路，比如以提高用戶體驗為目標，可以學的技術(shù)就不只是某一個框架或語言。在此過程中，將自身的技術(shù)能力和定位從開發(fā)人員向架構(gòu)師，乃至CTO的標準去提升?！?/p>

心中有教堂，月亮和六便士，都可以擁有。