2016-04-01-信息系统实践手记4-平台对接的一些思考
信息系统实践手记4-平台对接的一些思考
说明：
正文：
- 信息系统实践手记系列是系笔者在平时研发中先后遇到的大小的问题，其中比较典型的内容加以收集和分享。
- 信息系统实践手记目录：博客园(或查看源码的README.MD文件)
摘要：
- 此文描述了笔者接触过的部分信息系统或平台之间的对接构型和情况，挂一漏万的总结分享之。
正文
1.什么是平台对接？
一般的信息系统有两种：
- （A）单套（单功能）：它一般比较专业，单独安装在通用或专用硬件上，有统一的用户接口，专门执行一个功能。自己完成数据的采集，计算，呈现，控制，反馈等内容。
- （B）群件（多功能）：这类信息系统中含有多个模块（一个模块一套专业功能），甚至多个平台（每个平台含多个模块）平面或多层级联。如果是多平台级联，则一定会遇到平台对接问题。一般一个集成项目合同中内容很多，涉及多个信息系统（多个平台），它们由多个厂家（公司）开发，互为第三方，合作完成需求集合。每个平台都必须按照某种规则和机制互相连接，这就会引起平台对接的情况。
2.平台对接要考虑哪些方面？
一般的，以自己负责的平台，或产品角度来看待问题，你会发现自家平台A（系统A），需要对接平台B（系统B）,平台C（系统C）等，需要考虑（包含但不限于）如下方面：
- 平台间的功能划分
- 这一般由产品经理和方案经理负责处理。研发部门搞出来的产品是有《Feature List》（描述功能集合）文档的。拿着这些现存的积木块，搭建起来某种类型的方案（Solution），也就是我方平台（产品）的SCOPE（功能边界）。搞清楚自己的SCOPE后，就能清晰界定其他第三方平台的SCOPE了。
- 等所有平台等都划分清晰SCOPE了，那谁该实现什么功能？就很清晰了。虽然过程是“痛苦”的争论，但确定后以合同，备忘录，或至少email形式，正式的多方抄送，没有异议，并留下证据。最终方案由集成商牵头提交用户审核。
- 平台间互通协议确定
- 既然确定了功能边界，不同平台之间如何互通？就可以进一步讨论了。这需要干系人（相关各大平台的各类专家）坐在一起制定互通协议。
- 一般的，各平台都有“系统专家（架构师）”，会以他们为主讨论。而且集成商一般会牵头，这时要看谁强势。每个平台都希望自己少做甚至不做开发，而对方直接参照己方已经支持的协议或标准来对接自己平台（信令和数据）。这是一个摆事实，讲道理的时间。客观上也是有规则可遵循。
- 平台互通协议设计原则
- 第一，尽量站在自家平台立场，力争改动最小，这样肯定人力最小，bug最少，速度最快，最方便。
- 第二，尽量使用通用技术（框架），比如国标（国家标准）GB等，国际标准H264，RTP/RTSP,SIP等。这对以后联调，对接，抓包，分析，留证据等都有利。
- 第三，尽量不要“临时尝鲜”，找一个不成熟的新框架或新标准，各个平台和各路专家都不懂，绝对得不偿失，但往往不懂技术的领导特别会这样要求。
- 第四，尽量采用简单的技术框架，因为对接是个麻烦事，意料之外的麻烦一定会发生（墨菲定律），协议/标准/框架/类库，尽量精简，能省则省，能减则减。
- 第五，遇到意料之外的情况，一定不要想workaround的办法绕过去，最后一定是自己吃亏，理应在最初就将困难摊在台面上大家争执讨论，共同承担和研究。
- 第六，尽量不要将工作量压在一个平台上，比如欺负某家弱势小公司，威逼它做大量修改来迎合其他强势平台。相反，你需要审核弱势平台的人力配备，能力除非，是否能按时交货？否则即便有合同在，但研发是一个客观过程，不会一蹴而就，不会有惊喜。工作量的不均衡只会造成不必要的“关键路径”，并且往往导致整体失败。
- （还有更多经验，不再累赘，都是个人体悟）
- 平台互通的开发和联调
- 每个平台各自开发，终会互相联调。永远要提前准备好，尽快切入开发，做联调的“主动的催促者”，而不是“被动落后者”。这虽然会多花一些协调的人力，但你有机会盯紧对方，让联调偏向自己的有利方面，拿到主动，控制节奏，看着对方围着你头头转，而你舒服的拿到的“管理权柄”！
- 准备好迎接错误。联调一定会出错，要有手段测试，审计，抓包，检查流程，逐级排查各个相关模块，查看信令，查看数据。绝对不能向无头苍蝇，没有无缘无故的BUG，而BUG也绝对不会自动修复，一切都必须有据可依。特别要防止多方互相推诿责任和问题。一定要先发制人的给出证据，哪怕错了，不丢脸，积极推动，拿到“联调主动权”，成为积极推动者，无论对合同的执行和厂家的信誉建设，都非常有利（说不定就拿到更多的合同，这是经常发生的事情）。
- 调测完毕后，主线会合并分支代码（联调分支），一定要正式出包，现场复测！这个非常重要。因为每个厂家的平台因为多个合同，往往会有多个现场。许多第三方平台在不同现场是多个不同的平台版本，而第三方的版本管理同样会有问题（每个研发部都是一样的问题），我们自己的版本管理也往往会忙中出错。所以一定要复测，拿着版本号说话。
- （还有更多经验，不再累赘，都是个人体悟）
- 平台互通收尾
- 联调完毕，但还有很多事情要做。比如技术总结，项目流程总结，版本收纳，分支和主线的合并，workaround的处理，遗留问题的处置。
- 在现场A的平台调通，还要同步功能到主线后，发布到其他现场做部署和升级。
3.平台对接实践经验分享
- 项目经验
- 掌握主动，一定要我方产品经理，方案经理，系统专家（架构师），项目经理，尽早切入讨论，哪怕是详细的技术solution研讨。
- 清晰划分工作界面，产品scope，接口定义清晰，不武断，不专断，友好而激烈的讨论，这里最容易争执。
- 采用自己熟悉的技术，兼顾对方技术，平衡工作量。
- 一定要确定接口人，确定时间点（schedule），哪怕实际上时间必定偏差，但绝对比没有PLAN好太多！
- 有些第三方厂家直接扔过来N个研发人员，自己居然不管理，让我方PM管理。要记住，这算是好的情况，你还能安排他们工作，至少面上如此。最糟的情况是，对方答应给你干活，其实没有干，到时间点了耍无赖！
- 用《进度推进表》，《BUG跟踪表》等支持PM工作，一定要紧盯对方，拿到联调主动权。主动出击，牵头联调，保障自己平台不是拖后腿的。
- 联调完毕，代码合并，版本记录，重新发布正式版本测试，一定要做细致，别一高兴，结果乱了。
- 技术经验
- 一般平台对接，信令要对接，数据也要对接。信令对接大都是传递数据结构，典型的是传递“设备列表”，这个情况有很多种：
- 有直接读取对方DB的方法：优点是快速，简单，直接，粗暴，但其实不太建议。除非是兄弟产品间可以“深度集成”，如此”坦诚相见“，否则不太合适；缺点是对方的一个升版就可能导致对接情况发生不可预知的变化，也容易弄坏人家的DB，说也说不清楚。
- 按接口互通：这个是通常的做法，一般速度还可以接受，耦合度低，通用性强，对方即便升级，也有义务维持接口不变，方便联调。
- 按标准互通：按照某领域的互通标准（比如GB国标互联互通协议等）来对接“设备列表”等信令信息。好处是标准比较容易推行，各大厂家都遵守。但难点是需要吃透标准，有些标准里面有“自定义”字段，这些就是潜在的问题点（坑）！一个不小心就摔进去了，一定要经常和各厂家开会，互通进度，积极联调。当然也可制定附加的技术接口和协议，作为变化的保障。
- 对接平台除了信令，最多的还是互通数据。一般数据量会比较大，要求高速，实时，这对两边的平台都是考验。
- 双方友好协商，无论对方是否专业，我方必须将专业的咨询分析结果呈报出来，互相讨论，切莫坑蒙拐骗。
- 要讨论数据的业务规律，比如出现频率，峰值，规则，表现，时空特性，是否存储，数据的消费节点Px的处理路径。数据的生成和消费节点往往额外重要。
- 选定好的数据结构，考虑安全和压缩等功能。
- 考虑数据处理节点Px失效时候的解决办法，异常情况的考虑。
- 还有很多是经验，找个靠谱的系统专家是关键
- 一般平台对接，信令要对接，数据也要对接。信令对接大都是传递数据结构，典型的是传递“设备列表”，这个情况有很多种：
说明：如本文涉及相关专有名词或其他如有问题，请联系原作者。文章内容，仅供参考。