信息系統實踐手記7-對接卡口平臺細節

說明：信息系統實踐手記系列是系筆者在平時研發中先後遇到的大小的問題，也許朴實和細微，但往往卻是經常遇到的問題。筆者對其中比較典型的加以收集，描述，歸納和分享。摘要：此文描述了筆者接觸過的部分信息系統或平臺之間的對接構型和情況，掛一漏萬的總結分享之。正文系列隨筆目錄：信息系統實踐手記（http ...

說明：信息系統實踐手記系列是系筆者在平時研發中先後遇到的大小的問題，也許朴實和細微，但往往卻是經常遇到的問題。筆者對其中比較典型的加以收集，描述，歸納和分享。

摘要：此文描述了筆者接觸過的部分信息系統或平臺之間的對接構型和情況，掛一漏萬的總結分享之。

正文

系列隨筆目錄：信息系統實踐手記（http://www.cnblogs.com/taichu/p/5305603.html）

作者：太初

轉載說明：請指明原作者，連接，及出處。

正文

在圍繞地圖（GIS）展開的應用中，需要接入很多第三方的平臺，這在前面幾次的分享中或多或少提到過。

其中“卡口平臺”，作為和地圖應用緊密相關的專用平臺，往往由第三方供應商專門提供給公安，交警等專業用戶。

但作為專用平臺，卻沒有綜合應用平臺的能力，而這是綜合業務平臺的強項，在圍繞GIS地圖展開的業務開發中，自然也包含了對接“卡口平臺”。

下麵就具體的闡述一下相關內容，包括：卡口平臺的業務情況；對接形式；業務平臺自身模型設計等內容。

A.卡口平臺的業務情況：

A1卡口平臺簡介

卡口平臺是一個軟體平臺，下轄很多前端設備（有時這些設備被另外的“設備平臺”管理，而卡口平臺與設備平臺有一個對接）。

卡口平臺中的前端設備都是安裝在十字路口龍門架上的照相機，能瞬間產生高亮，無論夜晚還是早上都可拍照。除了攝像機，可能還有配合的速度檢測儀等設備。這些設備除了在路口，也可能安置在高架的收費站出入口，或其他交通道路的特定位置。一般一個或多個照相機“看守”一條車道，每條車道有車輛（單向）行駛方向。所以一般的二車道，四車道，甚至六車道的道路路口，你會看到龍門架上安裝了好多照相機，方向各不同相同，閃光燈此起彼伏的拍著照片。拍照的契機不一定是違章拍攝，也有正常情況下的按需拍照。

使用卡口平臺的用戶一般是公安或交警部門，他們需要這些卡口信息來以管理交通，維護社會治安。實際情況中，不同的前端設備（Camera，簡稱CAM）分屬於不同的部門，但由於部門間信息沒有充分（100%）的互通（復用），肯定存在資源浪費和重覆建設的情況。

A2卡口平臺業務

卡口平臺業務很多，下麵列舉2類比較典型的業務及相關的系列介面。

卡口過車歷史記錄查詢（業務平臺主動查詢卡口平臺）；
卡口訂閱和取消訂閱；
卡口過車實時記錄分發（卡口平臺主動推送給業務平臺）；
車牌黑名單訂閱和取消訂閱；
車牌黑名單告警分發（卡口平臺主動推送給業務平臺）；

關於卡口訂閱，取消訂閱和實時記錄分發：

業務平臺可以根據用戶的需求，通過卡口平臺開放的介面，向卡口平臺訂閱卡口過車記錄的推送服務。一旦訂閱成功，該卡口的過車實時信息（車輛信息包括，車牌，車身顏色，是否超速，照片，等等）就會主動推送到訂閱者（業務平臺）上，並呈現給用戶實時觀察。如果不需要了就按照介面來取消訂閱。這類似於設計模式里經典的訂閱分發模型。另外，分發的介面一般是業務平臺來提供，也可以是卡口平臺提供，這要看平臺間如何對接及協商（詳見：信息系統實踐手記4-平臺對接的一些思考）；

關於黑名單訂閱，取消訂閱和告警分發：

它很類似卡口訂閱，只不過它針對的是“某車牌A”在某個時間段的活動情況。如果在訂閱（監控/布控）的時間段內，某個卡口出現了此車牌的過車記錄，則將信息包裝為“一個告警”推送給業務平臺，以便後續觸發更多的上層複雜業務及規則。

B.對接卡口平臺的細節概述：

平臺對接的概述都在（信息系統實踐手記4-平臺對接的一些思考）中提到了，不再敘述，這裡僅僅是羅列部分細節，供相關專業人士參考；

對“卡口訂閱”相關業務：
- 卡口設備查詢（調用方向:業務平臺-->卡口平臺）：這很重要，是卡口一些列業務和介面的基礎，它一般返回一個長長的卡口設備列表，這很常見。
- 卡口訂閱介面（調用方向:業務平臺-->卡口平臺）：一般是webservice的形式較多（時下流行的restful也有）；可以用axis等工具從wsdl直接導出JAVA類，並添加業務代碼；（如果是特定的私有介面，比如私有格式的socket介面，雙方協定了二進位byte格式或高級一些的字元串string格式，甚至xml格式，這樣就需要另外撰寫解析代碼，稍微麻煩一些，但也可能獲得執行速度快和相對安全保密等好處）；
  - request一般包含欄位：“卡口ID，訂閱開始時間，訂閱結束時間，業務平臺標記，等等”
    - “業務平臺標記”欄位：是考慮到1個卡口平臺可能為N個業務平臺提供服務，則需要區分是哪個業務平臺的訂閱。當然，做法很多，這也取決於卡口平臺支持的好不好，也就是設計的合適與否。協商介面的時候，雙方專家應該提及並討論。如果卡口平臺告知已經考慮過並有自己的區分方法（比如通過調用介面的IP或其他辦法）那也不錯。否則一個簡單通常的辦法就是增加欄位“業務平臺標記”；
    - “起止時間”欄位：如果省略，則預設訂閱規則立刻生效；
  - response一般包含欄位：“訂閱號ID，errornbr，errormsg，等等”
    - “訂閱號ID”欄位：用於取消訂閱；
  - 業務能力調查：雖然介面明確，但卡口平臺的業務能力也需要瞭解，僅舉一例供參考：比如“佈防開始和結束時間”，規則的時間間隔是否必須小於“100年”？也許用不到這麼久，但需要明確，用戶界面GUI上面需要做“匹配”的限制！諸如此類的細節很多，雙方系統專家一定要討論清晰。最好有《介面設計CHECKLIST》這樣的組織過程資產來幫助以防缺漏考慮，這在我們後續的分享中，考慮在聊敏捷開發的再細說。
- 卡口取消訂閱介面（調用方向:業務平臺-->卡口平臺）：一般和訂閱類似。
  - request一般包含欄位：“訂閱號ID，等等”；
  - response一般包含欄位：“errornbr，errormsg，等等”；
- 卡口過車記錄上報（調用方向:卡口平臺-->業務平臺）：在訂閱的有效起止時間內，或者是實時起效的情況下，一般守護的卡口有過車情況，則系統將相關信息發給業務平臺。使用較多的是http協議的post方式，帶上自定義的欄位，一般用“|”來分隔，整個字元串作為value，放到key=value的格式中。
  - request一般包含欄位：“卡口ID，卡口名稱，過車時間，車牌信息，車輛種類，照片URL，等等”；
  - response一般包含欄位：“errornbr，errormsg，等等”；（按照http協議一般是200OK返回，如果有錯誤，應按協議返回錯誤碼和錯誤消息）
- 卡口過車記錄查詢（調用方向:卡口平臺-->業務平臺）：除了推送外，查詢歷史數據是另一個手段。實現方法很多，它和平臺對接及介面定義有關，比如：
對“卡口佈防”相關業務：
- 黑名單訂閱介面（調用方向:業務平臺-->卡口平臺）：形式類似卡口訂閱，略；
- 黑名單取消訂閱介面（調用方向:業務平臺-->卡口平臺）：略；
- 黑名單過車記錄上報（調用方向:卡口平臺-->業務平臺）：本質上都是過車信息的彙報，但觸發條件不同：卡口是守護“卡口”，而黑名單是守護“車牌”；
- 黑名單記錄查詢：也類似，略；

C.業務平臺的內部卡口模型：

這裡稍微提及一下業務平臺內部對卡口模型（model）的建立，安排和處理，涉及到需求分析，系統設計等內容，只提綱要供參考；

業務系統絕不可以沒有專門的內部“卡口模型”來對應卡口相關業務，否則代碼就太爛了；
- 你必須充分瞭解我平臺的“業務規則/場景情況/自身能力/邊界條件等”；
- 也必須充分瞭解對方平臺的“它的對接模型/它的場景/它的業務量/它的實現方法/它的一些邊界條件/等等”；

“卡口模型”概念上分幾塊：卡口設備列表一塊；卡口訂閱條目一塊；黑名單訂閱條目一塊；實際的過車記錄信息一塊；歷史過車信息一塊；許可權一塊（可選）；等等
“卡口模型”設計上對應分為：卡口設備CACHE；卡口訂閱和黑名單訂閱CACHE；過車記錄實時CACHE；歷史過車記錄的TABLE（持久化）；許可權數據結構；等等
“卡口模型”業務規則：圍繞上述的幾個概念，以及概念落地為數據結構，如CACHE,TABLE等，則可以寫出業務的偽代碼了；
模型用業務抽象來屏蔽實現差異：通過上述處理，屏蔽了不同卡口平臺的區別。而實踐中不同的卡口平臺往往有諸多差異：
- 業務功能不同：有的有黑名單，有的只有卡口，有的無實時推送，只能歷史查詢，等等；
- 業務限制不同：有的起止時間只能支持50年，有的更長；有的返回設備列表會自動分頁，有的有限制長度，等等；
- 業務能力不同：有的推送速度快，能支持10秒一條，甚至更快，甚至可以配置間隔；有的不能配置，有的效率很低很慢，等等；
總結：其實對接卡口平臺，可以抽象的看作對接一個“能力平臺”，那麼自然要將能力集合{能力1，能力2，...}剝離清晰；然後還要設計內部模型，來分多層次支持這些能力，同時要兼顧和考慮這些抽象能力的具體實現（第三方能力平臺的供應商）程度可能有差異（並不一致），進而考慮不同程度，不同場景的對接情況。

總結：

平臺對接實在是龐大巨集觀，卻又細緻入微的工作，沒有5到10年的經驗，下不來，主持不好工作，容易留下坑，日後自己還會中招。

而且分門別類的各種行業不同需求，平臺和對接方式日新月異，情況複雜多變，

往往再優秀的框架設計，模式設計，方面編程，場景推演，也難於解決一切問題，

有時甚至還是人力問題，那往往就特別遺憾（乾瞪眼，明明有人就能做的很漂亮，很優雅）。

這不可避免的就提到了研發流程和開發管理問題，也許下次有機會可以聊聊。

謝謝。