信息系统实践手记4-平台对接的一些思考

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

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

正文

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

作者：太初

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

1.什么是平台对接？

一般的信息系统有两种：一种是单套单功能的，一般比较专业，单独的安装在通用或专门硬件上，统一的用户接口（比如客户端）专门执行一个功能。它往往自己完成了数据的采集，计算，呈现，控制，反馈等内容。另一种，就是群件。信息系统中含有多个模块（一般以功能高内聚来区分模块），甚至多个平台（以一整套较为完整功能集合定义为平台）。如果是后一种多平台连接在一起的较大的信息系统，就一定会越到平台对接？为什么？ 当然是一个合同中的信息系统的多个平台，一般都是多个厂家（公司）开发，互为第三方，合作完成整体功能。每个小部分（平台）必须按照某种规则和机制互相连接。这就越到了平台对接的问题。

2.平台对接要考虑哪些方面？

一般的，以自己负责的平台或者公司的平台产品角度来看问题，你会发现你的平台A，会需要对接平台B,平台C等等，那么需要考虑哪些方面呢？

• 平台间的功能划分
  • 这往往是产品经理和方案经理出马的地方。研发部门搞出来的产品是有《FeatureList》（功能集合）的。拿着这些积木搭建起来若干方案Solution，也就是我方产品或平台提供的“功能边界”（SCOPE）了。搞清楚了自己的SCOPE，还需要了解其他几个第三方平台的“功能边界”SCOPE。
  • 等所有平台A,B,C等都划分清晰了，谁干什么，argue之后，定下，email发出留下证据，形成给用户的最终方案，由集成商牵头提交，并组织各厂商实施不同平台的部署和联调。
• 平台间互通协议确定
  • 既然确定了功能边界，那么不同平台之间的互通就提上日程。需要大家坐在一起根据需要不同来制定互通的协议。
  • 一般的，各平台都有“系统专家（架构师）”，会参与讨论，集成商牵头，这个时候就看谁强势了。每个平台都希望不做或少做额外的开发，对方直接按照自己的协议或标准来对接自己的信令和数据，这是一个大家摆事实，讲道理的时间。但客观上还是可以有规则可以遵循。
• 平台互通协议设计原则
  • 尽量站在自家平台的立场，企图改动最小，最方便，这是第一。
  • 尽量使用通用技术框架，比如国标GBXXX，国际标准H264，RTP/RTSP,SIP。这对以后联调，对接，抓包，分析，留证据等都有利，说得清。此其二。
  • 尽量不要临时尝鲜，找到一个不成熟的框架或协议，各个平台都不太懂，没领域专家，这样的事情绝对不能做，但往往不懂技术的领导会要求。此其三。
  • 其他情况等价的时候，尽量用简单的技术框架，因为对接是个麻烦事，意料之外的麻烦一定会发生（墨菲定律），能省则省，能减则减，此其四。
  • 遇到新情况，一定不要直接思考workaround的办法，想要绕过去，最后一定自己吃亏，就应在最初就将对接的困难摊在台面上，大家吵一吵，此其五。
  • 智慧的PM会建议，不要将工作量压在一个平台，欺负他为了赚钱而愿意屈服，你需要审核它的人力，能力，是否能按时交货，即便有合同保证，但客观上讲，研发是一个科学的过程，工作量的不均衡，不但容易造成不必要的“关键路径”，而且往往会导致整体失败。即便赔偿了，延期也是对整个solution的不利。此其六。
  • 余下的，技术上面的考虑，属于偏TECH方面，也有不少原则，但一般有法可依，有理可讲，下面再叙述。
• 平台互通的开发和联调
  • 每个平台各自都会开发，也都会联调。永远记住，要提前准备好，尽快切入开发，做主动的催促者，不做被动的落后者。虽然催促者容易多花effort去协调，盯紧对方，但调测的过程是偏向自己的，能拿到主动，对方围着你头头转，你就拿到的“管理权柄”！
  • 准备好迎接错误，联调一定会出错，要有手段测试，审计，抓包，检查流程（逐级排查网元），查看信令，查看数据，无据可依不是专业的体现，也往往容易导致多方纠缠和推诿。一定要先发制人的给出证据，哪怕错了，不丢脸，积极推动，拿到“联调主动权”，让他人的人力围着你。
  • 调测完毕，主线合并代码后，一定要正式出包，现场复测！这个非常重要。因为往往有多个现场，第三方的一个平台也有多个版本，对方自己的版本管理也许会有问题，你自己的版本管理也往往会忙中出错，一定要复测，拿着版本号说话。
  • 还有太多经验教训，不一一列举。
• 平台互通收尾
• 联调完毕，其实还有很多事情要做。比如，技术总结，项目流程总结，版本收纳，分支和主线的合并，workaround的处理，遗留问题的处置。
• 此联调OK的功能还要同步到主线或分支来提供其他现场的部署和升级。

3.平台对接实践经验分享

• 项目经验
  • 掌握主动，一定要我方产品经理，方案经理，系统专家（架构师），项目经理，尽早切入讨论，哪怕是详细的技术solution研讨。
  • 清晰划分工作界面，产品scope，接口定义清晰，不武断，不专断，有好激烈讨论，这里最容易争执。
  • 采用自己熟悉的技术，兼容对方接受，平衡工作量。
  • 一定要确定接口人，确定时间，哪怕最后时间肯定会变化，开始不确定，最后变化的就没边没谱了！
  • 有些第三方就扔过来3个研发人员，都不管理，让我方PM自己管理，要记住，这算是好的情况，对方赖着不干活才是最麻烦。
  • 用《进度推进表》，《BUG跟踪表》等支持PM工作，一定要紧盯对方，拿到联调主动权。主动出击，牵头联调，保障自己平台不是拖后腿的。
  • 联调完毕，代码合并，版本记录，重新发布正式版本测试，一定要做细致，别一高兴，结果乱了。
• 技术经验
  • 一般平台对接，信令要对接，数据也要对接。信令对接大都是传递数据结构，典型的是传递“设备列表”，这个情况太多了。怎么传递？方法很多。
    • 有直接读取对方DB的方法：快速，简单，直接，粗暴，不太建议，除非是兄弟产品可以“深度集成”，不然以后会有问题，对方的一个升版就导致不可预知的情况。
    • 接口对接法：这个是通常的办法，一般速度还可以，相对复杂，但是耦合度低，通用性强。对方即便升级，但需要维持接口不变化，而且联调测试方便。
    • 按标准互通：比如按照某领域的“GB国标”对接“设备列表”等信令信息， 那么就要大家吃透标准，经常互通，有些标准里面甚至有附加“自定义”字段，这些就是坑！一个不小心摔进去了，一定要经常研讨开会，互通进度。也可制定附加的技术接口和协议，作为变化的保障。
  • 对接平台除了信令，最多的还是数据。一般数据会量比较大，要求高速，实时，这对两边的平台都是考验。
    • 双方友好协商，无论对方是否专业，我方必须将专业的咨询分析结果呈报出来，互相讨论。
    • 要讨论数据的规律，出现的频率，峰值，规律，表现，时空特性，是否需要存储，数据在消费节点Px的一系列的行为。数据的发起和终止节点往往额外重要。
    • 选定好的数据结构，考虑安全和压缩等需要。
    • 考虑处理节点Px失效时候的解决办法，异常情况的考虑。
  • 还有很多是经验，找个靠谱的系统专家是关键

说明：如本文涉及相关专有名词或其他如有问题，请联系原作者。文章内容，仅供参考。

[END]