本系列說明
遙想當(dāng)年研發(fā)們仰視的架構(gòu)師，一出手一出口必是一套套(?)灭贷，讓人感覺他們?nèi)鐠叩厣裆闵畈豢蓽y温学，反駁都找不到趁手的詞匯，雖然當(dāng)時總覺得哪里不對∩跖保現(xiàn)而今不同了仗岖，架構(gòu)師理論方面的書籍或者視頻資料已然汗牛充棟，整個程序員群體都可以或多或少說上一些架構(gòu)理論览妖，可能理解不深刻轧拄，但是起碼有武器可以拿來跟架構(gòu)師懟。所以讽膏，現(xiàn)在架構(gòu)師真的沒那么容易混了檩电。本文(或者系列???...如果我不懶的話)的立意與常規(guī)的架構(gòu)講述套路不同，筆者想通過生活小細節(jié)或者小啟發(fā)來延伸出一些架構(gòu)思想，以期讓人有更加深刻的理解俐末。
最近干貨的出貨量大大降低料按，實在是精力不太夠(其實正在醞釀，敬請期待)卓箫。最近的幾篇都是生活中的靈光一現(xiàn)载矿，寫出來的東東竟然也有不小的啟發(fā)性和可讀性。今天要說道的烹卒，正是迎著朝陽駕車上班途中偶感所得闷盔。
# 變道提前打燈
上海中環(huán)和羅山高架路上的不少電子警示牌，不厭其煩地提示著"變道請?zhí)崆?秒打轉(zhuǎn)向燈"旅急，以前看到了也就看到了逢勾，因為筆者一直很守法，一般提前5秒就打了坠非，所以此警示從未驚起什么波瀾敏沉。某日清晨腦回路猛然搭住，就想如果變道不打燈被視作違章的話炎码，這個識別的程序邏輯該怎么設(shè)計呢盟迟？
砍材不誤磨刀功，不了解的領(lǐng)域準(zhǔn)備工作還是要充分調(diào)研的：
大眾熟知的闖紅燈識別潦闲，步驟是通過路口的三個感應(yīng)線圈觸發(fā)攝像頭的三次拍照攒菠，命中三次就視為違章，筆者開始也是想當(dāng)然的認(rèn)為攝像頭大部分都是靠拍照歉闰。
后來跟專業(yè)的同學(xué)求證辖众，新一代交通攝像頭的工作原理其實大約是這樣子的：攝像頭會持續(xù)拍攝交通情況的視頻，而在攝像頭所在位置附近會有個本地的存儲器和處理器和敬，視頻就存儲在那里凹炸，而后處理器會基于圖像識別或者人工智能blablabla等技術(shù)手段分析視頻中的違章情況，一旦識別出就會截取視頻生成圖片昼弟，最后這些高清截圖會上傳到遠程的市局服務(wù)器存儲啤它，而違章截圖也是從此而來（該信息只是單方面求得，如有偏差歡迎指正）舱痘。
繼續(xù)又去查了一下变骡，汽車轉(zhuǎn)向燈的頻閃間隔大約是1Hz，也就是一秒鐘閃爍一次芭逝，當(dāng)然也有0.5秒閃爍一次的塌碌，這個汽車行業(yè)和國家并沒有硬性規(guī)定。
拋開圖像識別的領(lǐng)域不談旬盯，剩下的實現(xiàn)難度在哪里呢台妆？且讓我直接寫三個案例來闡明：
Case 1
變道前的4.01秒開啟轉(zhuǎn)向燈翎猛，到3.01秒的時候轉(zhuǎn)向燈剛好熄滅，到2.01秒的時候轉(zhuǎn)向燈再次亮起接剩。
Case 2
變道前的4.99秒開啟轉(zhuǎn)向燈办成，到3.99秒的時候轉(zhuǎn)向燈剛好熄滅，到2.99秒的時候轉(zhuǎn)向燈再次亮起搂漠。
Case 3
需求只提到了提前3秒這個下限值，那上限值應(yīng)該是多少呢某弦？我可否提前5秒打轉(zhuǎn)向桐汤，甚至提前1分鐘打燈呢？很明顯間隔太久的轉(zhuǎn)向燈完全沒有意義靶壮，所以這個需求描述是有缺陷的怔毛。
剖析解讀
Case 1 & 2兩個案例類似，都在3秒前打燈了所以肯定不違章腾降，但是3秒這個時點上轉(zhuǎn)向燈都是熄滅狀態(tài)拣度。視頻分析所需的時間窗口當(dāng)然不能卡在3秒這個時點上，那么需要放大到多少合適呢螃壤？案例1的時間窗口必須不小于3.02秒抗果，案例2不小于4秒。注意奸晴，這里說的是時間窗口的下限冤馏。
而Case 3主要說的是時間窗口的上限，因為我不可能把時間窗口設(shè)置到無限大寄啼，按照交通實際情況逮光，1分鐘開外的轉(zhuǎn)向警示基本無意義了。經(jīng)查交通法規(guī)里確實沒有這方面的描述墩划，看來對于“提前”這件事情大家都知道很難量化的定義它涕刚。
再考慮一下需求設(shè)計問題：
（架構(gòu)師的基本素質(zhì)之一 -- 質(zhì)疑需求&明確需求）
1. 是選擇提前“時間”合適還是提前“距離”合適？選擇“時間”就會出現(xiàn)上面的時間窗口臨界問題乙帮。選擇“距離”杜漠，在不同的車速狀況下，“車速”越快打轉(zhuǎn)向燈的提前距離就應(yīng)該越大蚣旱，若是需要再嚴(yán)謹(jǐn)些的描述碑幅，這個“車速”應(yīng)該是前后車的“相對速度”，想想是不是如此塞绿？
對于汽車的轉(zhuǎn)向燈頻閃頻率國家似乎并沒有一個統(tǒng)一標(biāo)準(zhǔn)沟涨，那就意味著有長有短，進一步造成時間窗口的不可確定性异吻。
閃爍次數(shù)前文也簡單提過裹赴，基于頻閃頻率的最小閃爍次數(shù)也需要保證喜庞，否則連2S的時間窗口都看不到轉(zhuǎn)向燈亮起過，這視頻沒法分析了棋返。
另外延都，基于3個案例假設(shè)我們設(shè)定時間窗口為變道前的[-5s, -3s]，表示這個時間區(qū)間內(nèi)必須出現(xiàn)過轉(zhuǎn)向燈的亮起狀態(tài)睛竣。如果某個極端情況轉(zhuǎn)向燈在[-5s晰房，-3s]僅亮起一次，(-3s, 0) 再也沒有亮起過射沟，也就是轉(zhuǎn)向燈總共就閃了一次而已殊者，警示作用很不明顯，那么對于轉(zhuǎn)向燈的最小閃爍次數(shù)是否有要求呢验夯？經(jīng)筆者對自己車子的多次測試猖吴，開啟一下轉(zhuǎn)向即使馬上關(guān)閉，轉(zhuǎn)向燈也至少閃爍3次挥转。(對測試當(dāng)日跟我車屁股后面的司機師傅們深表同情海蔽，你們可能一直在罵前面那個傻叉為什么一直在打轉(zhuǎn)向？)
解決方案
透過問題看本質(zhì)無非就是時間窗口的臨界設(shè)定問題绑谣。
首先簡單放大時間窗口這么低級的方案肯定為架構(gòu)師所不齒党窜，因為再大的時間窗口都可能會存在臨界問題，而且時間窗口越大處理器分析的壓力就越大。
這里我要祭出本人一直以來作為架構(gòu)師灰常灰常重要但是很容易被忽視的一條原則：“能用規(guī)范化和標(biāo)準(zhǔn)化來解決的問題艳馒，就不要再花更多的成本用在工程手段上”缝左。此原則在創(chuàng)業(yè)公司尤其適用。
比如費盡九牛二虎之力研發(fā)了一個元數(shù)據(jù)管理系統(tǒng)，可以對業(yè)務(wù)系統(tǒng)里各類風(fēng)格迥異千奇百怪格式的日志進行解析，后果是這個元數(shù)據(jù)系統(tǒng)可能永遠跟不上業(yè)務(wù)系統(tǒng)更新的速度，而你只能跟在屁股后面不停的修正這個元數(shù)據(jù)系統(tǒng)择镇。如果寫個日志組件，規(guī)定讓所有的業(yè)務(wù)系統(tǒng)必須集成括改，直接打印出規(guī)范的統(tǒng)一標(biāo)準(zhǔn)的日志來腻豌，元數(shù)據(jù)系統(tǒng)的設(shè)計就可以相當(dāng)簡單了。
再比如運維耗盡全力為了實現(xiàn)基于容器化的持續(xù)部署嘱能，不得不為每個業(yè)務(wù)系統(tǒng)不統(tǒng)一的變量聲明方式編寫大量的yaml配置文件吝梅，為什么不能讓業(yè)務(wù)系統(tǒng)統(tǒng)一改造成規(guī)范的變量配置方式呢？相信這才是一勞永逸且最省力的方式吧惹骂。
回到轉(zhuǎn)向燈的問題上來苏携，我的解決方案首選壓根就不是技術(shù)方案，而是先把上面提到的所有不確定的問題先制定出標(biāo)準(zhǔn)來对粪。比如閃爍頻率右冻，最少閃爍次數(shù)等装蓬。
解決方案我會用軟件產(chǎn)品的幾個典型場景來類比，讓大家自己去聯(lián)想吧纱扭。
銀行日終跑批
銀行支付類金融系統(tǒng)都會有日切牍帚，做一些停業(yè)記賬、清算乳蛾、會計日期切換等操作暗赶，而這個窗口就算時間足夠的短，也不得不停止某些業(yè)務(wù)比如轉(zhuǎn)賬肃叶，這段時間也就是銀行日切黑暗期忆首。有的銀行在晚上 9-11點，有的在凌晨1-2點被环，不一而足。首先對于龐大的信息系統(tǒng)要做好時間的完全同步和一致是基本不可能的详幽，所以時間窗口可能產(chǎn)生交叉筛欢，由此出現(xiàn)任何的賬務(wù)數(shù)據(jù)異常，都是很可怕的一件事情唇聘。
TCP的滑動窗口實現(xiàn)
前面描述的所有細節(jié)都是基于變道這個時點來往前倒推版姑，如果用類似TCP的滑動窗口方式呢？比如我們就設(shè)定5秒的滑動窗口迟郎，交通攝像頭我們估算一秒100幀的水平剥险，那么5秒的窗口里就有500幀圖像需要處理。對滑動窗口內(nèi)的每幀圖像進行識別宪肖，標(biāo)示出當(dāng)前轉(zhuǎn)向燈亮暗的狀態(tài)表制，當(dāng)某一幀識別出變道動作，那只要把[-5s, -3s)區(qū)間內(nèi)的圖像識別的轉(zhuǎn)向燈狀態(tài)做個簡單的運算即可控乾，就算區(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也采用了滑動窗口實現(xiàn)方式帘撰。
Minimum Window Substring算法
最小覆蓋子串算法，也是從滑動窗口延伸的一個算法万皿，當(dāng)然也有數(shù)據(jù)結(jié)構(gòu)的小竅門骡和。因為要取最小相赁，所以也涉及到如何收縮窗口讓子串最小。請考慮如何讓收縮窗口讓視頻分析的區(qū)間更小呢慰于？
算法講解參見
分布式鎖的臨界問題
分布式鎖的實現(xiàn)方案很多钮科，市面上以Zookeeper, Redis實現(xiàn)的居多。不管是哪種婆赠，都要考慮這么一個問題：持鎖的進程在釋放鎖之前崩潰了绵脯，導(dǎo)致鎖一直在無法釋放的狀態(tài)。為了避免這種情況休里，一般會設(shè)置一個鎖失效時間蛆挫，這個時長設(shè)定一般要比99%的持鎖時間久，那么就引入另一個問題妙黍，假如持鎖的進程A就是不小心抖動了一下導(dǎo)致持鎖時長超過了失效時長悴侵，而失效機制導(dǎo)致鎖的釋放就意味著進程B也可以持有這個鎖。A B兩個進程同時持有鎖拭嫁，我就問你怕不怕可免！我就問你慌不慌！不然的話做粤，或者你的系統(tǒng)允許這種極端情況的發(fā)生浇借，有一定的容錯能力，大不了最后再補救怕品「竟福或者你需要一個雙向的****鎖檢測機制，客戶端在邏輯鏈路上的關(guān)鍵節(jié)點不斷檢測鎖的剩余時間肉康，然后基于自己估算的仍需時間延長鎖的失效時間闯估，反過來，服務(wù)端也可以檢測客戶端的持鎖時長吼和，在超時那一刻睬愤，通知客戶端必須做出鎖失效/快速失敗的回滾處理等等。這些細節(jié)都不是那么容易操作的纹安，所以我也就拋出個思路尤辱，拿走不謝。
# 路面積水問題
當(dāng)日是個雨后的早晨厢岂，四處都有積水光督。
這是發(fā)生在“變道轉(zhuǎn)向”之后再次讓我陷入思考的第二件事。
示意圖如上塔粒，我要說的積水問題必須是在高架上下閘道口的坡面上的结借。為什么我不說更常見的平坦路面的積水區(qū)呢？因為作為一個有素質(zhì)的老司機卒茬，經(jīng)過平坦路面的積水區(qū)時路邊若是有行人船老，必然速度放緩慢慢前行咖熟，以防積水潑濺到路人。而在高架坡面上因為視野中看不到高架底下的行車或者行人柳畔，有些時候下意識的就沖過去馍管，高架下方“爭渡爭渡驚起一灘鷗鷺”。
這里還是友情提醒一下薪韩，駕車但凡涉水不管什么情況都要放緩确沸，這對別人對自己都沒壞處。
那么這個故事到底對架構(gòu)有借鑒意義呢俘陷？請大家思考：
路面為什么會有積水罗捎？
積水情況是否有監(jiān)控？
我只是高架路面設(shè)計師拉盾，如何想得到高架下的行車或行人桨菜？
路面為什么會有積水
原因無非兩個，路面不平整或者沒有傾斜度捉偏，排水系統(tǒng)不給力倒得。對于路面施工的質(zhì)量問題，沒什么好說的告私，施工和驗收環(huán)節(jié)都沒做到位。而依賴的排水系統(tǒng)不給力承桥，對于高架施工隊來說這個鍋好像是可以甩給排水系統(tǒng)團隊的驻粟。
無需多言，這里我要類比的軟件架構(gòu)類別是“服務(wù)治理”凶异。很明顯高架路面系統(tǒng)依賴了排水系統(tǒng)蜀撑，那我們就來說道說道限流、路由剩彬、熔斷酷麦、降級這四塊。
限流比較容易理解喉恋，我的排水管道就這么粗沃饶，你拿盆往里灌肯定噴出來，所以超出排水管道處理能力的水就不收了轻黑。那多的這些水怎么處理呢糊肤？不知道大家有沒有聽過“海綿城市”，通過一些特殊材料或特殊管道設(shè)計氓鄙，將這些水先蓄在某些地方馆揉，以后隨時可以拿來澆澆公園的花草啥的也算有效利用，架構(gòu)里這就是常見的“削峰”抖拦，一般通過MQ隊列來實現(xiàn)升酣。當(dāng)然還有更簡單粗暴的就是水從哪里來回哪里去舷暮，我路邊整幾排燒紅的鐵棒，水一沾上就變?yōu)檎羝舭l(fā)掉了(好像發(fā)現(xiàn)了什么了不得的發(fā)明), 架構(gòu)里對應(yīng)的就是“快速失敗”噩茄，既然系統(tǒng)已經(jīng)處理不了你了下面，就直接給你個失敗應(yīng)答完事。
路由就是把水引流到不同的排水口(多個排水口可以理解成排水系統(tǒng)的分布式多節(jié)點)巢墅，污水和雨水是不同的排水通道诸狭，這個可以叫灰度或A/BTest；大雨會啟動更多的排水口進行排水君纫，或者易積水路段使用大的排水口驯遇，這個叫“彈性擴容”或者“權(quán)重路由”。
熔斷就像家里的保險絲蓄髓，當(dāng)排水系統(tǒng)達到自己能力的上限叉庐，水再也進去不去的時候（響應(yīng)超時或持續(xù)報錯），排水口可以考慮自動關(guān)閉会喝。等排水系統(tǒng)緩過勁來之后陡叠，可以打開排水口繼續(xù)接受排水，這里需要不時的去探測排水系統(tǒng)是否恢復(fù)肢执，決定何時再開啟排水口枉阵。此處的熔斷就是為了保護排水系統(tǒng)本身，不要因為大量的水灌入導(dǎo)致排水管道的破裂脫節(jié)之類的惡劣情況發(fā)生预茄。
降級之前要先分級兴溜，在排水壓力很大的情況下，可以讓關(guān)鍵核心路段的積水先排掉別讓交通完全癱瘓耻陕，其他邊緣路段就自我犧牲一下先關(guān)閉主動排水口拙徽，也就是說在排水能力有限的情況下，把優(yōu)先權(quán)讓給關(guān)鍵核心诗宣，這種是資源搶占式的降級膘怕；假設(shè)平日的排水是在管道流動的過程中加入了過濾雜質(zhì)的功能，以防大形體的垃圾進入排水系統(tǒng)堵塞住出水口召庞，那在暴雨天氣排水壓力很大的情況下岛心，是否可以考慮關(guān)停過濾功能，或者把過濾的標(biāo)準(zhǔn)放寬篮灼，這樣排水的過程必然順暢很多鹉梨，這種是裁剪枝節(jié)、降低失敗率穿稳、提高關(guān)鍵流程吞吐量的降級存皂。
積水情況是否有監(jiān)控
這個問題其實有一定的迷惑性，積水這種表象級別的監(jiān)控絕對不是我們的目的，而是應(yīng)該看更深一層旦袋，如何監(jiān)控到路面的凹陷凸起骤菠。類比到軟件系統(tǒng)，如果沒有監(jiān)控疤孕，我們對它們將一無所知商乎。可悲的是祭阀，有相當(dāng)比例的工程師對于系統(tǒng)上線后的感知鹉戚，仍舊是通過是否有異常日志或者業(yè)務(wù)故障通知，才意識到自己系統(tǒng)的問題专控。實際上軟件產(chǎn)品的交付物其中一個很重要的特性就是“可監(jiān)控”抹凳，對于一個無法從內(nèi)到外看個透徹的黑匣子，是相當(dāng)恐怖的一件事情伦腐。
那么到底應(yīng)該監(jiān)控什么呢赢底？除了對自身業(yè)務(wù)或技術(shù)指標(biāo)的監(jiān)控，對于依賴方的監(jiān)控同樣重要柏蘑。不能只盯著自己高架路面的平整度幸冻，還要監(jiān)控你依賴的排水系統(tǒng)處理能力，如果處理速度越來越慢咳焚，那就要考慮告警并介入了洽损。
細節(jié)為王，眼界放寬
開篇我說過現(xiàn)在的架構(gòu)師不好混革半，實際上作為一個經(jīng)驗老到的架構(gòu)師碑定，他的能力就深藏在一些細節(jié)和眼界上，而這些都不是吃快餐養(yǎng)成的“準(zhǔn)”架構(gòu)師們短時間內(nèi)可以望其項背的督惰。就像上面的問題“我只是高架路面設(shè)計師不傅，如何想得到高架下的行車或行人旅掂？” 話說沒吃過豬肉也見過豬跑赏胚，我就不信你沒有在雨天有積水的馬路上走過，或者親身經(jīng)歷或者看到別人被積水坑害過商虐。
回到軟件架構(gòu)上觉阅，有些細節(jié)可能讓你空想你是想不出來的，但是你從初級工程師成長起來肯定踩到過某些坑秘车，而這些坑都應(yīng)該在你的架構(gòu)設(shè)計里避免典勇。一個標(biāo)準(zhǔn)的系統(tǒng)應(yīng)用特性，很多人可以張嘴就來：可擴展性叮趴、高可靠割笙、高可用、低延遲、BLABLABLA伤溉，又有多少人真正的對“可運維”“可監(jiān)控”“可排障”“可持續(xù)交付”等在概要設(shè)計初期就有考慮呢?
# 課間不休息了般码，我再啰嗦兩句
到這里，發(fā)現(xiàn)自己就半小時的車程感悟了這么多乱顾，也真的挺難為自己的板祝。
總結(jié)性陳述：其實主要就扯了臨界時間窗口、服務(wù)治理兩個架構(gòu)設(shè)計經(jīng)常遇到的點走净，結(jié)合**提前打轉(zhuǎn)向燈 **和 防止****路面積水兩個場景做了發(fā)散性的對比券时，其他一些只言片語的架構(gòu)思想僅為個人心得，如有異議隨時歡迎來懟伏伯。
就此擱筆橘洞，有緣再見。
