另類架構(gòu)之駕車感悟

1、 【另類架構(gòu)】之駕車感悟 本系列說明遙想當(dāng)年研發(fā)們仰視的架構(gòu)師，一出手一出口必是一套套(?)，讓人感覺他們?nèi)鐠叩厣裆闵畈豢蓽y，反駁都找不到趁手的詞匯，雖然當(dāng)時(shí)總覺得哪里不對?，F(xiàn)而今不同了，架構(gòu)師理論方面的書籍或者視頻資料已然汗牛充棟，整個(gè)程序員群體都可以或多或少說上一些架構(gòu)理論，可能理解不深刻，但是起碼有武器可以拿來跟架構(gòu)師懟。所以，現(xiàn)在架構(gòu)師真的沒那么容易混了。本文(或者系列?.如果我不懶的話)的立意與常規(guī)的架構(gòu)講述套路不同，筆者想通過生活小細(xì)節(jié)或者小啟發(fā)來延伸出一些架構(gòu)思想，以期讓人有更加深刻的理解。最近干貨的出貨量大大降低，實(shí)在是精力不太夠(其實(shí)正在醞釀，敬請期待)。最近的幾篇都是生活

2、中的靈光一現(xiàn)，寫出來的東東竟然也有不小的啟發(fā)性和可讀性。今天要說道的，正是迎著朝陽駕車上班途中偶感所得。變道提前打燈上海中環(huán)和羅山高架路上的不少電子警示牌，不厭其煩地提示著變道請?zhí)崆?秒打轉(zhuǎn)向燈，以前看到了也就看到了，因?yàn)楣P者一直很守法，一般提前5秒就打了，所以此警示從未驚起什么波瀾。某日清晨腦回路猛然搭住，就想如果變道不打燈被視作違章的話，這個(gè)識別的程序邏輯該怎么設(shè)計(jì)呢？砍材不誤磨刀功，不了解的領(lǐng)域準(zhǔn)備工作還是要充分調(diào)研的：大眾熟知的闖紅燈識別，步驟是通過路口的三個(gè)感應(yīng)線圈觸發(fā)攝像頭的三次拍照，命中三次就視為違章，筆者開始也是想當(dāng)然的認(rèn)為攝像頭大部分都是靠拍照。后來跟專業(yè)的同學(xué)求證，新一代交

3、通攝像頭的工作原理其實(shí)大約是這樣子的：攝像頭會持續(xù)拍攝交通情況的視頻，而在攝像頭所在位置附近會有個(gè)本地的存儲器和處理器，視頻就存儲在那里，而后處理器會基于圖像識別或者人工智能blablabla等技術(shù)手段分析視頻中的違章情況，一旦識別出就會截取視頻生成圖片，最后這些高清截圖會上傳到遠(yuǎn)程的市局服務(wù)器存儲，而違章截圖也是從此而來（該信息只是單方面求得，如有偏差歡迎指正）。繼續(xù)又去查了一下，汽車轉(zhuǎn)向燈的頻閃間隔大約是1Hz，也就是一秒鐘閃爍一次，當(dāng)然也有0.5秒閃爍一次的，這個(gè)汽車行業(yè)和國家并沒有硬性規(guī)定。拋開圖像識別的領(lǐng)域不談，剩下的實(shí)現(xiàn)難度在哪里呢？且讓我直接寫三個(gè)案例來闡明：Case 1變道前的

4、4.01秒開啟轉(zhuǎn)向燈，到3.01秒的時(shí)候轉(zhuǎn)向燈剛好熄滅，到2.01秒的時(shí)候轉(zhuǎn)向燈再次亮起。Case 2變道前的4.99秒開啟轉(zhuǎn)向燈，到3.99秒的時(shí)候轉(zhuǎn)向燈剛好熄滅，到2.99秒的時(shí)候轉(zhuǎn)向燈再次亮起。Case 3需求只提到了提前3秒這個(gè)下限值，那上限值應(yīng)該是多少呢？我可否提前5秒打轉(zhuǎn)向，甚至提前1分鐘打燈呢？很明顯間隔太久的轉(zhuǎn)向燈完全沒有意義，所以這個(gè)需求描述是有缺陷的。剖析解讀Case 1 & 2兩個(gè)案例類似，都在3秒前打燈了所以肯定不違章，但是3秒這個(gè)時(shí)點(diǎn)上轉(zhuǎn)向燈都是熄滅狀態(tài)。視頻分析所需的時(shí)間窗口當(dāng)然不能卡在3秒這個(gè)時(shí)點(diǎn)上，那么需要放大到多少合適呢？案例1的時(shí)間窗口必須不小于3.02秒，

5、案例2不小于4秒。注意，這里說的是時(shí)間窗口的下限。而Case 3主要說的是時(shí)間窗口的上限，因?yàn)槲也豢赡馨褧r(shí)間窗口設(shè)置到無限大，按照交通實(shí)際情況，1分鐘開外的轉(zhuǎn)向警示基本無意義了。經(jīng)查交通法規(guī)里確實(shí)沒有這方面的描述，看來對于“提前”這件事情大家都知道很難量化的定義它。再考慮一下需求設(shè)計(jì)問題：（架構(gòu)師的基本素質(zhì)之一 -質(zhì)疑需求&明確需求）1. 是選擇提前“時(shí)間”合適還是提前“距離”合適？選擇“時(shí)間”就會出現(xiàn)上面的時(shí)間窗口臨界問題。選擇“距離”，在不同的車速狀況下，“車速”越快打轉(zhuǎn)向燈的提前距離就應(yīng)該越大，若是需要再嚴(yán)謹(jǐn)些的描述，這個(gè)“車速”應(yīng)該是前后車的“相對速度”，想想是不是如此？2.對于汽車的

6、轉(zhuǎn)向燈頻閃頻率國家似乎并沒有一個(gè)統(tǒng)一標(biāo)準(zhǔn)，那就意味著有長有短，進(jìn)一步造成時(shí)間窗口的不可確定性。3.閃爍次數(shù)前文也簡單提過，基于頻閃頻率的最小閃爍次數(shù)也需要保證，否則連2S的時(shí)間窗口都看不到轉(zhuǎn)向燈亮起過，這視頻沒法分析了。另外，基于3個(gè)案例假設(shè)我們設(shè)定時(shí)間窗口為變道前的-5s, -3s，表示這個(gè)時(shí)間區(qū)間內(nèi)必須出現(xiàn)過轉(zhuǎn)向燈的亮起狀態(tài)。如果某個(gè)極端情況轉(zhuǎn)向燈在-5s，-3s僅亮起一次，(-3s, 0) 再也沒有亮起過，也就是轉(zhuǎn)向燈總共就閃了一次而已，警示作用很不明顯，那么對于轉(zhuǎn)向燈的最小閃爍次數(shù)是否有要求呢？經(jīng)筆者對自己車子的多次測試，開啟一下轉(zhuǎn)向即使馬上關(guān)閉，轉(zhuǎn)向燈也至少閃爍3次。(對測試當(dāng)日跟我

7、車屁股后面的司機(jī)師傅們深表同情，你們可能一直在罵前面那個(gè)傻叉為什么一直在打轉(zhuǎn)向？)解決方案透過問題看本質(zhì)無非就是時(shí)間窗口的臨界設(shè)定問題。首先簡單放大時(shí)間窗口這么低級的方案肯定為架構(gòu)師所不齒，因?yàn)樵俅蟮臅r(shí)間窗口都可能會存在臨界問題，而且時(shí)間窗口越大處理器分析的壓力就越大。這里我要祭出本人一直以來作為架構(gòu)師灰?；页Ｖ匾呛苋菀妆缓鲆暤囊粭l原則：“能用規(guī)范化和標(biāo)準(zhǔn)化來解決的問題，就不要再花更多的成本用在工程手段上”。此原則在創(chuàng)業(yè)公司尤其適用。比如費(fèi)盡九牛二虎之力研發(fā)了一個(gè)元數(shù)據(jù)管理系統(tǒng)，可以對業(yè)務(wù)系統(tǒng)里各類風(fēng)格迥異千奇百怪格式的日志進(jìn)行解析，后果是這個(gè)元數(shù)據(jù)系統(tǒng)可能永遠(yuǎn)跟不上業(yè)務(wù)系統(tǒng)更新的速度，而

8、你只能跟在屁股后面不停的修正這個(gè)元數(shù)據(jù)系統(tǒng)。如果寫個(gè)日志組件，規(guī)定讓所有的業(yè)務(wù)系統(tǒng)必須集成，直接打印出規(guī)范的統(tǒng)一標(biāo)準(zhǔn)的日志來，元數(shù)據(jù)系統(tǒng)的設(shè)計(jì)就可以相當(dāng)簡單了。再比如運(yùn)維耗盡全力為了實(shí)現(xiàn)基于容器化的持續(xù)部署，不得不為每個(gè)業(yè)務(wù)系統(tǒng)不統(tǒng)一的變量聲明方式編寫大量的yaml配置文件，為什么不能讓業(yè)務(wù)系統(tǒng)統(tǒng)一改造成規(guī)范的變量配置方式呢？相信這才是一勞永逸且最省力的方式吧。回到轉(zhuǎn)向燈的問題上來，我的解決方案首選壓根就不是技術(shù)方案，而是先把上面提到的所有不確定的問題先制定出標(biāo)準(zhǔn)來。比如閃爍頻率，最少閃爍次數(shù)等。解決方案我會用軟件產(chǎn)品的幾個(gè)典型場景來類比，讓大家自己去聯(lián)想吧。銀行日終跑批銀行支付類金融系統(tǒng)都會

9、有日切，做一些停業(yè)記賬、清算、會計(jì)日期切換等操作，而這個(gè)窗口就算時(shí)間足夠的短，也不得不停止某些業(yè)務(wù)比如轉(zhuǎn)賬，這段時(shí)間也就是銀行日切黑暗期。有的銀行在晚上 9-11點(diǎn)，有的在凌晨1-2點(diǎn)，不一而足。首先對于龐大的信息系統(tǒng)要做好時(shí)間的完全同步和一致是基本不可能的，所以時(shí)間窗口可能產(chǎn)生交叉，由此出現(xiàn)任何的賬務(wù)數(shù)據(jù)異常，都是很可怕的一件事情。TCP的滑動窗口實(shí)現(xiàn)前面描述的所有細(xì)節(jié)都是基于變道這個(gè)時(shí)點(diǎn)來往前倒推，如果用類似TCP的滑動窗口方式呢？比如我們就設(shè)定5秒的滑動窗口，交通攝像頭我們估算一秒100幀的水平，那么5秒的窗口里就有500幀圖像需要處理。對滑動窗口內(nèi)的每幀圖像進(jìn)行識別，標(biāo)示出當(dāng)前轉(zhuǎn)向燈亮

10、暗的狀態(tài)，當(dāng)某一幀識別出變道動作，那只要把-5s, -3s)區(qū)間內(nèi)的圖像識別的轉(zhuǎn)向燈狀態(tài)做個(gè)簡單的運(yùn)算即可，就算區(qū)間再大一些也完全不是問題。當(dāng)然轉(zhuǎn)向燈閃爍間隔是一秒的話連續(xù)100幀圖像都應(yīng)該是一樣的狀態(tài)，如果只是做轉(zhuǎn)向燈的識別那么可以把粒度放寬直接跳過其他的99幀，如果也做其他的違章識別另當(dāng)別論。隨著處理器給出分析結(jié)果，窗口向后滑動，繼續(xù)處理新幀和等待處理器的應(yīng)答，如此循環(huán)往復(fù)。另外，流式數(shù)據(jù)處理框架Spark Streaming也采用了滑動窗口實(shí)現(xiàn)方式。Minimum Window Substring算法最小覆蓋子串算法，也是從滑動窗口延伸的一個(gè)算法，當(dāng)然也有數(shù)據(jù)結(jié)構(gòu)的小竅門。因?yàn)橐∽钚。?/p>

11、所以也涉及到如何收縮窗口讓子串最小。請考慮如何讓收縮窗口讓視頻分析的區(qū)間更小呢？算法講解參見/p/ce80b4c07c22分布式鎖的臨界問題分布式鎖的實(shí)現(xiàn)方案很多，市面上以Zookeeper, Redis實(shí)現(xiàn)的居多。不管是哪種，都要考慮這么一個(gè)問題：持鎖的進(jìn)程在釋放鎖之前崩潰了，導(dǎo)致鎖一直在無法釋放的狀態(tài)。為了避免這種情況，一般會設(shè)置一個(gè)鎖失效時(shí)間，這個(gè)時(shí)長設(shè)定一般要比99%的持鎖時(shí)間久，那么就引入另一個(gè)問題，假如持鎖的進(jìn)程A就是不小心抖動了一下導(dǎo)致持鎖時(shí)長超過了失效時(shí)長，而失效機(jī)制導(dǎo)致鎖的釋放就意味著進(jìn)程B也可以持有這個(gè)鎖。A B兩個(gè)進(jìn)程同時(shí)持有鎖，我就問你怕不怕！我就問你慌不慌！不然的話，

12、或者你的系統(tǒng)允許這種極端情況的發(fā)生，有一定的容錯(cuò)能力，大不了最后再補(bǔ)救?；蛘吣阈枰粋€(gè)雙向的鎖檢測機(jī)制，客戶端在邏輯鏈路上的關(guān)鍵節(jié)點(diǎn)不斷檢測鎖的剩余時(shí)間，然后基于自己估算的仍需時(shí)間延長鎖的失效時(shí)間，反過來，服務(wù)端也可以檢測客戶端的持鎖時(shí)長，在超時(shí)那一刻，通知客戶端必須做出鎖失效/快速失敗的回滾處理等等。這些細(xì)節(jié)都不是那么容易操作的，所以我也就拋出個(gè)思路，拿走不謝。移步理解鎖以及分布式鎖路面積水問題當(dāng)日是個(gè)雨后的早晨，四處都有積水。這是發(fā)生在“變道轉(zhuǎn)向”之后再次讓我陷入思考的第二件事。示意圖如上，我要說的積水問題必須是在高架上下閘道口的坡面上的。為什么我不說更常見的平坦路面的積水區(qū)呢？因?yàn)樽鳛橐?/p>

13、個(gè)有素質(zhì)的老司機(jī)，經(jīng)過平坦路面的積水區(qū)時(shí)路邊若是有行人，必然速度放緩慢慢前行，以防積水潑濺到路人。而在高架坡面上因?yàn)橐曇爸锌床坏礁呒艿紫碌男熊嚮蛘咝腥?，有些時(shí)候下意識的就沖過去，高架下方“爭渡爭渡驚起一灘鷗鷺”。這里還是友情提醒一下，駕車但凡涉水不管什么情況都要放緩，這對別人對自己都沒壞處。那么這個(gè)故事到底對架構(gòu)有借鑒意義呢？請大家思考：路面為什么會有積水？積水情況是否有監(jiān)控？我只是高架路面設(shè)計(jì)師，如何想得到高架下的行車或行人？路面為什么會有積水原因無非兩個(gè)，路面不平整或者沒有傾斜度，排水系統(tǒng)不給力。對于路面施工的質(zhì)量問題，沒什么好說的，施工和驗(yàn)收環(huán)節(jié)都沒做到位。而依賴的排水系統(tǒng)不給力，對于高

14、架施工隊(duì)來說這個(gè)鍋好像是可以甩給排水系統(tǒng)團(tuán)隊(duì)的。無需多言，這里我要類比的軟件架構(gòu)類別是“服務(wù)治理”。很明顯高架路面系統(tǒng)依賴了排水系統(tǒng)，那我們就來說道說道限流、路由、熔斷、降級這四塊。限流比較容易理解，我的排水管道就這么粗，你拿盆往里灌肯定噴出來，所以超出排水管道處理能力的水就不收了。那多的這些水怎么處理呢？不知道大家有沒有聽過“海綿城市”，通過一些特殊材料或特殊管道設(shè)計(jì)，將這些水先蓄在某些地方，以后隨時(shí)可以拿來澆澆公園的花草啥的也算有效利用，架構(gòu)里這就是常見的“削峰”，一般通過MQ隊(duì)列來實(shí)現(xiàn)。當(dāng)然還有更簡單粗暴的就是水從哪里來回哪里去，我路邊整幾排燒紅的鐵棒，水一沾上就變?yōu)檎羝舭l(fā)掉了(好像發(fā)

15、現(xiàn)了什么了不得的發(fā)明), 架構(gòu)里對應(yīng)的就是“快速失敗”，既然系統(tǒng)已經(jīng)處理不了你了，就直接給你個(gè)失敗應(yīng)答完事。路由就是把水引流到不同的排水口(多個(gè)排水口可以理解成排水系統(tǒng)的分布式多節(jié)點(diǎn))，污水和雨水是不同的排水通道，這個(gè)可以叫灰度或A/BTest；大雨會啟動更多的排水口進(jìn)行排水，或者易積水路段使用大的排水口，這個(gè)叫“彈性擴(kuò)容”或者“權(quán)重路由”。熔斷就像家里的保險(xiǎn)絲，當(dāng)排水系統(tǒng)達(dá)到自己能力的上限，水再也進(jìn)去不去的時(shí)候（響應(yīng)超時(shí)或持續(xù)報(bào)錯(cuò)），排水口可以考慮自動關(guān)閉。等排水系統(tǒng)緩過勁來之后，可以打開排水口繼續(xù)接受排水，這里需要不時(shí)的去探測排水系統(tǒng)是否恢復(fù)，決定何時(shí)再開啟排水口。此處的熔斷就是為了保護(hù)排

16、水系統(tǒng)本身，不要因?yàn)榇罅康乃嗳雽?dǎo)致排水管道的破裂脫節(jié)之類的惡劣情況發(fā)生。降級之前要先分級，在排水壓力很大的情況下，可以讓關(guān)鍵核心路段的積水先排掉別讓交通完全癱瘓，其他邊緣路段就自我犧牲一下先關(guān)閉主動排水口，也就是說在排水能力有限的情況下，把優(yōu)先權(quán)讓給關(guān)鍵核心，這種是資源搶占式的降級；假設(shè)平日的排水是在管道流動的過程中加入了過濾雜質(zhì)的功能，以防大形體的垃圾進(jìn)入排水系統(tǒng)堵塞住出水口，那在暴雨天氣排水壓力很大的情況下，是否可以考慮關(guān)停過濾功能，或者把過濾的標(biāo)準(zhǔn)放寬，這樣排水的過程必然順暢很多，這種是裁剪枝節(jié)、降低失敗率、提高關(guān)鍵流程吞吐量的降級。積水情況是否有監(jiān)控這個(gè)問題其實(shí)有一定的迷惑性，積水這

17、種表象級別的監(jiān)控絕對不是我們的目的，而是應(yīng)該看更深一層，如何監(jiān)控到路面的凹陷凸起。類比到軟件系統(tǒng)，如果沒有監(jiān)控，我們對它們將一無所知?？杀氖?，有相當(dāng)比例的工程師對于系統(tǒng)上線后的感知，仍舊是通過是否有異常日志或者業(yè)務(wù)故障通知，才意識到自己系統(tǒng)的問題。實(shí)際上軟件產(chǎn)品的交付物其中一個(gè)很重要的特性就是“可監(jiān)控”，對于一個(gè)無法從內(nèi)到外看個(gè)透徹的黑匣子，是相當(dāng)恐怖的一件事情。那么到底應(yīng)該監(jiān)控什么呢？除了對自身業(yè)務(wù)或技術(shù)指標(biāo)的監(jiān)控，對于依賴方的監(jiān)控同樣重要。不能只盯著自己高架路面的平整度，還要監(jiān)控你依賴的排水系統(tǒng)處理能力，如果處理速度越來越慢，那就要考慮告警并介入了。細(xì)節(jié)為王，眼界放寬開篇我說過現(xiàn)在的架構(gòu)師不好混，實(shí)際上作為一個(gè)經(jīng)驗(yàn)老到的架構(gòu)師，他的能力就深藏在一些細(xì)節(jié)和眼界上，而這些都不是吃快餐養(yǎng)成的“準(zhǔn)”架構(gòu)師們短時(shí)間內(nèi)可以望其項(xiàng)背的。就像上面的問題“我只是高架路面設(shè)計(jì)師，如何想得到高架下的行車或行人？” 話說沒吃過豬肉也見過豬跑，我就不信你沒有在雨天有積水的馬路上走過，或者親身經(jīng)歷或者看到別人被積水坑害過?；氐杰浖軜?gòu)上，有些細(xì)節(jié)可能讓你空想你是想不出來