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

[[435679]]

規(guī)劃階段

觀看供應(yīng)商演示后不要立即做出決定

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

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

正確安排團(tuán)隊(duì)成員

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

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

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

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

最終，這個(gè)決定歸結(jié)為兩個(gè)因素：時(shí)間與金錢。認(rèn)為的組織主要選擇哪個(gè)選項(xiàng)?

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

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

選擇集成供應(yīng)商時(shí)，必須仔細(xì)考慮這兩個(gè)方面。

• 實(shí)施階段
• 正確進(jìn)行集成DevOps流程

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

部署新工件后，大多數(shù)集成中間件服務(wù)器都需要重新啟動(dòng)。必須從負(fù)載平衡器池中取出服務(wù)器，部署工件文件，然后將服務(wù)器添加回池中。大多數(shù)時(shí)候，運(yùn)營團(tuán)隊(duì)必須在多臺(tái)服務(wù)器上重復(fù)該過程，以使其保持同步和一致?？偠灾碌墓ぜ渴鹗且粋€(gè)耗時(shí)，容易出錯(cuò)的手動(dòng)過程。

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

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

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

用于集成項(xiàng)目的CI/CD管道示例。資源。

遵循正確的彈性模式

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

如果源系統(tǒng)期望以同步方式進(jìn)行響應(yīng)，請嘗試?yán)弥虚g件隨附的可靠性功能，例如重試和斷路器。對于需要可靠傳遞的消息，請使用異步消息傳遞而不是請求-答復(fù)操作。

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

正確保護(hù)移動(dòng)中的數(shù)據(jù)

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

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

運(yùn)維階段

正確設(shè)置可觀察性堆棧

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

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

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

通過在服務(wù)器機(jī)群上啟用實(shí)時(shí)遙測，可以收到有關(guān)停機(jī)，服務(wù)器負(fù)載過重以及機(jī)隊(duì)整體運(yùn)行狀況的通知。這有助于運(yùn)營團(tuán)隊(duì)主動(dòng)解決問題，而不是等待災(zāi)難。

調(diào)試工具是團(tuán)隊(duì)的朋友

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

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

為了快速識(shí)別集成瓶頸，的團(tuán)隊(duì)成員還應(yīng)該熟悉Java堆轉(zhuǎn)儲(chǔ)分析和SQL查詢跟蹤等技能。

按比例擴(kuò)展到源系統(tǒng)和目標(biāo)系統(tǒng)

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

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

結(jié)論

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

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