導語 | 成為架構師是程式設計師進階不可或缺的一條路徑，尤其在當今愈加智慧化的社會，對每位程式設計師的架構能力都提出了新的要求。本文是對騰訊雲塊儲存與虛擬化總監馬文霜、貝殼找房基礎平臺總經理&騰訊雲最具價值專家「TVP」王超、同程藝龍機票事業群CTO&騰訊雲最具價值專家「TVP」王曉波在雲+社群沙龍online的分享整理，希望與大家一同交流。
01 暢談架構演進史
王曉波：其實架構演進，這件事情在我看來正好是對自己職業生涯的一個總結，我之前是做基礎架構、中介軟體等一系列的東西，這些年在做業務架構和應用架構。
從我的角度來看，架構技術演進史可以分成兩個部分看待：一個是應用技術架構部分，一個是基礎技術架構部分，兩個演進方式和關鍵節點不太一樣。但應用架構是建立在基礎架構演進史基礎之上的。
架構演進史可以分為三個階段，首先是單體時代。在 2006 年左右，當時國內對架構師的定義還不是那麼清晰，很多人不清楚架構師是什麼。剛開始我們僅僅是把技術做得比較好，能夠規劃框架開發規範的稱之為架構師。
第一代的架構演進就是技術程式設計框架為核心展開的一系列規劃和解耦部分或者一系列的模型建設部分。那個時代來看，很多開源主要的東西都是程式設計框架，更多的是單純的程式設計。
第二代就進入了高併發、分散式，應對大流量的狀態。這個時候的架構演進更加註重的是外圍基礎設施，也就是關聯式資料庫是不是 OK、Cache 是不是 OK、整個負載是不是 OK，是不是可以做橫向的擴充套件，是不是足夠分散式，是不是足夠擁有對流量的控制，或者是不是有足夠的穩定性、高可用的控制......
這一代架構的演進特點是注重於基礎建設，就是大量的資源變成了基礎建設，應用在這個基礎上更好地迭代。
第三階段應該是基於資料的應用架構，應用架構到了現在這個狀態更加註重資料驅動，也就是越來越多的基於資料的挖掘產生新的應用。
或者可以這樣說：當“機器學習”這一類的技術不再是作為一個廣告詞推出的時候，並且真正落到系統的每一個角落的時候，那麼我們的架構新挑戰也就來到了。
這一代的資料驅動的架構更加註重的是對於海量資料的挖掘和實時應用，對於大量資料的快速計算，甚至我們要求做更快的應用開發部署，這個時候更多的特點就是延伸，更多地做資料驅動等等一系列的東西，源源不斷創造新的資料驅動架構理念。
王超：我從另一個層面來看，架構是隨著整個行業的發展和社會需要去發展的。
首先是門戶、社交時代，在 2000 年前後，當時是 PC 網際網路蓬勃爆發的年代，有四大門戶，網際網路主要是新聞內容傳遞為主。所以那個年代分散式內容分發網路，也就是 CDN 蓬勃發展。再經過幾年開始有 SNS 社交這一類的產品出現，解決的是人和人之間資訊傳遞的問題。
技術上從編譯型語言，逐步過度到動態解釋性語言的廣泛應用，便於編寫一些複雜的業務邏輯關係程式碼，同時像關係型資料庫也開始被廣泛應用。
除此之外，因為關係網路非常複雜，要滿足效能要求，開始大量應用快取，彌補關係型資料庫存取能力不足的一些場景需求。
當時還有一個快速發展的技術就是搜尋引擎，綜合搜尋解決的也是資訊快速被查詢的需求和問題，但因為是全網檢索，就對儲存、計算有了非常高的要求，這個時候呈現出了分散式系統和 NLP 的雛形，進一步提升工程能力。
第二階段是是移動網際網路階段，就是從 PC 到手機再到各種各樣的端，大家對網際網路的認知逐步加深，流量開始指數級增長。
這個時候需要的是更強的儲存和計算能力，所以雲端計算就被廣泛提出來，隨之出現了很多超大規模叢集。
最後是消費網際網路和產業網際網路的高速發展期，工程能力在上個時期已經被很好的解決了，在 IoT 廣泛應用之前不會再有指數級終端裝置聯網，基礎工程能力不再是問題，主要的技術發展會聚焦在大資料、AI 架構方面。比如，如何用圖資料庫解決複雜關係圖譜的問題，GPU 叢集、彈性計算、機器學習框架都越來越重要。
所以在我看來，架構技術的演進和發展是因為社會發展和使用者需要發生變化的。
馬文霜：曉波老師和王超老師對網際網路的產品、技術架構演進做了非常好的歸納和總結。我想以雲硬碟的技術演進給大家講一講我們在這裡的一些思考以及獲得的經驗教訓。
2013 年我們設計雲硬碟的時候認為這是一個分散式的儲存系統，騰訊在分散式系統是有著多年的積累的，分散式檔案系統 TFS、KV 儲存、CKV 都是非常成熟的產品。用成熟穩定的產品去支撐雲盤可靠性好，能夠快速上線，就集結了騰訊的三大明星產品TFS、TSSD 和 CKV，設計了雲盤 1.0。
TFS、TSSD 和 CKV，這些系統的可用性都非常好，然後用它們搭建出來的雲硬碟可用性肯定也是有保障的。冷熱分離，冷資料下沉到由 HDD 組成的 TFS 裡面，熱資料就上浮到由 SSD 組成的 TSSD 叢集當中，既保證了效能，又照顧了吞吐，還可以無限擴容、成本有優勢，各種優點可謂一應俱全。
但是到了 2014 年底，運營不到一年半的時間就發生了三次比較大的不可用故障，小問題不斷。2014 年有一次不可用時間超過十二個小時。
1.0 架構為什麼會有這麼多問題？我們認為核心的問題還是我們沒有從客戶的需求出發去做這個架構設計，這也是剛剛王超老師提到過的。我們是基於已有的技術去做架構和設計產品功能，過分強調複用已有的系統，導致這個架構複雜，難以保障可用性。
一個典型的例子是，底層儲存用的是一個 KV 的儲存系統，這個系統的特點就是對更大的鍵值更友好，承載的雲盤效能就會更好，成本也更低。
我們線上的 linux 雲主機比例更高，如果設計 4096 的雲盤給 linux 雲主機用，對於使用者來說能夠得到更好的效能，成本也更低。我們設計了 4096 和 512 兩種大小的雲盤，把 512 給 Windows 的雲主機去用，4096 就給 linux 系統用。上線以後直接遇到了使用者的瘋狂吐槽：Linux 雲主機重灌到 Windows 以後資料沒法用了。
這個例子當中我們為了支撐不同大小的雲盤把我們的系統架構做得更復雜了，本以為會給使用者帶來更好的效能，但是使用者對這個產品的功能根本不認可，不能換系統，硬碟就只能鎖定在某種系統上面，認為這個體驗非常槽糕。
經過反思，我們決定一切從使用者需求出發，總結下來其實是三個核心需求：資料可靠性、可用性、穩定的效能。
基於使用者對雲硬碟的三個核心訴求，我們設計了第二代架構。特點是扇區大小統一、一致的儲存介質、固定的叢集規模等等，靜態資料路由，設計力求簡單。
第二代架構系統的可用性有了質的提升，支撐了雲主機在 2015 年到 2016年 的快速發展。
接著，我們在第三代架構中去掉接入層，SSD 和 HDD 混合儲存降低成本，再到後面的引入 SPDK，RDMA 技術降低延遲，都非常自然。
因此我們總結的教訓是，產品的架構設計一定要基於使用者需求，在不同時期抓住使用者當時的核心痛點，演進架構，解決掉使用者的這些問題，才能成功。而不是根據已有的技術能力，YY 出產品功能，然後推給使用者，可想而知，這樣的產品一定會被使用者用腳投票，無論背後的技術架構多麼巧妙，業務註定會失敗。
王曉波：看來，合格的演進應該來自真正的需求，當需求發生了變化、體驗發生了變化，需要更多更新更好的體驗的時候，架構也將開始下一步的演進。
02 如何實現高可用架構？
馬文霜：一般來說，整個系統的可用性一定會有一個數值來度量，大家都是用當月的不可用時間除以當月的總時間，比如算下來這個可用性是 99.99% 或者 99.999%，感覺很高了。
但問題在於，系統在業務低峰期掛掉十分鐘和業務高峰期掛掉十分鐘對業務的影響可能會相差很大，如果照搬算出來的可用性又完全一樣，這個時候可用性不能反映系統的真實情況。
騰訊在內部計算可用性的時候採用了另一種演算法，不是去看這個系統，而是從請求的角度出發。因為系統都是去提供服務的，在這個系統被拒絕的請求量，加上超時的請求量，然後除以總的請求量，如果你的系統算出來的可用性接近 100%，那麼你的系統的可用性肯定很高的。
在設計、運營系統的過程當中，一定要警惕系統中單個伺服器的服務能力陡降導致的系統可用性的下降，甚至不可用的問題。
舉例來說，假如我們設計一套系統，有一個負載計算器去做請求的分發，後面接了很多的業務伺服器，單臺伺服器的 QPS 是一萬，我們接十臺伺服器上去，系統的處理能力就是十萬，如果有一臺伺服器掛掉，系統的 QPS 會降到九萬，系統的處理能力是可以被估算出來的。
我們在做架構設計的時候總是假設系統裡面的伺服器狀態是正常的，或者是故障，正常的伺服器留在了線上，故障伺服器被負載均衡器快速地踢掉。其實我們往往沒有考慮到在系統運營的過程中，單個伺服器會突然進入到了一個亞健康的狀態，這是非常常見的。
比如因為交換機異常導致轉發能力下降，這個時候伺服器的網路能力肯定就會有一個明顯的下降，CPU 如果有降頻，記憶體在做 ECC 糾錯，整個伺服器的計算能力是會有一個驟降的。
硬碟也是經常出問題的地方，硬碟異常導致 IO 延遲陡增，甚至 IO 直接 hang 住不可用。單個伺服器進入到了亞健康狀態以後，伺服器的請求能力急劇下降，甚至完全堵塞。
很多開源的系統，比如 HDFS ，就會因為單個節點的處理能力下降導致整個系統的處理能力下降，甚至整個系統就會變成不可服務。
因此我們在做高可用的架構設計過程當中一定要考慮，系統中單臺伺服器進入到了亞健康狀態，處理能力變差了以後，系統是不是仍然是高可用呢？其實從這個問題上來看，主要應對有幾個方面：
首先如果能夠從設計上避免業務請求的依賴，這個事情是比較好辦的，相當於每個業務邏輯比較單一，直接就是在單個的伺服器上面能夠完成這個業務邏輯，這樣的話即使單個伺服器處理能力下降，對系統可用性的影響也是可控的。
如果業務鏈條比較長，業務之間有依賴，就比較麻煩了。比如 HDFS 在寫資料的時候需要把三個副本寫到三個節點上面，但是這個寫作又是一個序列的寫作，這樣就會出現三個資料節點，任何一個出現寫入慢都會導致客戶端的寫入無法完成。這個業務鏈條越長，亞健康狀態或者服務能力下降的節點的影響越大。
這種情況下有通過一個全鏈路的探測和監控，快速地把這些異常的，處於亞健康狀態的節點剔除，才能讓系統可用性快速恢復。
兩三年前騰訊雲團隊在全鏈路監控，剔除亞健康狀態節點上投入了非常大的精力。比如在網路出現大面積故障的時候，其實是不能做剔除的，但如果是單個伺服器的節點網路卡異常，或者你的接入交換機故障網路效能下降，就應該快速地剔除掉，不能出現誤判。
王超：作為一個架構師真的是要對很多的細節扎得深，抽絲剝繭看其中的問題，並有針對性地解決。比如高可用怎麼定義，基於請求還是基於 RunTime 都是不一樣的，這個邊界要搞得非常清楚。架構師要看的有深度，同時又需要廣度。
舉個例子，我曾遇到過一個問題，發現團隊上線程式碼容易出現 Bug ，緊急修復再上線，結果又有新問題，每次出問題解決時間又很長，形成了一個惡性迴圈。而且，問題經常被運營和產品先發現，而技術卻第一時間發現不了，總是被動通知。
基於這個問題往下拆解，會發現每天很多團隊釋出多個專案，專案之間有些依賴問題沒有解決掉，很多團隊又同時都在發，出現程式碼衝突，並且沒有好的釋出系統，釋出完也不能做到立刻回滾。這些問題總結下來，有監控不到位、系統不完善，也有機制上的一些缺失。
作為架構師，首先要有基本的解決思路，比如如何去單點？釋出怎麼設計？怎麼監控？這些常規知識網上都能找到，但用理想的方式去解決往往週期太長，業務等不了。
在我看來，長期方案固然要有，但短期方案也非常重要。不一定需要用最理想和技術方案去解決，但可以借鑑架構的思路。
比如，能不能把這些團隊的程式碼釋出，集中到一個團隊去做，甚至一個人去做，類似解決資料庫寫衝突問題。如果釋出很多，可以分成幾個時間視窗去發。類似於 Log Structure Merge 的思路，就是合併寫，也是簡單高效的做法。
我覺得架構思路可以應用到方方面面，生產架構本質上也是一種架構，這就是我從另外一個角度去思考的架構內涵。
另外就是要分析公司的特點，比如貝殼業務都是在白天去跑，晚上沒有多少人去看房子，這個時候晚上做混沌工程，即使系統短時間出問題影響也沒有那麼大，還有時間修復。大家要學會用這種優勢提升系統魯棒性。
王曉波：完全的高可用是不是存在？這個問題需要辯證的去看，什麼樣的情況是高可用，高可用到什麼情況我們才能把這件事情做完呢？換句話說，在高可用這件事情上我們的目標是什麼？需要達到什麼樣粒度的高可用？
對我來說，我想到的第一件事情就是成本。舉個例子，如果當機影響非常大，做異地多活的話，對於整個架構來說高可用成本比較大。如果掛掉的時候能夠恢復，降低成本的方式就是降級。
對於熔斷和降級這樣可能比較廉價的高可用措施，是一個架構師的進階條件，特別是做應用系統的架構師。其實關鍵點在於明白降級要降的是什麼？在什麼條件下熔斷什麼樣的東西對我們的損失是最小的？這件事情反映了一個架構師是不是對技術有非常深刻的瞭解，或者是對基礎技術有深刻的瞭解。
做高可用架構的時候首先技術肯定是要好的，但是反過來，是不是隻要技術很好就能完全搞定？我認為不是，如果對業務流程或者業務場景不瞭解的話，會帶來非常大的問題，就是降成什麼樣子才是真正的降級？是對業務沒有影響還是對業務體驗沒有影響，或者是對整個交易的過程或者收入沒有影響？
一系列的降級方式其實完全不一樣，取決於這個架構師對於業務的瞭解，並且把這樣的業務流程模型化成一個系統架構，然後在系統架構當中完全實現如何把它降級。
所以不僅要技術好、邏輯好，還得去挑時間，最後還得比業務更懂業務。
03 如何快速把控專案架構？
王曉波：對於一個新的專案來說，對系統架構設計能力的挑戰分為兩種情況。一種是全新的、從零開始的專案。這樣的專案因為是從零開始的，需要按部就班的去做。更難的點就是接手了一個完全陌生領域的業務系統，在這種情況下挑戰很大。
大部分的架構師在實際工作當中更容易碰到這樣的問題，比如接手了一個前輩的系統，看完第一遍系統架構或者程式碼的時候心裡有“動物”在奔跑。
面對這樣的情況，他第一時間想到的事就是把整個系統的邊際和現在的系統邏輯過程看完，然後把業務梳理完，最後自己把這樣的業務和技術重新地、完整地設計出一個新的架構，完全全新，基於他自己思想。
這個全新的架構一定先放在心裡，因為在新接手專案之後的架構，從你認為的亂碼發展到你認為的好，這是一個時間的過程，這件事情其實要是通過時間、通過步驟到達最好的狀態。這個狀態如果是一步到位的話，當然不是說百分之百會失敗，但這種情況很容易會翻船。
因為從你心中最理想的那個好到現實的差，其實它的距離感不僅來自於技術的好壞，還有來自於對業務的理解，以及你對團隊的理解，包括來自於你對時間和商業成本的考慮。所以我會自己設計一個全新的架構，但我把它放在心裡，不停地用每一步的目標對標我這個心裡的最好。
那麼什麼才是最好呢？要隨著時間的發展去看，前提條件是第一次要讓這個系統能夠可用，並且達到商業目標，這是最快要做的，剩下的事情就是心中的理想。
馬文霜：接手一個新專案之後，最先要做的事去找優秀的人加入自己的團隊。畢竟任何一個架構的落地，實際上還是要有相應的程式設計師去落地。
任何一個架構首先都要簡單可控，如果一個同學跟我說做這個架構可能要花至少1年時間，比如要花一到兩個季度調研某個技術，然後再花半年時間去做相應的落地，在我看來是不可行的。
我認為應該有一種快速的、成熟的架構，去快速地試錯，然後先把這個原型搭出來。看看這個是不是使用者要的，高可用、高併發、高效能，哪個方面更重要，就投入相應的資源在上面去做相應的演進。
王超：如果我接手一個全新的專案，首先會摸清現有系統的情況，先把整個程式碼的關鍵邏輯和分層結構列出來、畫出來，弄清楚有哪些模組，模組之間是怎麼通訊的，中介軟體都有哪些，三方服務有哪些等等。之後再去分析風險點，把風險點、呈現的問題和故障列出來，再去設計合理方案。
千萬不要拿到一個通用解決方案馬上就去實施，要去分析自己的業務情況，是不是真的需要高併發、需要低延遲。
比如，傳統網際網路、電商，因為純線上操作成本低，同一時間會產生大量的請求，這種業務對併發、流控的要求就非常高。你的架構設計要考慮怎麼用佇列解偶、怎麼熔斷。
而產業網際網路線下和線上的動作是聯動的，所有的請求動作都伴隨著線下物理動作發生，所以併發請求就不會太大，就沒必要去追求幾十萬 QPS 的容量。
但 Latency 比較重要，以貝殼業務舉例，因為房地產交易有超長鏈路，完成一條鏈路可能經過三四百個服務，每個 Latency 都很高的話，請求短時間回不來，體驗就會很差。所以，要考慮怎麼縮短、合併鏈路，怎麼做快取。
另外，這種業務特點，問題的定位和追溯是比較難的。經常出現一個問題，搞不清楚到底是哪一個服務或者哪幾個服務的問題，整個排查定位成本就非常高。一個問題往往好幾個團隊都在查，就是組織的驚群問題。
那麼怎麼快速地定位，一是要對一個請求、一條資料生命週期進行 Trace 管理。二是要對平臺釋出、網路環境、中介軟體等配置的變更做感知。三是要用到一些資料分析和 AI 輔助定位。
架構師首先要了解系統現狀、業務現狀、團隊能力現狀，再因地制宜。要基於你現在的系統情況、業務情況以及團隊的組織情況去思考真正的架構，最終才會出現剛才曉波老師說的腦子裡面的畫面，做出長期規劃，按照演進路徑過渡到那個畫面 。
04 如何綜合提升架構能力？
馬文霜：我團隊裡的成員也問過類似的問題，就是該如何去提升架構能力。我認為比較有效的途徑就是去做不同型別的專案，多去解決業務問題，解決業務難題，相當於更多地去練。
但是可能有人會說：我在這個團隊當中完成自己的本職工作都顯得沒有餘力了，不太有機會能參與到其它的專案裡面，很多網際網路的技術我也接觸不到，成長很慢怎麼辦？
對此，首先肯定是要去看一些關於架構的技術書籍，或者是在雲+社群看各位老師的架構分享直播，學習一下高可用架構的思路和方法論。但從這上面只能學習到了理論基礎，更多更重要的其實還是要自己去實踐，去練。
比如高可用的架構、高擴充套件性，系統的擴充套件性怎麼去做？是不是可以在騰訊雲上面買一個負載計算器，去掛邏輯伺服器，自己搭建一個簡單的、具有橫向擴充套件能力的系統。
其實雖然沒有機會去參與專案，但還是要通過自己去搭建環境、自己去做業務、自己去模擬真實的業務場景，然後去練手。
比如要做模組解耦，那麼可以去搭建一個 Kafka 用起來，這些其實都非常簡單，尤其是現在雲的環境上面非常簡單，關鍵是我們自己要動手去練和實操。
王超：我剛開始接觸技術的時候，大家都不知道什麼才是技術架構師，隨著技術的演變，我自己也做了一些總結。首先我建議工程師和架構師要主動多去承擔和解決一些橫向的技術問題，跳出自己的技術邊界，去思考和觸及，多去推動一些橫向的事情，逐步就會有更多的機會。
另外就是要有開放的心態，無論什麼樣的新技術，可能現在不夠成熟，還是在概念期或者 POC 階段，其實都是可以去關注的，不要去排斥，同時要去學習。當然因為現在技術發展很快、方向很多，每個方向都學得很深也很難。
所以重要在於找到適合自己的，跟你現在這個領域有結合、有發展，自己又有興趣去做的，再深入進去。可以找對應優秀的開源專案看程式碼，理解它是怎麼設計的。因為架構無處不在，程式碼裡面其實也包含了很多優秀的架構設計思路，所以要去深入理解。
以馬老師熟悉的 linux 為例，發展了那麼多年到現在架構的精髓依然被應用在非常多的地方，底層核心的東西是不太會變的，一定要去深入理解。
最後一點，當你自己有了一定的沉澱、積累和產品之後，要把這個東西嘗試著去開源，放到網上讓更多的人使用、驗證、給你反饋。這個反饋非常重要，總是閉門造車、沒有反饋的話架構能力很難提升。
馬文霜：主動的同學一定是有目標的，知道自己要什麼，要去做高可用的架構的時候知道自己缺什麼，然後會給自己設定目標，比如這個月我就去做狀態伺服器的設計，下個月就去做可擴充套件性的設計，什麼時間點要完成什麼樣的目標，主動性真的是特別重要。
王曉波：程式設計師和架構師雖然是兩個名詞，但我認為，程式碼才是正道。架構師只是一個過渡階段的某種時期的詞語，就是程式設計師當中的一個片段。其實本質上每個人都是技術世界分工的一部分，不管是程式設計師還是架構師，或者是測試和運維，本質上來說都是程式設計師，因為我們都在為程式碼工作，我們的工作內容都是程式碼。
想要成為一個優秀的架構師首先要定義的是自己想成為一個什麼樣的架構師，這件事在整個成長的過程當中非常重要。如果目標是像馬老師這樣對 Linux 非常瞭解，那就需要未來掌控整個儲存技術。
架構的意義在於我們怎麼去理解技術的原理，真正深入計算機原理，計算機是什麼，儲存是什麼，為什麼今天這樣的東西存在，然後去想像這件事情，不停地在這裡探索一系列的東西。
如果目標是像王超老師這樣去做商業的決策，去解決產業鏈的問題，除了去了解技術的原理之外，可能也要加上一些商業原理。因為這件事情本質上是在做商業作業系統，所以深入瞭解可能也不太一樣。
我和王超老師的成長經歷很相似，剛開始都是做技術架構，然後又轉到應用架構。在這個過程中我們都會碰到一個問題：技術怎麼會越做越寬？我的優勢點好像由某個點變成了一個面。
其實我想說的是整個過程可能也是程式設計師到優秀架構師的轉換過程，應用架構師應該把面拓寬，因為架構師和程式設計師的本質差別在於全域性思維的不一樣，如果只是寫一行程式碼完成一個功能，思維會停留在這樣的一個角落。
但如果要從架構師出發其實需要升得更高，就是從全域性的角度去看待整個專案、整個系統，整個要完成的任務的邊界在哪裡，難度在哪裡，解耦部分在哪裡，才可以把這個架構設計好。
另外，如果我們只是一味站在這個高度去看，沒有深入直接地去做技術的話，其實就會變成技術型產品經理，能夠設計很好的產品，但需要找一位兄弟幫我變現。
所以架構師一定要自己去做很多的技術，而且有自己實現技術的能力。技術的東西太多了，展開面的同時要去把點突破，然後深入某些點去做某些點的深入，有點有面之後，這樣的一個架構師一定是優秀的架構師。
那麼什麼是點和麵的架構師的區別呢？有位同學曾碰到過一個奇怪的現象，就是跑著跑著突然自己的程式不見了，這對於上面的業務來說是癱瘓級了，起來了又不見了，這是很恐怖的。
架構師可能會先看應用有沒有自己的 BUG，因為是突然就不見了。要是知識面更拓寬一點的同學就會說我們把 DB 的程式碼看一下，是不是 DB的 Bug 造成的。最後發現也不是，那就試試重啟大法。正在苦惱的時候，他遇到了一位老前輩，提醒他去看看核心，是不是這個版本的核心有問題，終於解決了問題。
如果在設計架構中，知識面不全，站的高度不夠，深度也不夠的話，設計出來的技術架構永遠是留在 PPT 裡的架構。技術發展到今天，架構的基礎技術百花齊放，但架構的本質意義上還是在於整個技術面、技術深度這兩方面，一個寬度一個垂直，兩個方向真正的掌握了，這樣才能得到更好的結果，這也是高可用或者架構設計最核心的部分。
馬文霜：我非常認同一句話“架構能力就是解決問題的能力”。我認為優秀的同學一定有一種特質，就是對技術有好奇心，遇到一個問題會非常興奮，去思考這個到底是怎麼產生的，該如何解決，有哪些解決方案。
這也是問題驅動，無論是老闆分派的問題還是看到別人正在解決什麼問題，都會提起興趣，也有迫切把它解決掉的態度。這是可以驅動能力更好發展的。
王超：技術是一個領域，程式設計師是一個職業，架構是一個能力，是這樣的三個層次。架構是可以穿越很多職能的，比如寫程式碼，程式碼關注擴充套件性和魯棒性，會有外掛設計等。系統有架構、還有產品架構、組織架構、商業架構，可謂無處不在。
技術出身一個非常大的受益之處就是從一開始就在鍛鍊這種思維，既是一種思維也是一種能力，這種能力會隨著時間不斷成長，無論做什麼都要有這種架構的思維和能力，這種就是可遷移能力。
大家一定要去長期培養和珍惜架構的思維和能力，既有深度又有廣度，過程當中一定會帶來新的認知，新的成長倒逼能力的提升，形成這種良性的迴圈。
05 Q&A
Q：monodb的那個問題，你們除了在翻看核心找問題的同時系統頻繁癱瘓，你們怎麼做的？
王曉波：因為系統頻繁癱瘓，那個時候又沒法快速地解決這個問題，業務還是要保證的。因為我負責的是整個技術架構，包括運維團隊都是歸屬於技術架構，發生故障後我們當時首先做的是去止損。
為什麼要先做止損呢？理論上來說除了常規的看流量有沒有增加，有沒有發生變更，除此之外就是發生了一件未知現象，所以首先需要止損降級。
如果是故障的一剎那來做這件事是很難的，這件事一定要做在之前。也就是在故障之前要對整個系統有了解。架構師和運維要了解每一個使用的東西在什麼場景出現，在什麼場景不可用。
當時我們就是決定把相關業務降級，對於商業來說，這個時候的損失是最小的。降級之後的第二件事情就是快速地去解決它。
總結下來在這樣的情況下，事前準備非常重要，作為基礎架構和基礎運維團隊，最重要的就是對自己的業務充分了解，每個可疑的點上去把應變方案、相應的降級方案做起來，然後演練這些東西也要做起來。
Q：請教老師，雲環境的負載均衡高可用是如何保障的？
馬文霜：雖然我不是做負載均衡的，但是稍微有些瞭解，可以把我的瞭解和這位同學分享一下。
針對外網的負載均衡，會有一個 BGP 的排程，這是端到端可用性保證。比如現在你的負載均衡器是放在上海，假如現在你是從廣州訪問上海，就是走最近的 BGP 的鏈路訪問上海。假如廣州到上海的鏈路斷掉了，騰訊雲會做 BGP 路由的釋出，把這個 BGP 的路由釋出到北京，廣州去訪問上海的負載均衡的時候會繞到北京，然後去訪問到你的負載均衡，這個時候延遲會略有增加，但至少在我們的鏈路斷掉的情況下會有一個可用性的保障。
負載均衡器是在我們的雲機房的閘道器的出口，以叢集的方式去提供服務的，一般都是有好幾臺，現在騰訊雲的負載均衡還具備遷移的能力，某一個叢集因為一些機器有些故障或隱患，比如記憶體有些隱患，這個時候我們會把負載均衡器從一個叢集遷移到另外一個叢集。遷移的過程當中對外的業務是完全不感知的，這樣的話可以保證負載均衡器的高可用。
Q：從哪裡能夠學習到真正的架構技術？
王超：現階段學習架構其實已經比十幾年前容易太多了，像騰訊雲+社群都提供了非常多的資料、文章和課程供大家學習，而且這些課程都是成體系化地梳理出來傳授給大家。
二十年前大家基本上沒有什麼資訊，能夠做的學習架構就是看開原始碼，甚至開源專案都很少。所以早期的架構經驗都是從 Linux 核心中學到的。
現在學習門檻已經非常低了，有很多描述原理的書，要能夠深入到程式碼邏輯，比如分散式系統的選舉策略，為什麼用這種選舉策略，資料一致性策略，強一致或弱一致性的實現，資料同步怎麼實現等等，要深入到這種程度。
Q：系統出故障了，怎麼快速定位問題？
王超：怎麼才能快速定位，要訓練這種能力。比如程式被殺掉了，通過coredump、source mapping，可以很容易定位到哪一行程式碼，這是作為優秀工程師最基本的一個能力。
Q：樓盤字典中包含個人住址資訊， 如何防止被拖庫？
王超：防拖庫的方法差不多，要對資料脫敏，個人和住址也要分開存放，用的時候拿到金鑰再去組織，金鑰也要動態更新，單獨被讀取只能是一個無法識別的資料片段。
Q：架構演進的未來是什麼？10年後會和現在有什麼不同嗎？
王曉波：這個提問正好和我們的主題倒過來的，我們講的是架構演進史，我們是站在今天總結過去。其實從本質上來說我們也不知道，因為還沒有到時間，十年之後我們再來開一次會議，在那個點總結這個事情。
本質上來講，架構的演進這件事情一定不會停止，但是會發展到哪裡確實很難預料得到，不過未來十年的架構原理一定不會變化。
未來十年架構長什麼樣我們很難估計，但這十年當中的架構思路一定不會變化，就是基於更多的計算機的技術，瞭解更多的技術，然後對技術更加深入，用更新更深入的技術去反思今天的架構，讓它發展到下一代，更多地用技術去考慮商業，更多地考慮業務邏輯，然後用技術的方式去解決它，這件事情肯定是不會變的。
Q：任務急，時間短，怎麼做架構？
王曉波：剛才我們在講的過程當中也有講到，架構設計一定是天時地利人和，也就是整個背景都很重要。比如老闆覺得不應該花太長時間，因為需要解決商業的問題，直接給我懟程式碼，那這個時候架構師怎麼辦？
剛開始我自己在做架構師的時候其實對這件事情非常反感，因為我覺得任何一個技術，任何一個系統都應該好好設計，然後再去動手。
隨著時間的推移，我發現這件事情真的要重新考慮一下。因為對於商業來說，明天就是商業最後期限，如果明天不去搶佔這個市場，可能這件事情就不用做了。好好做架構這件事情應該是認真對技術負責，認真觀察商業，然後確定商業的邏輯。
那麼是不是我們應該去趕一下時間？還是去趕一下技術？當然，在這種情況下你自己的判斷不一定是正確的，畢竟是一個技術人員，最強的一項就是技術，可能你的老闆是一個商人，可能他對商業的敏感度更大一點，這件事情應該去聽老闆的，但也並不代表我們真的是要直接去懟程式碼，符合條件的基礎上我們對這些東西之後的技術債要記下來，然後在後面把它還掉，可能這就是一個相對來說比較可以接受的結果。
畢竟技術人員在這件事情上永遠是矛盾，就是當時間和技術發生衝突的時候選擇哪一個，但是從更成熟的考慮來說，對於商業思路的服從可能需要更大一點，因為能夠真正解決生存的問題，因為程式碼本身不印錢，但是解決生存的問題之後一定要把這個技術債還掉。
Q：架構師都需要什麼技術素養？
馬文霜：我覺得架構師首先應該是一個程式設計師，這個大家應該都認同。不是說做架構師只會做架構不會寫程式碼，架構師應該都是從程式設計師成長起來的，或者團隊已經沒有人了，現在架構要落地的時候你能上。
我覺得要先能寫程式碼，整個技術棧從底層到上層，比如底層作業系統的原理、核心、實現，然後再到上層的網路，資料庫的設計、資料庫的優化，應該說我們做程式設計師的過程當中都會涉及到的。
再往上就是一些分散式、大資料的系統，網路通訊的框架，加上 RPC 的框架，其實都是非常有必要去掌握的，還有訊息中介軟體等。
另外，現在比較流行的雲原生和容器技術，這些都是需要去掌握的。架構師主要的能力是在解決問題，當你的團隊遇到問題的時候，無論是技術問題還是業務問題，或者是其它的一些團隊的合作相關的問題，架構師都應該能夠上，衝在前面。
技術上面能夠有點子出來，開啟團隊思路，能夠讓團隊去嘗試解決問題，我覺得這是架構師技術的素養。
Q：自己搭的系統，沒使用者怎麼暴露問題？
馬文霜：先前我建議同學自己去搭系統，自己去練手，沒有使用者的話你就做你係統的使用者，可以做很多的機器人測試客戶端出來，往你的系統發請求，這些都是可以的。
我們都有很多的測試工具可以用起來，跟真實系統還是有差別的。但是這給你係統帶來的流量壓力，測試你係統的可用性，這些都是可以的。
Q：想要成為架構師應該著重培養形成哪些競爭力？
馬文霜：這裡我從另外一個角度去說，前面說了架構師技術的素養，解決問題的能力，我覺得另外一個角度的話就是架構師不是一個人在戰鬥，而是帶著一群人在解決某一個業務的問題。
這個過程當中需要讓你的團隊有戰鬥力，這是你的競爭力。帶領團隊解決業務問題，對外的話你怎麼說服你的兄弟團隊接受你的方案，怎麼去說服老闆去給你投相應的資源，讓你完成這個專案，其實這些都是一些軟實力，我覺得也都非常重要。
Q：三位老師還招人嗎？
王超：期待行業技術夥伴們的加入，一起為新居住產業貢獻力量。歡迎投放簡歷 surr@ke.com
王曉波：我們常年在招各路優秀的程式設計師，就是廣義的程式設計師，架構師、運維、測試，包括產品經理全部在招。
我們的 Base 很豐富，可以來到北京享受一下霧霾，也可以來到天府之國成都，我們的總部是在蘇州，這個地方也很好，可以一邊寫程式碼一邊吃大閘蟹。搜我們的招聘頁和域名都可以，域名很好記，Ly.com。
馬文霜：我這邊也是從底層技術到上層應用、後臺開發，都是需要的。我招人只看一點，如果你的主動性夠好，學習能力夠強，在某一方面能力出眾，都歡迎你給我發簡歷：kevinnma@tencent.com。