2016-04-01-信息系統實踐手記4-平臺對接的一些思考

---

layout: post
title: 2016-04-01-信息系統實踐手記4-平臺對接的一些思考
key: 20160401
tags: 系統分析 平臺 對接 聯調 協議 接口 信令 數據 標準
modify_date: 2016-04-01
---

信息系統實踐手記4-平臺對接的一些思考

說明：

• 本文發佈於: gitee,github,博客園
• 轉載和引用請指明原做者和鏈接及出處.

正文：

• 信息系統實踐手記系列是系筆者在平時研發中前後遇到的大小的問題，其中比較典型的內容加以收集和分享。
• 信息系統實踐手記目錄：博客園(或查看源碼的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失效時候的解決辦法，異常狀況的考慮。
  • 還有不少是經驗，找個靠譜的系統專家是關鍵

說明：如本文涉及相關專有名詞或其餘若有問題，請聯繫原做者。文章內容，僅供參考。

END