最近的幾個月里，我開始接手視頻平臺所需的“中間件”項目——級聯平臺，現在對這段時間的經歷做一個總結
1.級聯平臺是平臺與平臺之間溝通的橋梁，它按照國家交通部擬定的協議（jt-1078）去完成了平臺間定位數據的交換、實時視頻的請求、歷史視頻的回放控制等等業務。級聯平臺實際上的工作就是對指令的接收、下發，類似于一種數據接入處理，需要對十六進制報文、網絡傳輸有一定的知識儲備，而難點在于對協議的理解以及實施過程中，對級聯平臺所需的項目在不影響其原有功能的情況下進行升級改造，使其能夠配合級聯平臺進行工作。
2.剛接手的一個難點就是去理解原有的基于jt809的主從通信鏈路，jt1078協議還會基于一些其他協議的基礎上實現，其中最重要的就是依賴jt809，業務的通信基于jt809設計好的主從鏈路，我們的主從鏈路實現是基于mina框架，采用tcp通信，用java代碼實現的鏈路，在這其中學習到了主從鏈路的設計流程、以及這套基于spring的jt809項目如何配置部署
3.第二個難點就是考慮如何使其他的項目配合級聯平臺工作，這里需要考慮你作為哪一方平臺時（上級或下級）如何讓指定的業務走通，在我們的視頻平臺里，就是讓web端、與車臺通信端、流媒體端的項目協同配合，所以這首先就是得去熟悉原本項目的業務流程，再來就是梳理好整個業務流程，能夠完整的走下來且合理，也為后面寫技術文檔做準備。
4.第三個難點就是可能出現kafka和redis濫用的問題，因為涉及到太多的項目傳遞，往往都是通過消息中間件來完成，不論是redis還是kafka，都要考慮它可能存在的問題，比如我們遇到的一個大坑，就是因為使用redis線程池的時候，maxWaitMillis這個參數為進行設置，導致短時間線程連接數到達上限后再次請求里連接造成等待，無法釋放，默認值在此情況為永不超時，導致難以排查，最終是通過斷點查看線程使用情況發現的問題。具體redis需要配置的參數:redis參數配置
同樣，kafka作為消息傳遞的時候，也會有常見的重復消費、順序消費等問題，需要考慮好，而在我的項目中出現過消費消息與級聯通信鏈路初始化之間的沖突，需要設置好判斷，讓消息消費類kafkaHandler晚于創建鏈路對象jt809Client之后執行。
5.在項目測試上線后或多或少還有些問題，主要還是集中與有些設備或平臺之間一些細微差別和協議之間的沖突，比如jt809和jt1078協議對于查看資源列表的業務中，file-size屬性給予的長度限制不同，導致我們需要修改級聯平臺的file-size的類型為無符號整型去盡力匹配車臺可能過來的視頻大小
6.最后，在上線出現問題時，總結出了如下的排查方向
一、業務請求失敗時，先查看日志，是否有接收到請求（web端請求、上級平臺指令等）
二、web端請求沒有則考慮kafka是否掛掉，上級平臺則考慮鏈路是否斷開
三、有請求，則斷點查看web端請求是否正確，查看上級平臺下發的報文是否正確（對照協議查看報文是非常有效的方式）
四、如若都沒問題，可往線程使用進行查看，看是阻塞在哪了
五、若上級有下發但下級接收不到，考慮是否是網絡丟包或是上級發送錯鏈路