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

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

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

4. 总结:

平台对接实在是庞大宏观，却又细致入微的工作，没有5到10年的经验，下不来，主持不好工作，容易留下坑，日后自己还会中招。
而且分门别类的各种行业不同需求，平台和对接方式日新月异，情况复杂多变，
往往再优秀的框架设计，模式设计，方面编程，场景推演，也难于解决一切问题，
有时甚至还是人力问题，那往往就特别遗憾（干瞪眼，明明有人就能做的很漂亮，很优雅）。
这不可避免的就提到了研发流程和开发管理问题，也许下次有机会可以聊聊。

END