ควรใช้ Spring Integration vs. Camel เมื่อใด


142

ในฐานะผู้ใช้ Spring ที่ช่ำชองฉันคิดว่า Spring Integration จะเหมาะสมที่สุดในโครงการล่าสุดที่ต้องการความสามารถในการส่งข้อความ (JMS) บางอย่าง ( รายละเอียดเพิ่มเติม ) หลังจากใช้งาน Spring Integration มาหลายวันก็ยังรู้สึกเหมือนมีค่าใช้จ่ายในการกำหนดค่าจำนวนมากเนื่องจากจำนวนช่องสัญญาณที่คุณต้องกำหนดค่าเพื่อให้มีการสื่อสารตามคำขอตอบสนอง (ฟังในคิว JMS ที่แตกต่างกัน)

ดังนั้นฉันจึงค้นหาข้อมูลพื้นฐานว่า Camel แตกต่างจาก Spring Integration อย่างไร แต่ดูเหมือนว่าข้อมูลจะมีอยู่พอสมควรฉันพบ:

คำถามคือคุณมีประสบการณ์อะไรบ้างในการใช้กองซ้อนทับอีกอัน? คุณจะแนะนำ Camel ในสถานการณ์ใดบ้างเนื่องจาก Spring Integration ขาดการสนับสนุน คุณเห็นข้อดีข้อเสียของแต่ละข้อตรงไหน? คำแนะนำใด ๆ จากโครงการจริงจะได้รับการชื่นชมอย่างมาก


5
ด้วยการผสานรวมที่ยอดเยี่ยมอย่าง Camel กับ Spring ฉันไม่เห็นเหตุผลที่ดีเลยที่จะดู Spring Integration อูฐเก่งในทุกด้าน: กระชับใช้งานง่ายทรงพลัง ... สนุก คุณสามารถทำสิ่งต่างๆให้สำเร็จได้ด้วยโค้ดเพียงบรรทัดเดียวซึ่งบางครั้งฉันก็รู้สึกผิดที่เขียนโค้ดไม่เพียงพอที่จะพิสูจน์ฟังก์ชัน
Pavel Lechev

คำตอบ:


78

เราเลือก Camel มากกว่า Spring-Integration เพราะ API ที่คล่องแคล่วนั้นดีมาก เราใช้มันจริงในโครงการ Spring และใช้ Spring เพื่อกำหนดค่าบางส่วน API การเขียนโปรแกรมมีความชัดเจนและมีส่วนประกอบที่เหมาะสมจำนวนมาก

เราทำการยิงปืนเล็ก ๆ และโดยพื้นฐานแล้วในเวลานั้นสำหรับความต้องการของเรา Camel ได้รับรางวัล เราใช้เป็นหลักในการถ่ายโอนข้อมูลภายในไปยัง / จากบุคคลภายนอกซึ่งโดยปกติจะต้องมีการแปลงรูปแบบที่ส่งโดยใช้ ftp / sftp / ... หรือแนบไปกับอีเมลและส่งออก

เราพบว่าวงจรแก้ไข - คอมไพล์ - ดีบักลดลง การใช้ groovy เพื่อทดสอบการตั้งค่าเส้นทางจะได้รับโบนัสเพิ่ม

Spring-Integration เป็นผลิตภัณฑ์ที่ยอดเยี่ยมเช่นกันและฉันค่อนข้างแน่ใจว่ามันจะตอบสนองความต้องการของเราด้วย


1
ขอบคุณ Peter ที่แบ่งปันคะแนนของคุณคุณเคยลองใช้ความสามารถ JMS ของ Camel หรือไม่ดูเหมือนว่าส่วนประกอบต่างๆจะค่อนข้างยืดหยุ่นและมีความสมบูรณ์เช่นเดียวกับ Spring Integration หรือไม่? โดย "ยิงขนาดเล็ก" คุณอ้างถึงตัวเลขประสิทธิภาพที่ดีกว่าหรือไม่
ngeek

1
Shootout: มันคือประสิทธิภาพของนักพัฒนาเป็นหลัก ความต้องการด้านประสิทธิภาพของเราไม่สูงมาก ใช่เราใช้ JMS จำนวนมากเป็นพื้นฐาน ทั้ง ActiveMQ และ JBossMQ ใช้สำหรับการส่งข้อความ
Peter Tillemans


70

ฉันแนะนำ Spring Integration ก็ต่อเมื่อคุณมีโปรเจ็กต์ Spring อยู่แล้วและคุณเพิ่งจะเพิ่มการรวม "พื้นฐาน" โดยใช้ File, FTP, JMS, JDBC และอื่น ๆ

Apache Camel มีข้อดีสองประการ:

  1. รองรับเทคโนโลยีอื่น ๆ อีกมากมาย
  2. นอกจากนี้ XML DSL (ดี) ยังมี API ที่คล่องแคล่วสำหรับ Java, Groovy และ Scala

เนื่องจาก Apache Camel ทำงานร่วมกับ Spring ได้ดีมากฉันจึงใช้มันแทน Spring Integration ในโครงการ Spring ส่วนใหญ่

หากคุณต้องการรายละเอียดเพิ่มเติมคุณสามารถอ่านประสบการณ์ของฉันได้ในบล็อกโพสต์ของฉัน: Spoiled for Choice: Integration Framework ใดที่จะใช้ - Spring Integration, Mule ESB หรือ Apache Camel


32

ผมได้ดำเนินการเมื่อเร็ว ๆ นี้อูฐเทียบกับฤดูใบไม้ผลิบูรณาการยิงออกมาโดยมีจุดประสงค์ที่จะบูรณาApache Kafka แม้จะเป็นนักพัฒนาฤดูใบไม้ผลิตัวยงผมเศร้าพบความสงสัยของฉันกับฤดูใบไม้ผลิที่เคยเติบโตแต็คโครงการได้รับการยืนยัน: ฤดูใบไม้ผลิเป็นที่น่ากลัวเป็น IOC-Container เพื่อทำหน้าที่เป็นกาวสำหรับกรอบอื่น ๆ แต่มันล้มเหลวที่จะให้ทางเลือกที่มีศักยภาพที่จะกรอบเหล่านั้น อาจมีข้อยกเว้นสำหรับสิ่งนี้กล่าวคือทุกสิ่งที่เกี่ยวข้องกับ MVC สปริงมาจากที่ใดและทำงานได้ดี แต่ความพยายามอื่น ๆ ในการจัดหาฟังก์ชันใหม่ที่อยู่ด้านบนของคุณสมบัติคอนเทนเนอร์นั้นขาดด้วยเหตุผลสามประการและกรณีการใช้งาน SI Kafkaยืนยัน ทั้งหมด:

  • การแนะนำ DSL ที่ยากต่อการใช้งานในระยะยาวสำหรับการกำหนดค่า XML
  • หน้าของโค้ดคอนฟิกูเรชัน xml เพื่อรับคอมโพเนนต์เฟรมเวิร์กทั้งหมดแบบต่อสาย
  • ทรัพยากรที่ขาดหายไปเพื่อมอบฟังก์ชันการทำงานที่เทียบเท่ากับเฟรมเวิร์กเฉพาะ

ตอนนี้กลับไปที่ผลของการยิงออกของฉัน: ที่สำคัญที่สุดผมประทับใจโดยแนวคิดโดยรวมอูฐของเส้นทางระหว่างปลายทาง Kafka ผสานรวมกับแนวคิดนี้ได้อย่างราบรื่นและการกำหนดค่าสามบรรทัดก็เพียงพอที่จะทำให้ทุกอย่างทำงานได้ ปัญหาที่พบในระหว่างกระบวนการได้รับการแก้ไขอย่างเรียบร้อยโดยเอกสารที่เพียงพอจากทีมโครงการรวมถึงคำถามมากมายเกี่ยวกับ Stackoverflow สุดท้าย แต่ไม่ท้ายสุดมีการผสมผสานที่ครอบคลุมในฤดูใบไม้ผลิที่ไม่ทิ้งความปรารถนาที่ไม่ได้รับความสำเร็จ

ในทางตรงกันข้าม SI เอกสารสำหรับการรวม Kafka ค่อนข้างเข้มข้นและยังไม่สามารถอธิบายได้อย่างชัดเจนว่าจะรวม Kafka อย่างไร บูรณาการของคาฟคาถูกกดลงไปใน SI-วิธีการทำสิ่งซึ่งจะเพิ่มความซับซ้อนเป็นพิเศษ เอกสารอื่น ๆ เช่นใน Stackoverflow ก็มีน้อยและมีประโยชน์น้อยกว่าสำหรับ Camel

ข้อสรุปของฉัน: Cobbler ยึดติดกับการค้าของคุณ - ใช้ Spring เป็นคอนเทนเนอร์และ Camel เป็นกรอบการรวมระบบ


3
ขอบคุณ Fritz สำหรับการแบ่งปันประสบการณ์ของคุณ! ฉันเห็นด้วยอย่างยิ่งกับข้อสังเกตของคุณ: อูฐสะอาดมากเกี่ยวกับแนวคิดพื้นฐานรวมทั้งการจัดหาระบบนิเวศของส่วนประกอบที่ทำงานได้สำหรับงานหลายอย่างในมือ (resp. อนุญาตให้เชื่อมต่อได้อย่างง่ายดายหากคุณต้องการปรับแต่งกิจวัตรเฉพาะ)
ngeek

17

จริงๆมันขึ้นอยู่กับสิ่งที่คุณต้องการจะทำ. หากคุณต้องการขยายบางสิ่งเพื่อสร้างโซลูชันการส่งข้อความของคุณเอง Spring Integration มีรูปแบบการเขียนโปรแกรมที่ดีกว่า หากคุณต้องการสิ่งที่รองรับโปรโตคอลจำนวนมากโดยไม่มีรหัสที่กำหนดเอง Camel ก็นำหน้า Spring Integration

การยิงสเกลเล็ก ๆ เป็นความคิดที่ดีมากแค่ตรวจสอบให้แน่ใจว่าคุณพยายามทำสิ่งต่างๆที่คุณมักจะทำในโครงการ

- ข้อจำกัดความรับผิดชอบ: ฉันเป็นผู้ให้คำมั่นสัญญา Spring Integration


9

การเปรียบเทียบ Camel และ SI ส่วนใหญ่ที่ฉันเคยเห็นไม่ได้คำนึงถึงสิ่งต่อไปนี้:

1. ) ผลกระทบที่ Spring Boot มีต่อผลผลิตของนักพัฒนาสำหรับ Spring Integration

2. ) ผลกระทบของ Spring XD มีต่อการทำให้แอปพลิเคชัน Spring Integration พร้อมใช้งานโดยไม่มีการคอมไพล์โค้ดนอกจากนี้แหล่งที่มา Spring XD และซิงก์ก็เป็นเพียงอะแดปเตอร์ช่อง Spring Integration เมื่อคุณต้องการขยาย Spring XD

3. ) ผลกระทบของ Spring XD มีต่อการรวม Spring Integration, Spring Batch, Spring Data (+ Hadoop!) ไว้ในสแต็กเดียวนำการประมวลผลแบบแบตช์และสตรีมอย่างมีประสิทธิภาพการสนับสนุน HDFS / Apache Hadoop และอื่น ๆ อีกมากมายใน Spring Integration

4. ) ผลกระทบของ Spring Integration 4.0 Java DSL ที่จะเปิดตัวเร็ว ๆ นี้https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

สำหรับการพิจารณาของคุณ,

/ Pieter (ข้อจำกัดความรับผิดชอบฉันทำงานที่ Pivotal)


3
Java DSL ต้องการงานจำนวนมากและเอกสารเพิ่มเติมก่อนที่จะนำมาพิจารณา
cuttcards

เข้าฉายได้สักพักแล้ว… spring.io/blog/2014/11/24/
Peter Szanto

6

เรากำลังใช้ Spring Integration สำหรับแอปพลิเคชันของเราและตอนนี้กำลังพิจารณาที่จะย้ายไปที่ Apache Camel เนื่องจากเราพบปัญหามากมายเกี่ยวกับ Spring Integration framework นี่คือสองประเด็น

  1. CachingConnectionFactory ซึ่ง Spring จัดเตรียมไว้เปิดการเชื่อมต่อที่ไม่ได้ใช้งาน 1,000 รายการใน IBM MQ และไม่มีการรับประกันว่าจะนำการเชื่อมต่อเหล่านี้กลับมาใช้ และการเชื่อมต่อเหล่านี้จะยังคงเปิดอยู่ตลอดไปซึ่งสร้างปัญหาในด้าน MQ ต้องรีสตาร์ทแอปพลิเคชันทุกสัปดาห์ในสภาพแวดล้อมที่ต่ำกว่าเพื่อรีเฟรชการเชื่อมต่อ Apache Camel ยังมี Caching และการเชื่อมต่อดูเหมือนว่าจะขึ้น / ลงตามโหลด

  2. Spring ไม่มีตัวทำแผนที่สำหรับพารามิเตอร์ QoS แม้ว่าคุณจะเปิดใช้งาน QoS โหมดการจัดส่งและคุณสมบัติการหมดอายุ / เวลาที่กำหนดจะหายไป (ฉันจะแจ้งปัญหา JIRA สำหรับสิ่งนี้) Apache Camel จัดการสิ่งนี้และพารามิเตอร์ QoS จะถูกส่งไปยังแอพพลิเคชั่นต้นน้ำและไม่ทิ้งมัน

ตอนนี้ฉันกำลังแก้ไขปัญหาเกี่ยวกับการจัดการข้อยกเว้นและธุรกรรมกับ Apache Camel ซึ่ง Spring ดูเหมือนจะจัดการกับ AOP ได้ดีกว่า


มีการกำหนดค่าผิดพลาดซึ่งนำไปสู่การเปิดการเชื่อมต่อที่ไม่ได้ใช้งานใน IBM MQ
Harpreet Sandhu - TheRootCoder

4

จริงๆแล้วฉันจะบอกว่า FTP ได้สิ้นสุดระยะฟักตัวแล้ว คุณสามารถค้นหาง่ายๆบนฟอรัม SI / JIRA เพื่อดูว่ามีการใช้งานฟีเจอร์ใหม่และจุดบกพร่องใดบ้างที่ได้รับการแก้ไข จากการพูดพล่อยต่างๆดูเหมือนว่าจะมีการใช้งานในการผลิตอยู่แล้วดังนั้นฉันขอแนะนำให้ลองดูครั้งที่สองและแน่นอนว่าจะแจ้งข้อกังวลของคุณให้เราทราบผ่านทาง

http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT

ไชโย Oleg

คำเตือน: ฉันเป็นผู้คอมมิชชัน Spring Integration


4

Apache Camel เป็นเฟรมเวิร์คที่ดีมากและก็สมบูรณ์มากเช่นกัน แต่ถ้าแอปพลิเคชันของคุณใช้สปริงคำแนะนำส่วนตัวของฉันคือใช้ Spring Integration

Spring Integration คือกรอบการร้องเรียน EIP แบบบูรณาการของ Spring-Source Ecosystem มีการผสมผสานที่ยอดเยี่ยมกับระบบนิเวศ: Spring boot, Batch, XD; แม้แต่แกนกลางก็ใช้นามธรรมเดียวกันโดยเริ่มจาก Spring Framework 4 นามธรรมการส่งข้อความบางส่วนก็ถูกย้ายไปอยู่ในเฟรมเวิร์กเพื่อพิสูจน์ว่าสิ่งที่เป็นนามธรรมพื้นฐานของ Spring Integration นั้นแข็งแกร่ง ตอนนี้ Spring framework เช่นใช้สิ่งที่เป็นนามธรรมสำหรับการส่งข้อความสำหรับ Spring Web ซึ่งรองรับเว็บซ็อกเก็ต

สิ่งที่ดีอีกอย่างในแอปพลิเคชัน Spring ที่มีการรวม Spring ในการใช้ Apache Camel คือด้วยการรวม Spring คุณสามารถใช้ Application Context ได้เพียงหนึ่งรายการ โปรดจำไว้ว่าบริบทของอูฐเป็นบริบทฤดูใบไม้ผลิ หากคุณมีโอกาสใช้ Spring เวอร์ชันใหม่ฉันขอแนะนำให้ใช้ Spring Integration Java DSL สำหรับการกำหนดค่า ฉันใช้มันในโปรเจ็กต์ใหม่ของฉันและรู้สึกว่าอ่านง่ายและชัดเจนมากขึ้น ฉันหวังว่าภาพสะท้อนนี้จะช่วยคุณในการประเมินของคุณ


1

เหตุผลหนึ่งในการใช้ Camel กับ Spring Integration คือเมื่อคุณต้องการชุด EIP ที่มีคุณสมบัติมากขึ้น Spring Integration ไม่ได้ให้ความเป็นนามธรรมเหนือสิ่งต่างๆเช่น ThreadPool

Camel มีโครงสร้างเพิ่มเติมสำหรับการทำให้บางส่วนของการทำงานกับโค้ดพร้อมกันง่ายขึ้น:

http://camel.apache.org/camel-23-threadpool-configuration.html

หากคุณไม่ต้องการสิ่งนี้และต้องการเพียงแค่เชื่อมต่อไฟล์, JMS, FTP endpoints และอื่น ๆ ... จากนั้นใช้ Spring Integration


2
คุณมีสิ่งที่เป็นนามธรรมมากกว่า ThreadPools ใน SI pollers และ task operation จาก Spring ไม่มีการกำหนดค่าล่วงหน้าสำหรับคุณ OOTB ใน SI ดูผู้บริหารงานการกำหนดค่าที่นี่: static.springsource.org/spring-integration/docs/2.1.x/reference/...
cwash

@ จอนคุณช่วยดูโพสต์ของฉันใน JMS ได้ไหม
ผู้เรียน

-1

อูฐทำหน้าที่เป็นมิดเดิลแวร์สำหรับแอปพลิเคชันที่สามารถทำการสร้างแบบจำลองข้อมูลการเปลี่ยนแปลงค่าข้อความและการออกแบบท่าเต้นของข้อความ


-3

หากแอปพลิเคชันปัจจุบันของคุณอยู่ใน Spring และต้องการคุณสมบัติที่รองรับโดย Spring Integration ของ EIP ดังนั้น Spring Integration จึงเป็นตัวเลือกที่ดีที่สุดที่ต้องการการสนับสนุนจากบุคคลที่สาม / โปรโตคอล / รูปแบบไฟล์ ฯลฯ


Camel รองรับสปริงได้ดีมากและครอบคลุมส่วนประกอบของบุคคลที่สามมากมาย
MikeHoss
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.