在本文中，我整理了從許多整合專案中以整合顧問的方式學到的教訓。無論是建築師還是開發人員，在計劃新的整合專案或升級當前整合專案時，可能會發現此資訊很有用。
規劃階段
觀看供應商演示後不要立即做出決定
在評估階段，將坐在許多供應商的簡報和演示中。但是不要基於此判斷任何整合產品。整合產品在演示中可能看起來不錯，但有責任透過根據實際生產工作負載對其進行評估來做出最終決定。
在做出決定之前，請對每個供應商的產品進行PoC，以檢視在預期的2-3年的流量下其效能如何。另外，如果要替換現有系統，請考慮遷移路徑及其提供的支援。
正確安排團隊成員
在計劃新的整合專案時，從第一天開始僱用具有適當技能的人員總是更好的選擇。如今，許多整合專案都需要超出整合中介軟體範圍的專業知識。DevOps，基礎架構，可觀察性，資料庫，安全性和程式設計是新員工應具備的一些頂級技能。
例如，當的團隊正在開發整合時，通常需要聯絡其他團隊來完成任務。可能需要諮詢DBA來驗證資料庫架構，從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上部署所有內容。從長期可以承受和建立並維護的技術堆疊開始。隨著的整合專案在組織中獲得堅實的立足點，可以接受新的趨勢。
好了，今天的文章分享到這就結束了，要是喜歡的朋友，請點個關注哦！——我是簡搭（jabdp），我為自己“帶鹽”，感謝大家關注。
