คำแนะนำในการปรับใช้ไฟล์ war เทียบกับ jar ที่ปฏิบัติการได้ด้วยคอนเทนเนอร์แบบฝัง


89

ดูเหมือนว่าจะมีแนวโน้มในปัจจุบันในพื้นที่จาวาที่จะย้ายออกจากการปรับใช้เว็บแอปพลิเคชัน java ไปยังคอนเทนเนอร์ java servlet (หรือแอปพลิเคชันเซิร์ฟเวอร์) ในรูปแบบไฟล์ war (หรือไฟล์ ear) และแทนที่แอปพลิเคชันเป็น jar ปฏิบัติการด้วย เซิร์ฟเวอร์ servlet / HTTP ที่ฝังตัวเช่นท่าเทียบเรือ และฉันหมายถึงสิ่งนี้มากกว่านั้นในวิธีที่เฟรมเวิร์กรุ่นใหม่มีอิทธิพลต่อวิธีการพัฒนาและปรับใช้แอปพลิเคชันใหม่มากกว่าการส่งมอบแอปพลิเคชันไปยังผู้ใช้ปลายทาง (เพราะตัวอย่างเช่นฉันเข้าใจว่าทำไมเจนกินส์ถึงใช้คอนเทนเนอร์แบบฝังตัวง่ายมากในการหยิบจับ ). ตัวอย่างของเฟรมเวิร์กที่ใช้อ็อพชัน jar ที่เรียกใช้งานได้: Dropwizard , Spring BootและPlay (มันไม่ได้ทำงานบนคอนเทนเนอร์ servlet แต่เซิร์ฟเวอร์ HTTP ถูกฝังอยู่)

คำถามของฉันคือมาจากสภาพแวดล้อมที่เราได้ปรับใช้แอปพลิเคชัน (จนถึงจุดนี้ส่วนใหญ่เป็น Struts2) กับแอปพลิเคชันเซิร์ฟเวอร์ Tomcat เดียวต้องมีการเปลี่ยนแปลงแนวทางปฏิบัติที่ดีที่สุดหรือข้อควรพิจารณาอะไรบ้างหากเราวางแผนที่จะใช้แนวทางคอนเทนเนอร์แบบฝัง เหรอ? ขณะนี้เรามีแอปพลิเคชันพื้นบ้านประมาณ 10 รายการที่ทำงานบนเซิร์ฟเวอร์ Tomcat ตัวเดียวและสำหรับแอปพลิเคชันขนาดเล็กเหล่านี้ความสามารถในการแบ่งปันทรัพยากรและจัดการบนเซิร์ฟเวอร์เดียวนั้นดี แอปพลิเคชันของเราไม่ได้มีวัตถุประสงค์เพื่อแจกจ่ายให้กับผู้ใช้ปลายทางเพื่อให้ทำงานภายในสภาพแวดล้อมของพวกเขา อย่างไรก็ตามหากเราตัดสินใจที่จะใช้ประโยชน์จาก java framework ที่ใหม่กว่าแนวทางนี้ควรเปลี่ยนไปหรือไม่? การเปลี่ยนไปใช้ขวดปฏิบัติการได้เกิดขึ้นจากการใช้งานระบบคลาวด์ที่เพิ่มขึ้น (เช่น Heroku) หรือไม่

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

คำตอบ:


82

คำถามที่น่าสนใจ นี่เป็นเพียงมุมมองของฉันในหัวข้อนี้ดังนั้นควรใช้เกลือเม็ดหนึ่งเม็ด ฉันได้ปรับใช้และจัดการแอปพลิเคชันเป็นครั้งคราวโดยใช้ทั้งคอนเทนเนอร์ servlet และเซิร์ฟเวอร์แบบฝัง ฉันแน่ใจว่ายังมีเหตุผลที่ดีอีกมากมายในการใช้คอนเทนเนอร์ servlet แต่ฉันจะพยายามเน้นว่าทำไมพวกเขาถึงได้รับความนิยมน้อยลงในปัจจุบัน

เวอร์ชันสั้น: คอนเทนเนอร์ Servlet นั้นยอดเยี่ยมในการจัดการแอปพลิเคชันหลายตัวบนโฮสต์เดียว แต่ดูเหมือนจะไม่มีประโยชน์มากนักในการจัดการแอปพลิเคชันเดียว ด้วยสภาพแวดล้อมระบบคลาวด์แอปพลิเคชันเดียวต่อเครื่องเสมือนดูเหมือนจะดีกว่าและเป็นเรื่องธรรมดามากขึ้น เฟรมเวิร์กสมัยใหม่ต้องการให้เข้ากันได้กับระบบคลาวด์ดังนั้นจึงเปลี่ยนไปใช้เซิร์ฟเวอร์แบบฝังตัว


ดังนั้นฉันคิดว่าบริการคลาวด์เป็นสาเหตุหลักในการละทิ้งคอนเทนเนอร์ servlet เช่นเดียวกับคอนเทนเนอร์ servlet ให้คุณจัดการแอปพลิเคชันบริการคลาวด์ช่วยให้คุณจัดการเครื่องเสมือนอินสแตนซ์ที่เก็บข้อมูลและอื่น ๆ อีกมากมาย ฟังดูซับซ้อนกว่า แต่ด้วยสภาพแวดล้อมระบบคลาวด์ทำให้มีการเปลี่ยนไปใช้เครื่องแอปเดียว ซึ่งหมายความว่าคุณมักจะสามารถรักษาเครื่องทั้งหมดเหมือนเป็นแอพลิเคชัน แต่ละแอปพลิเคชันทำงานบนเครื่องที่มีขนาดเหมาะสม อินสแตนซ์ระบบคลาวด์สามารถปรากฏขึ้นและหายไปได้ตลอดเวลาซึ่งเหมาะสำหรับการปรับขนาด หากแอปพลิเคชันต้องการทรัพยากรเพิ่มเติมคุณจะต้องสร้างอินสแตนซ์เพิ่มเติม

ในทางกลับกันเซิร์ฟเวอร์เฉพาะจะมีประสิทธิภาพ แต่มีขนาดคงที่ดังนั้นคุณจึงเรียกใช้หลายแอปพลิเคชันบนเครื่องเดียวเพื่อเพิ่มการใช้ทรัพยากรให้สูงสุด การจัดการแอปพลิเคชันหลายสิบแอปพลิเคชันแต่ละรายการมีการกำหนดค่าเว็บเซิร์ฟเวอร์เส้นทางและการเชื่อมต่ออื่น ๆ เป็นของตัวเองไม่ใช่เรื่องสนุกดังนั้นการใช้คอนเทนเนอร์ servlet จึงช่วยให้คุณจัดการทุกอย่างได้และมีสติ มันยากกว่าที่จะปรับขนาด Servlet container ในระบบคลาวด์ดูเหมือนจะไม่มีประโยชน์มากนัก พวกเขาจะต้องตั้งค่าสำหรับแต่ละอินสแตนซ์เล็ก ๆ โดยไม่ต้องให้คุณค่ามากนักเนื่องจากพวกเขาจัดการแอปพลิเคชันเดียว

นอกจากนี้เมฆยังเย็นสบายและสิ่งที่ไม่ใช่เมฆก็น่าเบื่อ (ถ้าเรายังเชื่อว่าโฆษณา) เฟรมเวิร์กจำนวนมากพยายามที่จะปรับขนาดได้ตามค่าเริ่มต้นเพื่อให้สามารถปรับใช้กับระบบคลาวด์ได้อย่างง่ายดาย เซิร์ฟเวอร์ในตัวสามารถปรับใช้และรันได้อย่างรวดเร็วดังนั้นจึงดูเหมือนเป็นโซลูชันที่สมเหตุสมผล โดยปกติแล้ว Servlet container จะยังคงรองรับ แต่ต้องการการตั้งค่าที่ซับซ้อนมากขึ้น

จุดอื่น ๆ :

  • เซิร์ฟเวอร์แบบฝังสามารถปรับให้เหมาะสมสำหรับเฟรมเวิร์กหรือรวมเข้ากับเครื่องมือเฟรมเวิร์กได้ดีขึ้น (เช่น play console เป็นต้น)
  • สภาพแวดล้อมระบบคลาวด์บางประเภทไม่ได้มาพร้อมกับอิมเมจเครื่องที่ปรับแต่งได้ แทนที่จะเขียนสคริปต์การเริ่มต้นเพื่อดาวน์โหลดและตั้งค่าคอนเทนเนอร์ servlet การใช้ซอฟต์แวร์เฉพาะสำหรับการปรับใช้แอปพลิเคชันระบบคลาวด์นั้นง่ายกว่ามาก
  • ฉันยังไม่พบการตั้งค่า Tomcat ที่ไม่ได้ต้อนรับคุณด้วยข้อผิดพลาดเกี่ยวกับพื้นที่อนุญาตทุก ๆ การปรับใช้แอปของคุณอีกสองสามครั้ง การใช้เวลา (อีกครั้ง) ในการเริ่มต้นเซิร์ฟเวอร์แบบฝังตัวนานขึ้นเล็กน้อยก็ไม่มีปัญหาเมื่อคุณสามารถสลับระหว่างอินสแตนซ์การแสดงและการใช้งานจริงได้เกือบจะทันทีโดยไม่ต้องหยุดทำงาน
  • ดังที่ได้กล่าวไปแล้วในคำถามนี้สะดวกมากสำหรับผู้ใช้เพียงแค่เรียกใช้แอปพลิเคชัน
  • เซิร์ฟเวอร์แบบฝังเป็นแบบพกพาและสะดวกสำหรับการพัฒนา ทุกวันนี้ทุกอย่างดำเนินไปอย่างรวดเร็วต้องมีการสร้างและส่งมอบต้นแบบและ MVP ให้เร็วที่สุด ไม่มีใครต้องการใช้เวลามากเกินไปในการจัดสภาพแวดล้อมสำหรับนักพัฒนาทุกคน

1
ขอบคุณสำหรับคำตอบคุณให้คะแนนที่ดี คลาวด์เป็นปัจจัยผลักดัน! ในสถานการณ์ของเราฉันรู้สึกสบายใจมากขึ้นในการเป็นเจ้าของเซิร์ฟเวอร์คลาวด์และโมเดล Amazon Web Services (โครงสร้างพื้นฐานเป็นบริการ) ซึ่งต่างจากการปรับใช้เพียงแอปพลิเคชัน a la Google App Engine (Platform as a Service) แต่ฉันคิดว่านี่คือ โรงเรียนเก่าแห่งความคิด ดังนั้นสิ่งที่ควรหลีกเลี่ยง: เว้นแต่เราจะวางแผนที่จะใช้ประโยชน์จากระบบคลาวด์ในแพลตฟอร์มเป็นวิธีการบริการการปรับใช้สงครามเป็นหนทางที่จะดำเนินต่อไปแทนที่จะจัดการกับเว็บแอปพลิเคชัน Java แบบสแตนด์อโลนหลายรายการบนเซิร์ฟเวอร์เครื่องเดียว ขอขอบคุณอีกครั้งสำหรับข้อมูลของคุณ
Brice Roncace

3
เพียง 2cc: คุณสามารถเรียกใช้แอป jarหลายตัวบนเครื่องเดียวโดยมีเซิร์ฟเวอร์ HTTP แบบเบาเป็นพร็อกซีเช่น nginx สามารถใช้เพิ่มเติมสำหรับการรับส่งข้อมูลเว็บทั่วไปเช่น CDN แบบกำหนดเองตัวโหลดบาลานเซอร์ไฟร์วอลล์และอื่น ๆ ดังนั้นจึงสมเหตุสมผลที่จะพิจารณา โดยใช้เมื่อวางแผนการเข้าชมจำนวนมาก (มีประสิทธิภาพที่ดีกว่าจากนั้นจึงจัดการทุกคำขอเดียว - แม้แต่ทรัพยากรแบบคงที่ผ่านแอปหลักของคุณ
biesior
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.