2022-09-26

伍總監(jiān)：“目前為止你寫過最復雜的架構是什么？我們車企需要自己研發(fā)中間件，對架構方面要求頗高。”

他重點是“我寫過”什么架構，而不是“我用過”什么架構。

我……省略一萬字說了個不痛不癢的應用層架構。很多年不怎么寫應用程序了，最多寫些測試用例，近年一直干著預研的工作，很少涉及具體應用。

2個我寫的架構

其實2015-2018年干應用層的時候，倒是寫過幾個架構，其中有2個架構不是孤芳自賞，它們還得到同事的認可，在其他項目上也得到應用。

MiniShellEx：誕生于2014年中旬，應用程序命令行接口，提供命令補全、提示功能，最有價值的是可以依靠它去編寫單元測試， 節(jié)省單元測試代碼量。其實還有一個精簡版MiniShell Tiny，用于stm32單片機后臺調試，MiniShell Tiny它不依賴Linux庫libreadline。

EpollServerX：誕生于2015年初，看名字都知到他是基于epoll的以太網(wǎng)服務器庫，它與MiniShellEx結合起來，可以搭建遠程單元測試框架， 既可以做服務器，也可以做客戶端。若當時我知道libevent的存在，或許我不會重復造輪子。

它們的鏈接如下（你可能需要梯子）：

• https://github.com/MenglongWu/EpollServerX

• https://gitee.com/MenglongWu/MiniShellEx

最復雜架構

我所認為的架構，應該是盡可能使用現(xiàn)存架構，除非確認已存在的架構存在瓶頸，才少量嘗試創(chuàng)新、突破。

2015年干過一個最復雜的架構，我毫掩飾地評價它是最惡心架構，說他惡心的根本原因是我本可以編寫少量、甚至不編寫代碼，也就是上文說所的盡可能使用現(xiàn)存架構， 不僅同時用上EpollServerX和MiniShellEx，還寫了一個本不應該寫的軟路由，最后該工程框架成了公司祖?zhèn)鞔a，后面2個同事拿著它做二次開發(fā)。

我們的工程是這樣的，一個19寸機箱里有13快業(yè)務板和1塊軟路由板。像這樣的機箱有百來個，他們都與服務器發(fā)生數(shù)據(jù)交互。

行業(yè)里的做法應該是軟路由上搭建NAPT，服務器向軟路由發(fā)起連接，根據(jù)端口區(qū)分業(yè)務板。例如：

• 軟路由IP：192.168.1.5

• 業(yè)務板服務器和端口：192.168.0.1:1000

• 業(yè)務板服務器和端口：192.168.0.2:1000

• 當服務器要像業(yè)務板1通信，則連接192.168.1.5:10001；

• 當服務器要像業(yè)務板2通信，則連接192.168.1.5:10002；

• 軟路由做的工作叫做端口映射NAPT；

而我們產(chǎn)品經(jīng)理偏不按常理出牌，要要在軟路由上開放端口2000，軟路由連接機框內各業(yè)務板，服務器只連接軟路由，開發(fā)服務器的工程師說擔心服務器處理不過來，畢竟幾百個機框累計起來，服務器得維護數(shù)前個連接呢，只連接軟路僅幾百個連接。

我納悶：“數(shù)千個連接不多呀，你不是用Windows下的完成端口模式嗎，應該沒什么壓力，而且我們的業(yè)務板也不是事實都有數(shù)據(jù)流量?！?/span>

Windows的完成端口設計目的與Linux的epoll一樣，都是應對多連接場景。

老工程師：“以前都是如此干的，要動架構不太好改?！?/span>

好吧，擰不過老干部。于是我開始實現(xiàn)又長又臭的業(yè)務。

如此設計

第1秀：私有命令碼

EpollServerX監(jiān)聽兩個端口，端口2000是項目業(yè)務所需要的，協(xié)議按照項目的來。業(yè)務命令碼有近100條，我特意向產(chǎn)品經(jīng)理申請一條私有命令碼。留下一條后門，專門用于傳送字符串，字符串的內容提供給MiniShellEx解析，使我有更多的方式去調試。

開發(fā)階段，軟路由就在我的桌面，我完全可以ssh、telnet遠程登錄操作板卡。當真正上業(yè)務后，運營商會封死任何與業(yè)務無關的端口，真要出問題我就抓瞎了。擁有私有命令碼后，依靠現(xiàn)有端口完全可以秀各種操作，包括shell反彈、連接重定向。

第2秀：自連接

EpollServerX目的是充當服務器，其二也可以充當客戶端。但你有想過服務器自己連接自己嗎？

開放2000端口，然后自己連接自己，為什么有奇葩需求？——為了編寫測試用例，實現(xiàn)除了軟路由之外的業(yè)務。

某飛機操作系統(tǒng)，或者說飛機上的應用程序，下載后文件有百萬行，實際使用的代碼只有幾萬航而已，其他的都是他的測試用例。通常我們會把測試用例與業(yè)務代碼分離出來，不過飛機項目可是把測試用例與業(yè)務一同編譯、打包、發(fā)布。

當初設計時我沒打算向飛機項目看齊，僅僅是當時年輕，提出反對意見沒人聽，倘若老干部的代碼有BUG我要是沒有足夠證據(jù)去證明，老干部是不承認的。

于是未雨綢繆，把他們的業(yè)務都實現(xiàn)了（傳遞的是假數(shù)據(jù)），集成測試能夠自己先測試。

第3秀：數(shù)據(jù)流

正式業(yè)務數(shù)據(jù)流很簡單，業(yè)務數(shù)據(jù)從以太網(wǎng)來，指定業(yè)務端口，數(shù)據(jù)流直上到應用層，最后從原路返回。

測試階段我可以用命令行，在本地ttyX終端執(zhí)行任何測試用例子：

如果測試用例屬于本地查詢業(yè)務，則執(zhí)1、2流程；如果測試用例屬于主動向其他板卡發(fā)送指令，則執(zhí)3、4流程；

當業(yè)務開通后，運營商只開通業(yè)務端口2000，真?zhèn)€數(shù)據(jù)流和第二張圖幾乎一抹一樣，差別在于一個命令來源于ttyX、另一個來源于私有命令碼。

當同事還沒開發(fā)完成業(yè)務板、服務器，我則使用ttyX對自己的軟路由做自連接測試，ttyX啟動測試用例，模擬其他網(wǎng)絡節(jié)點向軟路由發(fā)送數(shù)據(jù)。

好了，框圖還是比較好畫的，至于具體實現(xiàn)要牽扯到數(shù)據(jù)結構，太多，以后有空再寫，其實本項目可以用無鎖編程，調試起來會麻煩一點，當年還是用上了少量的鎖。

開發(fā)

記得我和同事A討論：“測試50號命令，代碼在8千xx行?！?/span>

旁邊的另一個同事B聽著：“你不是做軟路由嗎，幾行代碼不就寫完了，怎么搞出8千行。給你年輕人減輕壓力，看來也做不出什么東西?！?/span>

同事A是知道我實現(xiàn)3份代碼的，沒多爭辯：“他實現(xiàn)的內容會比你實現(xiàn)的東西穩(wěn)定得多?！崩^續(xù)和我調試。

項目第一階段我是開發(fā)最久的，其他兩人大概2.5月完成，我花了3個月。核心業(yè)務其實不超過6千行，為了6千行的穩(wěn)定寫了8千行去實現(xiàn)其他業(yè)務的代碼，以及幾千行測試用例。測試用例子與實際業(yè)務工作量差不多是4：1。

在測試階段，我借助著MiniShellEx只花費1天時間測試萬80多條命令。反觀幾天后甲方來與我們聯(lián)調，3天時間測試不足20條命令。

收貨

項目第一階段交付，交付后甲方提出下一階段的要求，列出若干新增業(yè)務，業(yè)務板、軟路由板、服務器3塊業(yè)務開發(fā)的同事都分配到了任務。

粗略計算大概要1個多月才能提交第二階段，我呢在一周后叫到：“完工，什么時候可以和你們集成測試？”

之前嘲諷我為什么寫8千多行代碼的同事：“灌鴨子啊！這么快！”

我挺得意：“不僅僅功能實現(xiàn)，測試用例也跑了一遍，現(xiàn)在就等你們完工給我真實數(shù)據(jù)?！蔽⑿δ?。

工作量守恒定律。前面看似吃點虧把其它不歸我的業(yè)務也實現(xiàn)了，正是我在第一階段實現(xiàn)了3塊業(yè)務，它也創(chuàng)造一個測試環(huán)境，我可以不依賴其他同事任務進度，獨自完成軟路由的功能測試。其二，我的架構能同時兼容3種業(yè)務的實現(xiàn)，也證明架構有一定的彈性。