本文分享自華為雲社群《華為雲官網負責人明哥：我們是如何做到門面不倒，8個月挑戰業界翹楚？》，原文作者：華為雲社群精選 。
4月的一個周五傍晚，剛剛結束一場語音會議的明哥，拿起桌上的咖啡，一口灌了下去。同時，翻了翻攤在右手邊的筆記本，思考即将抛給他的一些問題。
在華為已經工作第15個年頭的他，目前是華為雲官網研發團隊的技術負責人，看護着華為雲對外的“門面”。
作為技術管理者，明哥有個小習慣，“每天給自己留一些靜默時間，在這段時間内，盡量不處理郵件、工作資訊，能夠做一些代碼開發、review、技術研究的工作。”
他還習慣把事務性的工作都安排在前半周，後半周能有相對完整的時間，和團隊的架構師、設計師系統讨論比較大的技術方案。
在鑽研技術這塊，明哥喜歡往下走，去看它的底層運作機制，它的源碼。他也是 “一萬個小時定律”的擁趸者，始終堅信積累足夠的時間和精力，一定能在技術上有所建樹，觸類旁通。
是以，他能和團隊僅用半年多的時間，完成一次幾乎不可能的挑戰。
再難，官網“門面”不能倒
在華為南京研究所露天長梯的二層平台上，一直豎着一塊海報闆：二戰中被打得像篩子一樣、渾身彈孔累累的伊爾2飛機，依然堅持飛行，終于安全傳回。
兩年前的下午，明哥雙手環胸站在辦公室的落地窗前，緊緊盯着這塊海報，思緒卻停在十分鐘前接到的任務上：他的團隊需要在有限的時間内，完成官網内容生産平台的全部自研重構，且達到業界領先的水準。
這是一次走出技術舒适圈的挑戰，放棄他們非常熟悉的技術架構，一切從頭開始，好比明明有一條高速公路通往終點，但是你不能走，你得自己建立一條。
這期間，華為雲官網團隊既要保證日常業務的正常運轉，按部就班解決各種業務需求，又要抽調出足夠的人手搭建新的内容平台，時間緊、人手少、任務重。
在不斷的技術研讨，重寫代碼，驗證測試後，項目的最小可用版本完成了showcase，彼時大家都很有成就感，也覺得終于能緩一緩了。然而一個更緊急的任務再次抛向他們：為了快速催熟産品，接下來的大促期間将直接使用自研系統。
此時離大促還有兩個月，開發團隊除了要分出一部分兵力生産頁面（為了確定使用者體驗，頁面要全新設計），還要補齊高并發、高可用、安全可信等産品化所必須的能力。通常，這樣的能力一般至少需要3到6個月，才能打磨完善的差不多。
明哥和團隊隻有背水一戰，那段時間裡，任務闆上寫滿了被拆分的工作細節，新的方案不斷覆寫舊的版本，會議室裡坐陣的技術專家走了一波，又新來一波……大家拒絕妥協，一門心思埋頭往前沖。
比如，為了保證生産出來的頁面在任何情況下都不能丢，設計團隊翻閱了大量資料，與安全、可用性、性能專家多次讨論和原型驗證，然後選擇了最‘備援’的方案，最終成功應對多次突發情況，經受住了大促的考驗。
曆時8個月，從項目啟動到第一個基于自研的内容生産頁面誕生，官網團隊交出了一份漂亮的成績單。
“挑戰非常大，但我們成功了。”
與此同時，他們還“順帶”開發了一個PQP頁面品質平台，負責自動檢查頁面上線前的内容品質，包括頁面的404、敏感字詞、中英文單詞的拼寫、圖示的設計元素是否符合規範等等。
從接手華為雲官網開始，品質就是懸在明哥頭上的達摩克利斯之劍。用他的話說，“品質這個東西，不出問題的時候大家不會覺得多重要，但凡發生問題，就會成為衆矢之的，所謂善戰之将無赫赫之功。”
如何保證頁面品質穩定，這一點往往是不少前端技術人員忽視的。“我們找咨詢公司，合作夥伴問了一圈，大家都沒有這樣的工具，更多的是靠流程保證，比如發現問題通知oncall，再逐層找到負責人。雖然管理手段能夠運作下去，但效率太低了。”
是以，将這種“人拉肩扛”的問題處理方式，轉化為工具能力，做成平台去賦能，再貫穿到整個頁面的釋出流程，是一件成就感與挑戰并存的事情。
目前，PQP平台已在華為内部“開源”，包括華為官網在内的80多個網站都已經接入，用于看護網站的内容品質。
談及品質，不僅是頁面内容的品質，還有官網穩定性的品質。試想，12306的每一次崩潰，後面是多少使用者的吐槽罵聲。
為了維護華為雲官網的穩定性，他們也針對高可用做了多層保障，比如多副本的容災備份，資料多活等等，在全球4個地區的6個機房都安置了華為雲官網的伺服器，并且采購了4家不同的CDN廠商規避可能出現的任何主客觀風險。建構多個逃生通道，一鍵完成流量的快速切換。就像剝洋蔥一樣，剝開一層裡面依然保證完好無缺。
“華為雲官網是我們的門面，控制台、背景服務或許可以挂，但官網就像上甘嶺的那面旗幟，哪怕是個光杆司令，我也不能倒，一定要豎在那裡。”
雲原生藏在業務裡
門面不能倒，為了這個目标，華為雲官網的架構以及生産釋出流程也在不斷優化完善中。
以前端架構為例，React性能強大且靈活，Angular有豐富的元件，Vue簡潔易建構，選起來頗有些亂花漸欲迷人眼。
明哥也曾陷入選擇何種技術架構的糾結中，團隊經過一番讨論，選擇了一個折中的方式——他們和web能力中心定下原則：基礎能力團隊維護一套主流技術架構群組件庫，各業務團隊有自己的選擇權，可以直接使用，也可以根據需要選擇其他技術棧，但核心是遵從統一的設計規範，達到即使不同技術棧生産的頁面也能讓使用者無感覺差異的效果。 正所謂好馬配好鞍，讓開發人員根據各自看護的業務特性找到最比對的架構。
但問題随之而來，如何将這些新、老技術棧，以及不同技術架構生産的頁面放在一起呈現給使用者？
華為雲引入了微前端架構，讓各個小團隊，不同的技術棧都能共生。 微前端的目的是低耦合，它把各子產品之間的影響降到最低，各子產品能按需使用不同的技術棧，進而降低技術棧切換的成本，確定産品平滑過渡，避免一刀切帶來的品質風險。
同時，所有的服務都部署在容器裡的，一切皆代碼。諸如應用程式、中間件、底層作業系統都被打包成标準的包，不管在什麼環境，什麼時候部署，子產品都是一樣的，不會出現因為系統、中間件版本、配置不一緻引發的研發環境和生産環境狀态不同的情況。這也是持續傳遞、快速疊代的基礎。
從人拉肩抗的低效率開發，到如今标準的頁面釋出流程，華為雲官網的架構也進入到一個新的階段：背景采用微服務架構，前端采用微前端架構，頁面上線遵守标準的DevOps流程，化繁為簡，充分利用技術的特性，破除實際業務的瓶頸。
舉個例子，以前的網站開發不管是頁面功能，還是頁面内容的變化，都繞不開發人員，網頁上任何一個細微的變化都得去修改html代碼或者CSS腳本。這種情況下，随便修改一個字，開發需求排下來，小半個月過去了。
為了讓大家都能得到“解脫”，是以有了頁面生産平台，可以讓業務人員自助完成頁面修改；有了可視化搭建，拖拽元件即可完成所見即所得的網頁制作；有了系統的内容品質檢測平台，能夠保證頁面的安全上線。通過IT化，讓所有上線動作都高效可控，打通官網内容DevOps的最後一環。
這也是明哥對于雲原生的了解，“雲原生本身并不能算一套架構，它更像是一個定義，一套方法論。 打開來看，雲原生無非這幾個關鍵元素：微服務、DevOps、持續傳遞、容器化。”
目前，DevOps方面，華為雲有一套統一的釋出流水線平台，所有服務均通過這個平台釋出到生産環境；持續傳遞方面，華為雲官網有65%左右的特性是通過按特性獨立釋出的，每周都會有幾百個特性釋出到生産環境上。
讓子彈再飛一會兒
康威定律裡曾提到，組織的架構決定了整體的技術架構。由于華為雲的前端和後端組織相對分離，雙方各司其職，技術溝通中難免會産生一些小的摩擦。不過，目前端技術浪潮洶湧而來之時，它也在試圖用技術去彌合人為原因造成的各種溝通問題。
以Node.js為例，通俗點說它是運作在服務端的JavaScript，可以讓懂JS的前端人員寫出簡單的後端服務，完成一些接口的拼裝。“通過Node.js，如果一個程式員針對一個簡單的需求，從前端到後端都由他自己來實作，由于省去溝通成本以及同步版本釋出的動作，效率能提升30%。”
明哥表示，這就是我們常說的“大前端”、“全棧開發者”。而全棧能力就是消解一些組織團隊互相配合産生的損耗，減少損耗，自然可以給開發效率、模式帶來質的提升。
談到開發效率的提升，時下大火的Serverless正在掀起一場雲計算領域的革命，這場風暴也波及到了前端，對于此，明哥顯得謹慎很多。
Serverless勾勒了一個不需要搭建環境、部署中間件，沒有特定使用場景、業務類型，隻需部署代碼的世界。這是技術人員的“烏托邦”，但明哥認為目前的Serverless技術有一定的局限性。開發團隊不可能隻使用一種技術或者元件，而不少技術或者架構，是需要在中間件、作業系統層面進行分析調優工作，Serverless目前沒有達到這個靈活性和适配性。
華為雲官網團隊也嘗試過應用Serverless提高開發效率，比如把一些背景執行不敏感、可用性要求較低的服務部署上去，再通過定時器觸發，也能達到一定效果。但是隻要涉及到全場景，尤其是多部件的解決方案，就不會考慮首選Serverless服務。
“可能我比較謹慎，有先進或者新的技術，習慣性觀察一陣子，讓子彈再飛一會， 技術成熟穩定後再跟上，那個時候也不晚。”
明哥在技術棧選擇這條路上也走過不少彎路，他認為，前端團隊選擇技術棧一定要結合實際業務需求，再去觀察技術棧的生态是不是持續演進中，人雲亦雲、好高骛遠不可取，如果沒有合适的，甯願自研也好過妥協。
沖破技術标簽，視野決定高度
回望前端技術的疊代，可以說是瞬息萬變，新的架構、元件庫層出不窮，新的程式設計語言一波波襲來……
涉獵不同技術棧的明哥一直在思索，技術的目的是什麼？在建設華為雲官網的過程中，他似乎找到了答案。
以JAVA為首的後端技術棧，在幾十年的疊代中，無論是技術語言，還是架構都趨于穩定。相較之下，前端還朝着技術成熟曲線的峰頂狂奔中，未來也會逐漸從百花齊放過渡到一兩個成熟穩定架構一統江山，一步步補全整個生态的階段。
目前一些主流架構本質上也是大同小異，選擇一個領域或者技術棧深耕，愈往下探，愈會發現其中的一緻性規律。
大浪淘沙中，明哥認為比較有潛力和探索空間的三個技術方向是沉浸式、智能化以及低碼化。
首先是沉浸式的效果，所見即所得的前端正在追求更豐富的展現和互動形式。比如工業制造領域的仿真模拟，可以對孿生的數字模型進行各種測試驗證。同樣，在前端領域，也能把産品可視化地呈現在網站上，讓使用者直覺地感覺解決方案的運作模式。
說到這裡，他在空氣中比劃了一下，“你想象把背景看不見摸不着的一些組網解決方案搬到前台，方案中的流程、資料流動都是可以看得到的，很神奇， 但也非常考驗後端資料和前端渲染能力的結合，不過我們正在努力。”
第二個是智能化，一方面華為雲官網團隊會在搜尋和推薦中進一步優化智能算法和政策，達到精準的千人千面智能化推薦，提升使用者的注冊轉化率；另一方面，團隊會在内容的智能生産方面，包括文章、圖檔、廣告等，做出更多的探索，協助營運人員、業務人員生産出更高品質的内容。
第三個方向是低碼化，現在多數業務人員可以自主生産簡單的頁面，涉及一些複雜頁面才有開發人員介入。以後，無論是面向營運人員，還是最終使用者，越來越多的頁面、接口、流程都會通過低碼化或者無碼化的方式實作。
前端新技術的出現，最終目的還是為了能夠響應業務，快速地解決生産、營運的需求，這也是所有技術都在探索的方向。
到了這個階段，大前端的範疇也在擴充，明哥也更習慣站在架構師的角度去看面前呈現的這些網頁，觀察它們背後的一系列邏輯。“但凡涉及到使用者可感覺的内容，其實都是大前端要關注的，對于前端人員來說，前端不僅是一個技術，它更像是一個目的。”
最開始，前端這個概念在業界比較模糊，前端人員都自嘲“切圖仔”，也沒有現在流行的三大架構，混沌初開，大家都摸着石頭過河。
這個時代已經一去不複還，如今的前端人員，技術是基礎，在此之上的思維和視野則決定了技術的高度。
“比如大家常常在論壇上為哪個程式設計語言最好而争得面紅耳赤。其實，囿于一個技術的優劣，就是在給自己貼标簽。就像有的前端人員會糾結技術路線，認為寫頁面看不到發展空間，這是把自己困在‘前端’的标簽裡。”
“如果你的定位是一個簡單的開發，一項技能足矣。但想要成長，得學會跳出那個圈子，換種思路，比如以提高使用者體驗為目标，可以學的技術就不隻是某一個架構或語言。在此過程中，将自身的技術能力和定位從開發人員向架構師，乃至CTO的标準去提升。”
心中有教堂，月亮和六便士，都可以擁有。
福利時間到：
歡迎大家到原文（https://bbs.huaweicloud.com/blogs/266278）下方踴躍留言互動，赢取我們精心準備的前端技術大禮包。
福利一： 看完華為雲官網的業務實踐，以及明哥對前端技術的思考，如果你也有業務或者技術上的疑惑，在評論區留言，明哥将空降評論區，現場答疑解惑。
福利二： 分享本文到朋友圈，截圖私信【華為雲社群精選】，小編将按點贊數選擇前3位贈送前端大禮包，内含首次公開的華為雲官網内部資料，以及明哥推薦書籍《領域驅動設計》一套。
點選關注，第一時間了解華為雲新鮮技術~