是不是覺得這個標(biāo)題似曾相識？
沒錯，就是致敬韓寒的那篇《 我也曾對那種力量一無所知 》。全文主旨就是業(yè)余玩家自嗨可以，但千萬別狂妄到企圖挑釁專業(yè)選手。否則，下場就和當(dāng)初的 松江新區(qū)·奧沙利文·韓寒 一樣，在潘曉婷面前只有開球的份兒。
雖說我和韓寒同年，但也算是“看著他長大”的。韓寒成名于新概念作文，而后不斷開掛，在作家、賽車手、導(dǎo)演等多個角色上都游刃有余且扮演的相當(dāng)成功，如此色彩斑斕的人生一直讓我艷羨不已。而我，一介碼農(nóng)，初時隨波逐流，醒時已亦步亦趨在架構(gòu)之路上，艱苦非常。
因?yàn)椋軜?gòu)師的力量，我也曾一無所知。
代碼執(zhí)念
每個程序員對美的代碼的認(rèn)知不盡相同，但大多有個共識，那就是，架構(gòu)師設(shè)定的各種條條框框簡直是對美的褻瀆！
其實(shí)，你可能對架構(gòu)師的執(zhí)念一無所知！
表面看到的：架構(gòu)師成天沒事找事，發(fā)布代碼規(guī)范，設(shè)定評審標(biāo)準(zhǔn)。執(zhí)著于代碼的潔癖，分層的固化、API的標(biāo)準(zhǔn)化、中間件的抽象化...
實(shí)際發(fā)生的：光禿禿(沒注釋)的形似被混淆過(兒戲的命名|對不齊的段落)的千行代碼，事務(wù)的注解可能在每一層都出現(xiàn)過，邏輯代碼散落在Business/Service/Dao各層，只是因?yàn)椴幌矚gHibernate所以選擇MyBatis，只是因?yàn)楣雀枘X殘粉所以選擇Gson/Guava...
隨心所欲的代碼會帶來維護(hù)的困難和各種技術(shù)債，不統(tǒng)一的技術(shù)框架會引入更多的學(xué)習(xí)切換成本和升級優(yōu)化成本，評審口徑不一致會導(dǎo)致團(tuán)隊(duì)聚焦散亂各自為戰(zhàn)...架構(gòu)師作為團(tuán)隊(duì)的一個輔助型英雄，著實(shí)操碎了心。
架構(gòu)師的執(zhí)念，就是盡最大努力，在低位面減少技術(shù)熵增，高位面尋求技術(shù)突破。
通過規(guī)范指定的標(biāo)準(zhǔn)都是低位面，不需要你在低位面上浪費(fèi)任何時間扯犢子。而高位面一定是無法給出規(guī)范標(biāo)準(zhǔn)的，任你創(chuàng)新和發(fā)揮。
同樣是打印Hello World，就是有人會多渲染個ASCII字符畫，讓控制臺輸出不那么冷冰冰。
第一次看到架構(gòu)師寫出下面這種條件表達(dá)式的非常規(guī)寫法時，
if ( 1 == iCount ) {}
if ( null != response && "SUCC".equals(response.getCode()) {}
年幼無知的我曾經(jīng)“嗤”出了聲：“寫個等式都要顛三倒四，整噱頭博眼球么？” 直到我寫出了如下錯誤，
if ( iCount = 1 ) {}
//漏了等號，永遠(yuǎn)為真
if ( response != null && response.getCode().equals("SUCC")) {}
//少寫判空導(dǎo)致的空指針異常
這種代碼的反差猶如龍門客棧的老板娘金鑲玉，看似風(fēng)騷潑辣殺人越貨，實(shí)則純粹坦蕩z至情至性。
當(dāng)你傻傻的寫乘/除2的N次方時可還記得騷氣的位運(yùn)算...騷氣的try-with-resource...騷氣的Lambda...騷氣的動態(tài)字節(jié)碼...比比皆是。
這么些年我總結(jié)下來，架構(gòu)師對代碼的執(zhí)念就是八個字：穩(wěn)中帶騷，騷中求穩(wěn)。
用 Python之禪 收個尾：
造物主思維
只活在IDE里寫代碼，是成不了架構(gòu)師的。
某個風(fēng)和日麗的下午，公司里一個小伙伴到我面前說：他申請?jiān)谝粋€月內(nèi)重寫消息網(wǎng)關(guān)系統(tǒng)(承載短信、微信、郵件、App推送四大渠道)，原因是目前的系統(tǒng)太難用了。我的第一反應(yīng)是 “WOC，我一直盼望的那個救世主終于出現(xiàn)了么?!” 其實(shí)吧，那個消息網(wǎng)關(guān)系統(tǒng)曾經(jīng)是我和架構(gòu)組兄弟花不少力氣設(shè)計(jì)的，本身并沒有什么大問題，最多就是隨著消息數(shù)量的指數(shù)級上升，需要做一些性能優(yōu)化，比如 分庫分表 和 數(shù)據(jù)歸檔 就能解決大部分問題，而這些升級所需的擴(kuò)展性在設(shè)計(jì)初期就考慮過。我生怕表現(xiàn)出對這位“救世主”的質(zhì)疑而顯得不禮貌，就小心翼翼的試探了兩個問題：
“如何平衡上游業(yè)務(wù)的洪峰和下游消息通道的最大承載，最大化單位時間內(nèi)的吞吐量？”
——微服務(wù)體系的流量控制“個人交易消息和全局活動消息，如何存儲和查詢？”
——時間和空間的抉擇
結(jié)果我得到的回復(fù)只是線程池、異步化和緩存的泛泛之談，離真正的落地還差的很遠(yuǎn)。除了上面2個問題，還有同步異步、時效、延遲、通道隔離、信息補(bǔ)償、環(huán)境開關(guān)等的實(shí)現(xiàn)同樣很重要。
造物思維就是從0到1需要的思維，這個1可不簡單，它必須包含進(jìn)化到100所需要的一切基礎(chǔ)鋪墊。女媧摶tuán土造人只存在于神話中， 而架構(gòu)師就是可以從0到1創(chuàng)造系統(tǒng)的“上帝”，只是翻船事故時有發(fā)生而已。不要輕視任何從0到1的創(chuàng)造性活動，這里所包含的知識或技能體量遠(yuǎn)超你的想象。
為了解釋這個過程，請你單從數(shù)學(xué)的角度，告訴我 (0, 1) 這個開區(qū)間之中到底有多少個數(shù)？
- 如果是無窮，那么二進(jìn)制的計(jì)算機(jī)如何運(yùn)算這無窮的數(shù)字呢？有同學(xué)回答，計(jì)算機(jī)是使用離散的浮點(diǎn)數(shù)來表示這些小數(shù)的。是沒錯，而本質(zhì)上，浮點(diǎn)數(shù)在坐標(biāo)軸上也就只是很密集的點(diǎn)而已，根本就不是連續(xù)的線。
- 既然全是點(diǎn)，更加疑惑了，計(jì)算機(jī)怎么畫線呢？到這里就可以結(jié)束了，因?yàn)轱@示器的像素本就是人肉眼無法識別的小格子，足夠密集的點(diǎn)足以呈現(xiàn)出線的效果。
- 繼續(xù)刨根問底，那得了解下什么是定點(diǎn)數(shù)了，才可以讓密集的那些點(diǎn)更加的密集。
希望你能靜下心來讀讀這篇浮點(diǎn)數(shù)，
讀完你至少可以了解“取值范圍”和“可表示的個數(shù)”之間、浮點(diǎn)數(shù)和定點(diǎn)數(shù)之間的區(qū)別等等。
我想我應(yīng)該從一個理科男的角度，說明白了創(chuàng)造需要的是什么：足夠密集的知識點(diǎn)和它們之間的連接。也有人把它包裝成了“知識體系”，說到底，一個意思。
創(chuàng)造本身已然不容易，如何創(chuàng)造更加五花八門。架構(gòu)選型其實(shí)就是選擇如何創(chuàng)造。
同樣是索引化的數(shù)據(jù)存儲，Kafka是索引文件和數(shù)據(jù)文件分離，MySQL InnoDB卻是索引和數(shù)據(jù)在同一個ibd文件里。都說多線程吞吐量高響應(yīng)快，Redis卻選擇了單線程模型(Redis6已經(jīng)加入了多線程實(shí)現(xiàn)，主要用于處理網(wǎng)絡(luò)IO上。命令的執(zhí)行依然是主線程串行執(zhí)行)。孰對孰錯？
所以創(chuàng)造從來都不是千篇一律，也不是一成不變，而是量體裁衣。
高明的架構(gòu)師心里藏有無數(shù)的架構(gòu)設(shè)計(jì)方案，但對于不同的場景，他會選擇最合適的那個來實(shí)現(xiàn)。因?yàn)?strong>架構(gòu)更像一種藝術(shù)而不是科學(xué)。你只看結(jié)論的話，或許最終方案并不怎么出色，甚至很普通。但是它是經(jīng)過N個方案PK勝出的The One，對其他你以為更好的方案所面臨的未知，你可能一無所知。
面對未知的勇氣
我有深海恐懼癥，許多人都有。因?yàn)槊鎸诓灰姷椎暮Ｋ?，我們充滿了對未知的恐懼。
IT行業(yè)的未知每天都在發(fā)生著，經(jīng)常讓我們手忙腳亂。何謂"未知"？它可以是詭異的生產(chǎn)故障，可以是全新的技術(shù)，也可以是模糊的未來業(yè)務(wù)形態(tài)， 而架構(gòu)師的核心職責(zé)之一就是從容的解決未知。
就，對大家來說一樣都是未知，憑啥架構(gòu)師就有勇氣從容應(yīng)對？傻孩子，架構(gòu)師的身后哪里還有人？不得死撐哇！當(dāng)然我是在開玩笑。許多詭異的生產(chǎn)問題有重啟大法，但讓習(xí)慣了SSH編程的你，使用Reactive來實(shí)現(xiàn)一套響應(yīng)式服務(wù)端系統(tǒng)，這種未知領(lǐng)域你會如何應(yīng)對？連產(chǎn)品經(jīng)理都看不清的未來業(yè)務(wù)形態(tài)，你又會如何設(shè)計(jì)系統(tǒng)的擴(kuò)展性呢？
草木皆兵
問：你這一生碰到過的最嚴(yán)重的生產(chǎn)事故是什么？
答：抱歉，從未碰到過。
你會如何評價此人？架構(gòu)師生而從容，不僅是做到泰山崩于前而色不變，更是因?yàn)閲?yán)重的事故甚至細(xì)微的事故苗頭都早已被扼殺在搖籃之中。海恩法則指出：每一起嚴(yán)重事故的背后，必然有 29 起輕微事故和 300 起未遂先兆以及 1000 起事故隱患。
幾年前有段時間我開車總覺得方向盤有點(diǎn)松動，一直沒當(dāng)回事，覺得可能車?yán)狭嘶蛘咦约浩綍r方向打太緊了。某天預(yù)約做保養(yǎng)，車店老板小馬哥把我車開走沒10分鐘，就給我來一電話：
“你的轉(zhuǎn)向柱可能出問題了，方向盤有點(diǎn)松，你之前有發(fā)現(xiàn)么？”
“我知道的，可能車?yán)狭税桑矝]當(dāng)回事。”
“你小子，轉(zhuǎn)向問題很嚇人的，我都不敢開了，到店里馬上幫你檢查看看?！?br>
后來結(jié)果你們也想得到，真的是轉(zhuǎn)向柱斷裂！幸好在事態(tài)嚴(yán)重之前，小馬哥憑借專業(yè)素養(yǎng)發(fā)覺了這個隱患。所以這到底是是我的無知無畏還是小馬哥的小題大做？開車的同學(xué)都知道車的制動、轉(zhuǎn)向是性命攸關(guān)的大事，但是你自問對 車跑偏、剎車異響、剎車發(fā)抖、轉(zhuǎn)向沉重 都足夠警覺么？其實(shí)，架構(gòu)師在評審會上表現(xiàn)出的“草木皆兵”亦是一種執(zhí)念，他所看到的“尸橫遍野”，你可能一無所知。
知道自己不知道
給你100W讓你實(shí)現(xiàn)一個數(shù)據(jù)庫，這活敢接么？就說這活本身，先別忙嫌錢多錢少。把你所有的與數(shù)據(jù)庫相關(guān)的知識拿出來，你看看能湊出下面哪些模塊出來？
未知? 不過爾爾。
架構(gòu)師的天賦
只有天才的程序員，沒有天才的架構(gòu)師。
架構(gòu)師靠的不是天賦，而是勤勉，要靠大量時間進(jìn)行實(shí)戰(zhàn)操練和經(jīng)驗(yàn)積累。身邊水貨架構(gòu)師這么多，也是因?yàn)閲鴥?nèi)的技術(shù)氛圍略顯浮躁，留給架構(gòu)師成長的那點(diǎn)可憐的時間和空間，時刻被公司項(xiàng)目擠壓著，拔苗助長，不得不水。熱門吵架題目“架構(gòu)師要不要寫代碼”，理性點(diǎn)的人會把架構(gòu)師做個分類，摘出個比如 業(yè)務(wù)架構(gòu)師，說可以不用寫代碼。但是他不可能從石頭縫里蹦出來，若沒有對業(yè)務(wù)浸淫多年的歷練(編碼只是一個歷練維度)，如何能設(shè)計(jì)出合理的業(yè)務(wù)架構(gòu)來？所以別再問這種傻X問題了，何苦給自己的偷懶找借口還如此冠冕堂皇？寧愿換個題目討論，“架構(gòu)師的門檻是寫多少行代碼”。
技術(shù)密度
程序員起步階段的技術(shù)能力，通常是“蜂窩”狀的，也就是存在大量的技術(shù)空洞，而這些空洞需要通過勤勞的采蜜，累積一點(diǎn)一滴的“蜂蜜”來填滿?？茖W(xué)愛好者都知道中子星的密度堪比黑洞，類比將地球壓縮成中子星，直徑只有22米，普通的原子都沒辦法在中子星附近停留，會被撕碎、經(jīng)過引力坍塌后進(jìn)一步壓縮。架構(gòu)師就擅長這種吸收并壓縮知識的套路。硬要我給架構(gòu)師的天賦定一個指標(biāo)的話，那就是技術(shù)密度的高低。初二物理都學(xué)過 密度 = 質(zhì)量 / 體積。對應(yīng)到代碼，同樣質(zhì)量的一個功能，你寫一頁，架構(gòu)師寥寥幾行，這就是高技術(shù)密度的直觀體現(xiàn)。
有效練習(xí)
再來，假如已經(jīng)部分交付如上圖的一個“蜂巢”系統(tǒng)，現(xiàn)在需要你實(shí)現(xiàn)更多的“六角蜂室”以擴(kuò)充這個蜂巢。
這個工作乍看起來像不像重復(fù)勞動？
其實(shí)不然。
首先為什么選擇六邊形？ 不是圓形不是三角形不是正方形？經(jīng)測量，六邊形蜂室的所有鈍角都是109°28′，所有銳角都是70°32′。曾有法國數(shù)學(xué)家研究過，如果要消耗最少的蜂蠟，制成更少間隙、更大容積和更堅(jiān)固的容器，就只有這個角度的六邊形。
其次蜂巢是倒掛的，為何液態(tài)的蜂蜜不會流出？ 因?yàn)榉涿郾旧砗坎坏?8%，流動性比水要低得多，但低流動性不代表不流動。所以蜂巢要保持9~14度左右的傾斜，進(jìn)一步防止蜂蜜流出。
實(shí)際結(jié)果是，你的“蜂室”交付了，但是你對角度，一無所知。
我生來覺得自己是個愚人，即使學(xué)習(xí)成績一直算優(yōu)秀，也會全歸于自己的勤勉。因?yàn)樯磉叺奶觳藕孟裾娴牟恍枰ΑＮ夷艹蔀榧軜?gòu)師，也是走上程序員這條不歸路的不得已之選。架構(gòu)師之路漫長且艱難，而今我也只是摸到些許門路，大多時候?qū)τ谧约旱摹安恢馈币廊换袒滩豢山K日。
你是否也曾對架構(gòu)師的力量不屑一顧過？不管是立志成為架構(gòu)師或已然成為架構(gòu)師，都請謙虛并努力起來。誰也不敢妄言自己掌握了架構(gòu)的終極力量，因?yàn)?/p>
架構(gòu)之路越走越無知，一如人生路。
尊重架構(gòu)師的力量，一如尊重未來的你。
