• <code id="yqigy"><object id="yqigy"></object></code>
  • 機房360首頁
    當前位置:首頁 ? CIO管理 ? 企業集成項目管理的經驗和教訓

    企業集成項目管理的經驗和教訓

    來源:機房360 作者:Harris編譯 更新時間:2021/11/18 7:28:36

    摘要:企業集成已經從良好的舊ESB和消息傳遞系統發展到了諸如服務網格之類的現代解決方案。炒作和技術來來去去,但是有效管理集成項目生命周期的基本做法仍然是相同的。

       企業集成已經從良好的舊ESB和消息傳遞系統發展到了諸如服務網格之類的現代解決方案。炒作和技術來來去去,但是有效管理集成項目生命周期的基本做法仍然是相同的。
      
      在本文中,我整理了從許多集成項目中以集成顧問的方式學到的教訓。無論是建筑師還是開發人員,在計劃新的集成項目或升級當前集成項目時,可能會發現此信息很有用。
      
      規劃階段
      
      觀看供應商演示后不要立即做出決定
      
      在評估階段,將坐在許多供應商的演示文稿和演示中。但是不要基于此判斷任何集成產品。集成產品在演示中可能看起來不錯,但有責任通過根據實際生產工作負載對其進行評估來做出最終決定。
      
      在做出決定之前,請對每個供應商的產品進行PoC,以查看在預期的2-3年的流量下其性能如何。另外,如果要替換現有系統,請考慮遷移路徑及其提供的支持。
      
      正確安排團隊成員
      
      在計劃新的集成項目時,從第一天開始雇用具有適當技能的人員總是更好的選擇。如今,許多集成項目都需要超出集成中間件范圍的專業知識。DevOps,基礎架構,可觀察性,數據庫,安全性和編程是新員工應具備的一些頂級技能。
      
      例如,當的團隊正在開發集成時,通常需要聯系其他團隊來完成任務??赡苄枰稍僁BA來驗證數據庫架構,從Ops工程師那里獲得幫助以計劃部署,并從QA團隊那里獲得指導來設計性能測試方案。協作對項目有利。但是,如果過多地依賴他人,那將會拖累開發進度。
      
      如果的團隊擁有上述專業知識怎么辦?這樣,的團隊就可以自足解決自己的問題并快速行動。因此,在規劃,構建和管理集成項目時,擁有一支由各種人才組成的團隊至關重要。
      
      開源還是商業供應商?
      
      最終,這個決定歸結為兩個因素:時間與金錢。認為的組織主要選擇哪個選項?
      
      預算充裕的組織會在商業集成工具,支持服務和高素質人才上投入大量資金。他們的主要目的是盡快完成整合項目并投放市場。時間對他們來說至關重要-不管他們花多少錢來建立和支持項目。
      
      另一方面,有些組織的預算和資源有限。但是,他們有足夠的時間嘗試使用開源工具。他們經常自己支持產品,并為開源社區做出貢獻。
      
      選擇集成供應商時,必須仔細考慮這兩個方面。
      
      實施階段
      
      正確進行集成DevOps流程
      
      傳統上,開發人員執行所有集成,然后他們將最終的工件投入運營中,以將其部署到生產中。由于缺乏集成工具特定的知識,因此運營團隊在嘗試進行部署和故障排除時遇到了噩夢。
      
      部署新工件后,大多數集成中間件服務器都需要重新啟動。必須從負載平衡器池中取出服務器,部署工件文件,然后將服務器添加回池中。大多數時候,運營團隊必須在多臺服務器上重復該過程,以使其保持同步和一致??偠灾?,新的工件部署是一個耗時,容易出錯的手動過程。
      
      想象一下,如果不得不一天之內進行多個部署,那么這將給開發人員和運營團隊帶來壓力。這使整個開發,測試和部署周期變慢-甚至需要花費數周的時間來部署集成的一個小的修復程序。
      
      如果集成開發人員具有強大而快速的流程來本地驗證其更改并以可靠的方式將其推向生產,則可以消除這種情況。完善的CI/CD管道將自動構建開發人員更改,對其進行測試,并最終以最少的人工干預跨多個環境部署構建工件。它具有可擴展性,高效性和可靠性-使的開發人員和運營團隊感到滿意。
      
      因此,請考慮從第一天開始建立適當的DevOps流程,以管理的集成開發流程。
      
      用于集成項目的CI/CD管道示例。資源。
      
      遵循正確的彈性模式
      
      通過集成中間件集成兩個系統時,不僅應該關注幸福的道路。如果沒有的控制,將無法保證源系統和目標系統的來來往往。但是,完全可以控制中間件在下雨天的行為。
      
      如果源系統期望以同步方式進行響應,請嘗試利用中間件隨附的可靠性功能,例如重試和斷路器。對于需要可靠傳遞的消息,請使用異步消息傳遞而不是請求-答復操作。
      
      最重要的是,如果在中間失敗,請不要保持沉默。盡可能執行必要的日志記錄,并實施補償事務,以確保故障后的一致性。
      
      正確保護移動中的數據
      
      對流經集成中間件的數據負責。在企業數據泄露之后,主動保護數據移動總是比執行損壞控制總要好。
      
      從外部系統接收數據或向外部系統發送數據時,請使用中間件支持的傳輸層或應用程序級安全方案。如今,大多數工具都支持雙向TLS,OAuth2.0等標準。
      
      運維階段
      
      正確設置可觀察性堆棧
      
      負責將到達集成中間件的任何消息傳遞到其最終目的地。這可能會在許多方面出問題。中間件可能無法處理請求,或者目標系統沒有響應?;蛘?,中間件沒有從源系統收到任何信息。如何自信地說出實際情況?
      
      此時,可觀察性工具將為提供幫助。使用分布式跟蹤工具來跟蹤跨系統的消息的端到端遍歷。這樣,可以發現丟失消息的地方。Jaeger是分布式跟蹤工具的一個很好的例子。
      
      使用Logstash,Fluentd和GreyLog等日志聚合工具將中間件日志發送到中央位置,以便可以從中央位置進行日志分析。諸如ElasticSearch,Kibana和Splunk之類的工具提供了豐富的日志分析支持。
      
      通過在服務器機群上啟用實時遙測,可以收到有關停機,服務器負載過重以及機隊整體運行狀況的通知。這有助于運營團隊主動解決問題,而不是等待災難。
      
      調試工具是團隊的朋友
      
      系統發生事件后,的團隊成員不應該玩分布式游戲。應該有一套適當的調試工具來隔離系統中的故障。
      
      擁有模擬源系統和目標系統的工具對于孤立地對集成中間件進行故障排除至關重要。ApacheJMeter,SoapUI和Postman是此類工具的少數示例。
      
      為了快速識別集成瓶頸,的團隊成員還應該熟悉Java堆轉儲分析和SQL查詢跟蹤等技能。
      
      按比例擴展到源系統和目標系統
      
      當上游系統擴大規模并發送更多流量時,集成層也應按比例擴大。否則,中間將存在性能瓶頸。
      
      將流量發送到速度較慢的下游系統時,應遵循最佳做法,以免耗盡它們。例如,可以在中間件和下游系統之間放置一個消息隊列,以便中間件可以在其中放置消息,而不是將消息直接發送到下游系統。這樣,隊列就像緩沖區一樣,吸收了傳入流量中的突然尖峰。另外,可以考慮在集成層限制消息的數量作為預防措施。
      
      結論
      
      無論使用Kubernetes和服務網格之類的云原生技術,還是使用VM和ESB都沒有關系。重要的是從小處著手,加快迭代速度,并從錯誤中吸取教訓。
      
      當想通過ESB將消息從系統A發送到B時,至少在第一次迭代時,不必在Kubernetes上部署所有內容。從長期可以承受和建立并維護的技術堆棧開始。隨著的集成項目在組織中獲得堅實的立足點,可以接受新的趨勢。
      
      編輯:Harris

    機房360微信公眾號訂閱
    掃一掃,訂閱更多數據中心資訊

    本文地址:http://www.sorostrading.com/news/20211118/n2520141559.html 網友評論: 閱讀次數:
    版權聲明:凡本站原創文章,未經授權,禁止轉載,否則追究法律責任。
    相關評論
    正在加載評論列表...
    評論表單加載中...
    • 我要分享
    推薦圖片
    在车上疯狂抚弄她娇喘视频
  • <code id="yqigy"><object id="yqigy"></object></code>