信息系统实践手记7-对接卡口平台细节

Posted 2020-07-08

说明：信息系统实践手记系列是系笔者在平时研发中先后遇到的大小的问题，也许朴实和细微，但往往却是经常遇到的问题。笔者对其中比较典型的加以收集，描述，归纳和分享。

摘要：此文描述了笔者接触过的部分信息系统或平台之间的对接构型和情况，挂一漏万的总结分享之。

正文

系列随笔目录：信息系统实践手记 （http://www.cnblogs.com/taichu/p/5305603.html）

作者：太初

转载说明：请指明原作者，连接，及出处。

 

正文

 

在围绕地图（GIS）展开的应用中，需要接入很多第三方的平台，这在前面几次的分享中或多或少的提到过。

其中“卡口平台”，作为和地图应用紧密相关的专有平台，往往由第三方供应商专门提供给公安，交警或专业用户。

但这个供应商本身没有太强大的综合应用平台的能力，而这是我们的强项，所以围绕GIS展开的业务，也肯定包含对接“卡口平台”一项。

下面就非常具体的阐述一下相关内容，主要包括：卡口平台的业务情况；对接卡口平台的形式；对接中遇到的具体问题若干举例分析等内容。

 

A.卡口平台的业务情况：

    A1卡口平台简介

      卡口平台它是一个软件平台，并且下辖很多前端设备（当然这些前端设备也可能是被另一个专门的设备平台管辖并对接到卡口平台），。

      卡口平台中的前端设备都是安装在十字路口龙门架上的照相机，能瞬间产生高亮，无论夜晚还是早上都可以拍照片。除了路口，也可能是在高架的收费站或出入口的车道龙门架上的照相机。这些照相机一般是一个或多个“看守”一条车道，每条车道是车辆单向行驶的。所以一般的二车道，四车道，甚至六车道的马路，在路口的地方，你会看到龙门架上安装了好多照相机，闪光灯此起彼伏的拍着照片，不一定是违章拍照，也有正常情况下的拍照。

      使用卡口平台的用户一般是公安或交警部门，他们需要这些卡口的信息收集，以便管理交通，维护社会治安。实际情况中，不同的前端设备（Camera，简称CAM）分属于不同的部门，但由于部门间信息没有充分的互通，肯定是有资源浪费的情况存在。

    A2卡口平台业务

1. 卡口过车历史记录的查询（业务平台平台主动查询卡口平台）；
2. 卡口布防和撤防；
3. 卡口过车实时记录的分发（卡口平台主动推送给业务平台）；
4. 车牌黑名单的布防和撤防；
5. 车牌黑名单告警的分发（卡口平台主动推送给业务平台）；

      * 这里仅列举与比较典型的基本业务，还有一些不常用的就不一一列举，读者可以自己研究；

     关于卡口订阅，取消订阅和实时记录分发： 业务平台可以根据用户的需求，通过卡口平台开放的接口，向卡口平台订阅告警，也就是布防，可以针对某个卡口A的实时布防。那么一旦布防成功，卡口过车的所有实时信息（车辆信息包括，车牌，车身 颜色，是否超速，照片等），就会发送到订阅的业务平台，并转发给用户，实时观看。不需要了就按照接口来退订（撤防）。这类似于设计模式里面经典的订阅分发模型。另外，分发的接口可以是业务平台提供，也可以是卡口平台提供，这要看平台间如何对接（详见：信息系统实践手记4-平台对接的一些思考）；

     关于黑名单布防，撤防和告警分发：它有点类似卡口的订阅，只不过是针对某车牌A的某个时间段来布防，目的是看这两黑名单中的车子是否出现。如果出现，就抓住它，拍照并告警给业务平台（上层平台），触发更多的复杂业务和规则应用。

 

B.对接卡口平台的细节概述：

    平台对接的概述都在（信息系统实践手记4-平台对接的一些思考）中提到了，不再叙述，这里仅仅是罗列细节，供相关专业人士参考；

• 对“卡口布防”相关业务：
  • 卡口设备查询（调用方向:业务平台-->卡口平台）：这很重要，是卡口一些列业务和接口的基础，它一般返回一个长长的卡口设备列表，这很常见。
  • 卡口订阅接口（调用方向:业务平台-->卡口平台）：一般是webservice的形式较多（时下流行的restful的也有）；可以用axis等工具从wsdl直接导出JAVA类，并添加业务，比较简单清晰；（如果是特定的私有接口，比如private私有格式的socket接口，双方协定了二进制byte格式或高级一些的是字符串string，甚至xml格式，这样就需要专门的解析代码，稍微麻烦一点，但也有好处，执行速度较快）；
    • request一般包含字段：“卡口ID，订阅开始时间，订阅结束时间，业务平台标记，等等”
      • “业务平台标记”字段：是考虑到卡口平台和多个业务平台有联系，这取决于卡口平台做的好不好，设计人员功力高不高。没有考虑到的话，协商接口的时候，双方专家最好提一下。如果卡口平台考虑到了，而且不需要额外增加这个“业务平台标记”，说明它自己可以根据调用信息或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查询语句给卡口平台（不太好，但有时因为第三方平台的情况首先，却只能如此）
  • 具体接口因为形式多样，不一一说明；
• 对“卡口布防”相关业务：
  • 黑名单订阅接口（调用方向:业务平台-->卡口平台）：形式类似卡口订阅，略；
  • 黑名单取消订阅接口（调用方向:业务平台-->卡口平台）：略；
  • 黑名单过车记录上报（调用方向:卡口平台-->业务平台）：本质上都是过车信息，支持出发条件不是守护“卡口”，而是守护“车牌”而已；
  • 黑名单记录查询：也类似，略；

 

 

C.业务平台的内部卡口模型：

    这里稍微提及一下业务平台内部对卡口模型（model）的建立，安排和处理，涉及到需求分析，系统设计等内容，只提纲要供参考；

1. 业务系统绝不可以内有专门的内部“卡口模型”来对应卡口相关的业务，否则代码就太烂了；
2. “卡口模型”概念上分几块：卡口设备列表一块；卡口订阅条目一块；黑名单订阅条目一块；实际的过车记录信息一块；历史过车信息一块；
3. “卡口模型”设计上对应分为：卡口设备CACHE；卡口订阅和黑名单订阅CACHE；过车记录实时CACHE；历史过车记录的TABLE（持久化）；
4. “卡口模型”业务规则：围绕上述的几个概念，以及概念落地为数据接口，如CACHE,TABLE等，则可以写业务的伪代码了；
5. 抽象：通过上述处理，屏蔽了业务平台对不同的卡口平台的区别，因为不同卡口平台有很多不同：
   1. 业务功能不同：有的有黑名单，有的只有卡口，有的无实时推送，只能历史查询，等等；
   2. 业务限制不同：有的起止时间只能支持50年，有的更长；有的返回设备列表会自动分页，有的有限制长度，等等；
   3. 业务能力不同：有的推送速度快，能支持10秒一条，甚至更快，甚至可以配置；有的不能配置，有的很慢，等等；
6. 总结：其实对接卡口平台，可以抽象的看作为对接一个“能力平台”，那么自然要将能力集合{能力1，能力2，...}剥离清晰；然后还要设计内部模型，来分多层次的支持这些能力，同时要兼顾和考虑这些能力的抽象和实现程度是不同的，进而考虑不同的对接场景。

 

总结：

平台对接实在是庞大宏观，却又细致入微的工作，没有5到10年的经验，下不来，主持不好。

而且分门别类的各种行业的不同需求，平台，对接方式，日新月异，情况复杂多变，

往往绝对再优秀的框架设计，模式设计，方面编程，场景推演，也难于解决一切问题，

有时甚至是人力问题，就特别遗憾了。这就提到了研发流程和开发管理问题，下次也许我们有机会来谈谈这个老问题。