KumoRail2019雜記

KumoRail項目自啓動以來，至今已逾二載。微信公衆號開放也有一年了。最初的版本雖然是能用的，但是裏面有太多的桎梏在限制著運行的效率，也讓整個程序的結構變得複雜，難以理解和優化。於是我從18年8月開始，另起重構了一個KumoRail的版本，命名為KumoRailT。我使用Tornado框架代替舊有的Flask來提高API的承載量和效率，使用SQL型數據庫，使數據的關係聯係更加緊密，構造新的回復語句生成模塊，以及重寫很多新的函數，重新整理這個架構，盡可能的做好一些。

其實最大的想法，一個還是在要優化用戶的查詢語句上面。事實上，大家用的最多的還是交路查詢工具，于是我就想著把這個function做到最簡。後面就做了只需要發送車次就可以返回交路以及到點信息的function。雖然這個功能確實是讓判斷查詢類型的函數變得越發複雜，并且還要和正晚點查詢裏面的車次+車站格式區分開，但是最後來看，其實現的效果還是比較OK的。具體來説，是在parse.py中的judge_type()函數中，單獨把判定前首是不是一個車次，或者是車次+車站的邏輯拉出來，寫成了一個judge_train_front()函數，以此預判。在後面，才是判斷以字母打頭的格式化查詢。這樣，確實是方便多了。

然後，還有的就是，在交路查詢裏面，稍微優化了一下格式，若是同一趟車，有兩個車次的，我把它該換為以斜杠來表示，以防產生歧義。

在正晚點歷史查詢方面，我加入了一個查詢最新的一趟車的數據的功能。本來的想法是查詢這趟車的最新的數條有效數據的，但是最終發現實現起來相當麻煩，還要跨數日的數據查詢，遂放棄了（待考）。事實上的效果并不樂觀。

然後還有，配屬查詢的網站後面也是重新開放了，我也重新用Request和bs4庫寫了一個鈎子去查詢上面的信息。之前用正則表達式來做網頁數據清洗確乎是不太合適了，我現在改成了bs4來加以分析。查詢方法是依舊的。

我還加入了獲取車次表和到站表（即是車次到每個站的到站信息）的鈎子。車次表由train_list.js來導入，這裏包含了30天的所有車次安排。對於到站表（arr），則是一個個從web中catch下來。其實這個方法已經不賴。不過比較痛苦的是在調整運行圖之後，如何合理的更新和安全的儲存新舊數據。目前沒有看到更好的方法。

seq則爲導入交路數據（不包括車型，只有狹義上的交路）的hook。其實是否需要直接合并到DB庫的工具區，尚待討論。

act為獲取晚點信息的hook。這個會單獨分析。

然後對於服務器的主體，即server.py，其實也無甚太多可談，結構其實大體類。就是我沒有把握是否使用到了Tornado的最大性能。@property沒有被使用，我亦是心虛虛的。

對於DB方面，其實我很久也沒有一個很好的方案，後來最終做成了5層的方案，也還是覺得不甚完美。層1為車站表，staInfo。層2為depot配屬和seq交路，每個車次最終會屬於某個交路。層3為train，車次和trainCode。trainCode，12位的區分碼，最終被發現是每天一樣的，但是又以此標識車次在該日的運行情況，因此保留了下來。arrival為到站表，及時刻。subArr和actArr服務于晚點數據。

DB的各個模塊都會調用dbmaria2.py，這是一個底層的、直接去和數據庫交互的模塊。其中主體是SQL語句生成器，由上層填入的各類條件表、期待的結果表、排序方式等，去生成條查詢語句，再經由PyMySQL庫丟去執行。此話另表。

最後，還要感謝小姐姐幫我畫的頭像，很好看wwww

胡言亂語而已。以上。