在本文中，我整理了從許多集成項目中以集成顧問的方式學到的教訓。無論是建筑師還是開發(fā)人員，在計劃新的集成項目或升級當前集成項目時，可能會發(fā)現(xiàn)此信息很有用。

[[435679]]

規(guī)劃階段

觀看供應商演示后不要立即做出決定

在評估階段，將坐在許多供應商的演示文稿和演示中。但是不要基于此判斷任何集成產(chǎn)品。集成產(chǎn)品在演示中可能看起來不錯，但有責任通過根據(jù)實際生產(chǎn)工作負載對其進行評估來做出最終決定。

在做出決定之前，請對每個供應商的產(chǎn)品進行PoC，以查看在預期的2-3年的流量下其性能如何。另外，如果要替換現(xiàn)有系統(tǒng)，請考慮遷移路徑及其提供的支持。

正確安排團隊成員

在計劃新的集成項目時，從第一天開始雇用具有適當技能的人員總是更好的選擇。如今，許多集成項目都需要超出集成中間件范圍的專業(yè)知識。DevOps，基礎架構，可觀察性，數(shù)據(jù)庫，安全性和編程是新員工應具備的一些頂級技能。

例如，當?shù)膱F隊正在開發(fā)集成時，通常需要聯(lián)系其他團隊來完成任務?？赡苄枰稍僁BA來驗證數(shù)據(jù)庫架構，從Ops工程師那里獲得幫助以計劃部署，并從QA團隊那里獲得指導來設計性能測試方案。協(xié)作對項目有利。但是，如果過多地依賴他人，那將會拖累開發(fā)進度。

如果的團隊擁有上述專業(yè)知識怎么辦?這樣，的團隊就可以自足解決自己的問題并快速行動。因此，在規(guī)劃，構建和管理集成項目時，擁有一支由各種人才組成的團隊至關重要。

開源還是商業(yè)供應商?

最終，這個決定歸結為兩個因素：時間與金錢。認為的組織主要選擇哪個選項?

預算充裕的組織會在商業(yè)集成工具，支持服務和高素質(zhì)人才上投入大量資金。他們的主要目的是盡快完成整合項目并投放市場。時間對他們來說至關重要-不管他們花多少錢來建立和支持項目。

另一方面，有些組織的預算和資源有限。但是，他們有足夠的時間嘗試使用開源工具。他們經(jīng)常自己支持產(chǎn)品，并為開源社區(qū)做出貢獻。

選擇集成供應商時，必須仔細考慮這兩個方面。

• 實施階段
• 正確進行集成DevOps流程

傳統(tǒng)上，開發(fā)人員執(zhí)行所有集成，然后他們將最終的工件投入運營中，以將其部署到生產(chǎn)中。由于缺乏集成工具特定的知識，因此運營團隊在嘗試進行部署和故障排除時遇到了噩夢。

部署新工件后，大多數(shù)集成中間件服務器都需要重新啟動。必須從負載平衡器池中取出服務器，部署工件文件，然后將服務器添加回池中。大多數(shù)時候，運營團隊必須在多臺服務器上重復該過程，以使其保持同步和一致。總而言之，新的工件部署是一個耗時，容易出錯的手動過程。

想象一下，如果不得不一天之內(nèi)進行多個部署，那么這將給開發(fā)人員和運營團隊帶來壓力。這使整個開發(fā)，測試和部署周期變慢-甚至需要花費數(shù)周的時間來部署集成的一個小的修復程序。

如果集成開發(fā)人員具有強大而快速的流程來本地驗證其更改并以可靠的方式將其推向生產(chǎn)，則可以消除這種情況。完善的CI/CD管道將自動構建開發(fā)人員更改，對其進行測試，并最終以最少的人工干預跨多個環(huán)境部署構建工件。它具有可擴展性，高效性和可靠性-使的開發(fā)人員和運營團隊感到滿意。

因此，請考慮從第一天開始建立適當?shù)腄evOps流程，以管理的集成開發(fā)流程。

用于集成項目的CI/CD管道示例。資源。

遵循正確的彈性模式

通過集成中間件集成兩個系統(tǒng)時，不僅應該關注幸福的道路。如果沒有的控制，將無法保證源系統(tǒng)和目標系統(tǒng)的來來往往。但是，完全可以控制中間件在下雨天的行為。

如果源系統(tǒng)期望以同步方式進行響應，請嘗試利用中間件隨附的可靠性功能，例如重試和斷路器。對于需要可靠傳遞的消息，請使用異步消息傳遞而不是請求-答復操作。

最重要的是，如果在中間失敗，請不要保持沉默。盡可能執(zhí)行必要的日志記錄，并實施補償事務，以確保故障后的一致性。

正確保護移動中的數(shù)據(jù)

對流經(jīng)集成中間件的數(shù)據(jù)負責。在企業(yè)數(shù)據(jù)泄露之后，主動保護數(shù)據(jù)移動總是比執(zhí)行損壞控制總要好。

從外部系統(tǒng)接收數(shù)據(jù)或向外部系統(tǒng)發(fā)送數(shù)據(jù)時，請使用中間件支持的傳輸層或應用程序級安全方案。如今，大多數(shù)工具都支持雙向TLS，OAuth2.0等標準。

運維階段

正確設置可觀察性堆棧

負責將到達集成中間件的任何消息傳遞到其最終目的地。這可能會在許多方面出問題。中間件可能無法處理請求，或者目標系統(tǒng)沒有響應?；蛘?，中間件沒有從源系統(tǒng)收到任何信息。如何自信地說出實際情況?

此時，可觀察性工具將為提供幫助。使用分布式跟蹤工具來跟蹤跨系統(tǒng)的消息的端到端遍歷。這樣，可以發(fā)現(xiàn)丟失消息的地方。Jaeger是分布式跟蹤工具的一個很好的例子。

使用Logstash，F(xiàn)luentd和GreyLog等日志聚合工具將中間件日志發(fā)送到中央位置，以便可以從中央位置進行日志分析。諸如ElasticSearch，Kibana和Splunk之類的工具提供了豐富的日志分析支持。

通過在服務器機群上啟用實時遙測，可以收到有關停機，服務器負載過重以及機隊整體運行狀況的通知。這有助于運營團隊主動解決問題，而不是等待災難。

調(diào)試工具是團隊的朋友

系統(tǒng)發(fā)生事件后，的團隊成員不應該玩分布式游戲。應該有一套適當?shù)恼{(diào)試工具來隔離系統(tǒng)中的故障。

擁有模擬源系統(tǒng)和目標系統(tǒng)的工具對于孤立地對集成中間件進行故障排除至關重要。ApacheJMeter，SoapUI和Postman是此類工具的少數(shù)示例。

為了快速識別集成瓶頸，的團隊成員還應該熟悉Java堆轉儲分析和SQL查詢跟蹤等技能。

按比例擴展到源系統(tǒng)和目標系統(tǒng)

當上游系統(tǒng)擴大規(guī)模并發(fā)送更多流量時，集成層也應按比例擴大。否則，中間將存在性能瓶頸。

將流量發(fā)送到速度較慢的下游系統(tǒng)時，應遵循最佳做法，以免耗盡它們。例如，可以在中間件和下游系統(tǒng)之間放置一個消息隊列，以便中間件可以在其中放置消息，而不是將消息直接發(fā)送到下游系統(tǒng)。這樣，隊列就像緩沖區(qū)一樣，吸收了傳入流量中的突然尖峰。另外，可以考慮在集成層限制消息的數(shù)量作為預防措施。

結論

無論使用Kubernetes和服務網(wǎng)格之類的云原生技術，還是使用VM和ESB都沒有關系。重要的是從小處著手，加快迭代速度，并從錯誤中吸取教訓。

當想通過ESB將消息從系統(tǒng)A發(fā)送到B時，至少在第一次迭代時，不必在Kubernetes上部署所有內(nèi)容。從長期可以承受和建立并維護的技術堆棧開始。隨著的集成項目在組織中獲得堅實的立足點，可以接受新的趨勢。