信息系统实践手记7

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

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

正文

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

作者：太初

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

正文

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

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

但作为专用平台，却没有综合应用平台的能力，而这是综合业务平台的强项，在围绕GIS地图展开的业务开发中，自然也包含了对接“卡口平台”。

下面就具体的阐述一下相关内容，包括：卡口平台的业务情况；对接形式；业务平台自身模型设计等内容。

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

    A1卡口平台简介

      卡口平台是一个软件平台，下辖很多前端设备（有时这些设备被另外的“设备平台”管理，而卡口平台与设备平台有一个对接）。

      卡口平台中的前端设备都是安装在十字路口龙门架上的照相机，能瞬间产生高亮，无论夜晚还是早上都可拍照。除了摄像机，可能还有配合的速度检测仪等设备。这些设备除了在路口，也可能安置在高架的收费站出入口，或其他交通道路的特定位置。一般一个或多个照相机“看守”一条车道，每条车道有车辆（单向）行驶方向。所以一般的二车道，四车道，甚至六车道的道路路口，你会看到龙门架上安装了好多照相机，方向各不同相同，闪光灯此起彼伏的拍着照片。拍照的契机不一定是违章拍摄，也有正常情况下的按需拍照。

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

    A2卡口平台业务

      卡口平台业务很多，下面列举2类比较典型的业务及相关的系列接口。

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

      关于卡口订阅，取消订阅和实时记录分发：

      业务平台可以根据用户的需求，通过卡口平台开放的接口，向卡口平台订阅卡口过车记录的推送服务。一旦订阅成功，该卡口的过车实时信息（车辆信息包括，车牌，车身 颜色，是否超速，照片，等等）就会主动推送到订阅者（业务平台）上，并呈现给用户实时观察。如果不需要了就按照接口来取消订阅。这类似于设计模式里经典的订阅分发模型。另外，分发的接口一般是业务平台来提供，也可以是卡口平台提供，这要看平台间如何对接及协商（详见：信息系统实践手记4-平台对接的一些思考）；

     关于黑名单订阅，取消订阅和告警分发：

     它很类似卡口订阅，只不过它针对的是“某车牌A”在某个时间段的活动情况。如果在订阅（监控/布控）的时间段内，某个卡口出现了此车牌的过车记录，则将信息包装为“一个告警”推送给业务平台，以便后续触发更多的上层复杂业务及规则。

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

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

• 对“卡口订阅”相关业务：
  • 卡口设备查询（调用方向:业务平台-->卡口平台）：这很重要，是卡口一些列业务和接口的基础，它一般返回一个长长的卡口设备列表，这很常见。
  • 卡口订阅接口（调用方向:业务平台-->卡口平台）：一般是webservice的形式较多（时下流行的restful也有）；可以用axis等工具从wsdl直接导出JAVA类，并添加业务代码；（如果是特定的私有接口，比如私有格式的socket接口，双方协定了二进制byte格式或高级一些的字符串string格式，甚至
  • 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查询语句给卡口平台（此方法不太好，但有时因为第三方平台的限制，只能如此）
• 具体接口还有很多，视具体情况协商而定；

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

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

• 业务系统绝不可以没有专门的内部“卡口模型”来对应卡口相关业务，否则代码就太烂了；
  • 你必须充分了解我平台的“业务规则/场景情况/自身能力/边界条件等”；
  • 也必须充分了解对方平台的“它的对接模型/它的场景/它的业务量/它的实现方法/它的一些边界条件/等等”；

• “卡口模型”概念上分几块：卡口设备列表一块；卡口订阅条目一块；黑名单订阅条目一块；实际的过车记录信息一块；历史过车信息一块；权限一块（可选）；等等
• “卡口模型”设计上对应分为：卡口设备CACHE；卡口订阅和黑名单订阅CACHE；过车记录实时CACHE；历史过车记录的TABLE（持久化）；权限数据结构；等等
• “卡口模型”业务规则：围绕上述的几个概念，以及概念落地为数据结构，如CACHE,TABLE等，则可以写出业务的伪代码了；
• 模型用业务抽象来屏蔽实现差异：通过上述处理，屏蔽了不同卡口平台的区别。而实践中不同的卡口平台往往有诸多差异：
  • 业务功能不同：有的有黑名单，有的只有卡口，有的无实时推送，只能历史查询，等等；
  • 业务限制不同：有的起止时间只能支持50年，有的更长；有的返回设备列表会自动分页，有的有限制长度，等等；
  • 业务能力不同：有的推送速度快，能支持10秒一条，甚至更快，甚至可以配置间隔；有的不能配置，有的效率很低很慢，等等；
• 总结：其实对接卡口平台，可以抽象的看作对接一个“能力平台”，那么自然要将能力集合{能力1，能力2，...}剥离清晰；然后还要设计内部模型，来分多层次支持这些能力，同时要兼顾和考虑这些抽象能力的具体实现（第三方能力平台的供应商）程度可能有差异（并不一致），进而考虑不同程度，不同场景的对接情况。

总结：

平台对接实在是庞大宏观，却又细致入微的工作，没有5到10年的经验，下不来，主持不好工作，容易留下坑，日后自己还会中招。

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

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

有时甚至还是人力问题，那往往就特别遗憾（干瞪眼，明明有人就能做的很漂亮，很优雅）。

这不可避免的就提到了研发流程和开发管理问题，也许下次有机会可以聊聊。

谢谢。

原标题：信息系统实践手记7

关键词：