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

---

layout: post
title: 2016-05-20-信息系統實踐手記7-對接卡口平臺細節
key: 20160520
tags: 對接 卡口 黑名單 佈防 撤防 訂閱 取消 設備 列表 模型
modify_date: 2016-05-20
---

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

說明：

• 本文發佈於: gitee,github,博客園
• 轉載和引用請指明原做者和鏈接及出處.

正文：

• 信息系統實踐手記系列是系筆者在平時研發中前後遇到的大小的問題，其中比較典型的內容加以收集和分享。
• 信息系統實踐手記目錄：博客園(或查看源碼的README.MD文件)

摘要：

• 此文描述了JS和FLEX（Flash）交互的一些經驗總結。

正文

在圍繞地圖（GIS）展開的應用中，須要接入不少第三方的平臺，這在前面幾回的分享中或多或少提到過。
其中「卡口平臺」，做爲和地圖應用緊密相關的專用平臺，每每由第三方供應商專門提供給公安，交警等專業用戶。
做爲集成大平臺（或稱綜合應用平臺），須要接入卡口平臺來展開地圖和卡口的關聯業務。
下面具體闡述相關內容，包括：卡口平臺業務狀況；對接形式；業務平臺自身模型設計等內容。

1.卡口平臺的業務狀況：

• 卡口平臺簡介
  • 卡口平臺是一個軟件平臺，下轄不少前端設備（有時這些設備被另外的「設備平臺」管理，而卡口平臺與設備平臺有一個對接）。
  • 卡口平臺中的前端設備都是安裝在十字路口龍門架上的照相機，能瞬間產生高亮，不管夜晚仍是早上均可拍照。除了攝像機，可能還有配合的速度檢測儀等設備。這些設備除了在路口，也可能安置在高架的收費站出入口，或其餘交通道路的特定位置。通常一個或多個照相機「看守」一條車道，每條車道有車輛（單向）行駛方向。因此通常的二車道，四車道，甚至六車道的道路路口，你會看到龍門架上安裝了好多照相機，方向各不一樣相同，閃光燈此起彼伏的拍着照片。拍照的契機不必定是違章拍攝，也有正常狀況下的按需拍照。
  • 使用卡口平臺的用戶通常是公安或交警部門，他們須要這些卡口信息來以管理交通，維護社會治安。實際狀況中，不一樣的前端設備（Camera，簡稱CAM）分屬於不一樣的部門，但因爲部門間信息沒有充分的互通（複用），確定存在資源浪費和重複建設的狀況。
• 卡口平臺業務
  • 卡口平臺業務不少，下面列舉比較典型的業務及相關的系列接口。
    • 卡口過車歷史記錄查詢（業務平臺主動查詢卡口平臺）；
    • 卡口訂閱和取消訂閱；
    • 卡口過車實時記錄分發（卡口平臺主動推送給業務平臺）；
    • 車牌黑名單訂閱和取消訂閱；
    • 車牌黑名單告警分發（卡口平臺主動推送給業務平臺）；
  • 關於卡口訂閱，取消訂閱和實時記錄分發：
    • 業務平臺能夠根據用戶的需求，經過卡口平臺開放的接口，向卡口平臺訂閱卡口過車記錄的推送服務。一旦訂閱成功，該卡口的過車實時信息（車輛信息包括，車牌，車身 顏色，是否超速，照片，等等）就會主動推送到訂閱者（業務平臺）上，並呈現給用戶實時觀察。若是不須要了就按照接口來取消訂閱。這相似於設計模式裏經典的訂閱分發模型。另外，分發的接口通常是業務平臺來提供，也能夠是卡口平臺提供，這要看平臺間如何對接及協商（詳見：信息系統實踐手記4-平臺對接的一些思考）；
  • 關於黑名單訂閱，取消訂閱和告警分發：
    • 它很相似卡口訂閱，只不過它針對的是「某車牌A」在某個時間段的活動狀況。若是在訂閱（監控/布控）的時間段內，某個卡口出現了此車牌的過車記錄，則將信息包裝爲「一個告警」推送給業務平臺，以便後續觸發更多的上層複雜業務及規則。

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

• 對「卡口訂閱」相關業務：
  • 卡口設備查詢（調用方向:業務平臺-->卡口平臺）：這很重要，是卡口一些列業務和接口的基礎，它通常返回一個長長的卡口設備列表，這很常見。
  • 卡口訂閱接口（調用方向:業務平臺-->卡口平臺）：通常是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返回，若是有錯誤，應按協議返回錯誤碼和錯誤消息）
  • 卡口過車記錄查詢（調用方向:卡口平臺-->業務平臺）：除了推送外，查詢歷史數據是另外一個手段。實現方法不少，它和平臺對接及接口定義有關，好比：
    • 業務平臺直接查詢卡口DB（此方法不太好，業務平臺會背上性能，安全性等額外的黑鍋）；
    • 業務平臺直接調用卡口平臺的歷史查詢記錄接口（此法最正規，較好！）
    • 業務平臺傳輸SQL查詢語句給卡口平臺（此方法不太好，但有時由於第三方平臺的限制，只能如此）
    • 具體接口還有不少，視具體狀況協商而定；
• 對「卡口布防」相關業務：
  • 黑名單訂閱接口（調用方向:業務平臺-->卡口平臺）：形式相似卡口訂閱，略；
  • 黑名單取消訂閱接口（調用方向:業務平臺-->卡口平臺）：略；
  • 黑名單過車記錄上報（調用方向:卡口平臺-->業務平臺）：本質上都是過車信息的彙報，但觸發條件不一樣：卡口是守護「卡口」，而黑名單是守護「車牌」；
  • 黑名單記錄查詢：也相似，略；

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

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

• 業務系統毫不能夠沒有專門的內部「卡口模型」來對應卡口相關業務，不然代碼就太爛了；
  • 你必須充分了解本身平臺的「業務規則/場景狀況/自身能力/邊界條件等」；
  • 也必須充分了解對方平臺的「它的對接模型/它的場景/它的業務量/它的實現方法/它的一些邊界條件/等等」；
• 「卡口模型」概念上分幾塊：
  • 卡口設備列表一塊；
  • 卡口訂閱條目一塊；
  • 黑名單訂閱條目一塊；
  • 實際的過車記錄信息一塊；
  • 歷史過車信息一塊；
  • 權限一塊（可選）；等等
• 「卡口模型」設計上對應分爲：
  • 卡口設備CACHE；
  • 卡口訂閱和黑名單訂閱CACHE；
  • 過車記錄實時CACHE；
  • 歷史過車記錄的TABLE（持久化）；
  • 權限數據結構；等等
• 「卡口模型」業務規則：圍繞上述的幾個概念，以及概念落地爲數據結構，如CACHE,TABLE等，則能夠寫出業務的僞代碼了；
• 模型用業務抽象來屏蔽實現差別：經過上述處理，屏蔽了不一樣卡口平臺的區別。而實踐中不一樣的卡口平臺每每有諸多差別：
  • 業務功能不一樣：有的有黑名單，有的只有卡口，有的無實時推送，只能歷史查詢，等等；
  • 業務限制不一樣：有的起止時間只能支持50年，有的更長；有的返回設備列表會自動分頁，有的有限制長度，等等；
  • 業務能力不一樣：有的推送速度快，能支持10秒一條，甚至更快，甚至能夠配置間隔；有的不能配置，有的效率很低很慢，等等；
• 總結：其實對接卡口平臺，能夠抽象的看做對接一個「能力平臺」，那麼天然要將能力集合{能力1，能力2，...}剝離清晰；而後還要設計內部模型，來分多層次支持這些能力，同時要兼顧和考慮這些抽象能力的具體實現（第三方能力平臺的供應商）程度可能有差別（並不一致），進而考慮不一樣程度，不一樣場景的對接狀況。

4. 總結:

平臺對接實在是龐大宏觀，卻又細緻入微的工做，沒有5到10年的經驗，下不來，主持很差工做，容易留下坑，往後本身還會中招。
並且分門別類的各類行業不一樣需求，平臺和對接方式突飛猛進，狀況複雜多變，
每每再優秀的框架設計，模式設計，方面編程，場景推演，也難於解決一切問題，
有時甚至仍是人力問題，那每每就特別遺憾（乾瞪眼，明明有人就能作的很漂亮，很優雅）。
這不可避免的就提到了研發流程和開發管理問題，也許下次有機會能夠聊聊。

END