ข้อดีและข้อเสียของการมี WAR ที่แตกต่างกันสำหรับเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ และปรับใช้ในแอปพลิเคชันเซิร์ฟเวอร์ที่แตกต่างกัน

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

ข้อดีของการมีสงครามที่แตกต่างกัน: 1. ฉันรู้สึกว่าการมี WAR ที่แตกต่างกันสองรายการทำให้ฉันมีความยืดหยุ่นในการปรับโครงสร้าง UI หรือโค้ดฝั่งเซิร์ฟเวอร์ใหม่โดยไม่ส่งผลกระทบต่ออีกฝ่าย 2. เพื่อเพิ่มการใช้งานหน่วยความจำให้สูงสุด ฉันสามารถปรับใช้ในคอนเทนเนอร์ที่แตกต่างกันสองแห่ง ดังนั้นหากก่อนหน้านี้ฉันใช้ 2 GB สำหรับ jboss ทั้งหมด (บอกว่าฉันใช้ jboss) ตอนนี้ฉันสามารถใช้ 4 gb ได้หากปรับใช้ในเซิร์ฟเวอร์แอป jboss สองเซิร์ฟเวอร์ที่แตกต่างกัน (แน่นอนว่าหมายเลขพอร์ตต่างกัน) 3. ฉันสามารถปรับขนาดแอปพลิเคชันของฉันได้ หากพรุ่งนี้ ฉันเห็นว่าเซิร์ฟเวอร์นั้นเป็นคอขวดของฉัน ฉันสามารถสร้างเซิร์ฟเวอร์ฟาร์มได้ (สำหรับโมดูลเซิร์ฟเวอร์ของฉันเท่านั้น) เนื่องจากเซิร์ฟเวอร์นั้นเป็น WAR ที่แตกต่างออกไป โดยไม่ต้องกังวลกับ UI WAR 4. เชื่อมต่ออย่างหลวมๆ และให้คะแนนการบูรณาการต่างๆ แก่ฉัน

จุดด้อย: 1. สำหรับ UI ฉันใช้ไพรม์เฟซ ฉันไม่เห็นกรณีการใช้งานที่ฉันเห็นเฟรมเวิร์กการรวม เช่น การเพิ่มมูลค่าของตะเข็บ ใครช่วยบอกฉันได้ไหมว่าการมีกรอบการทำงานบูรณาการจะสมเหตุสมผลสำหรับสงคราม UI ของฉันหรือไม่ โดยพื้นฐานแล้ว ความสนุกทั้งหมดของตะเข็บคือการบูรณาการที่ยอดเยี่ยมที่มีให้กับ UI, EJB เหนือสิ่งอื่นใด ดังนั้นฉันจึงไม่เห็นคุณค่ามากเกินไปที่นี่ เพราะแบบฟอร์มของฉันจะขอให้ API ที่เหลือทำการประมวลผลทั้งหมด

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

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

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


person arya    schedule 01.06.2012    source แหล่งที่มา
comment
โอเค เราไม่มี EAR จริงๆ แล้ว มีแต่สงคราม   -  person arya    schedule 01.06.2012


คำตอบ (1)


หากคุณแบ็กเอนด์หากเป็นอิสระและคุณสื่อสารกับไคลเอนต์โดยใช้บริการเว็บ REST หรือ SOAP ก็ถือว่าดี ลองจินตนาการว่าพรุ่งนี้คุณทิ้งไคลเอนต์ของคุณด้วย java และสร้างไคลเอนต์อื่นด้วย .NET แบ็กเอนด์จำเป็นต้องเปลี่ยนแปลงบ้างไหม? ถ้าไม่-นี่เป็นสิ่งที่ดี ถ้าใช่ - ฉันคิดว่าคงไม่ถึงฝั่งที่จะมีสงคราม 2 ครั้ง

person alexey28    schedule 01.06.2012
comment
ใช่ แต่แล้วข้อดีล่ะ ฉันเห็นข้อดีมากมายของการมีสงครามสองครั้ง สิ่งที่ฉันต้องการเข้าใจคือไฟล์ EAR/WAR ไฟล์เดียวสามารถปรับขนาดได้อย่างไร ฉันไม่คิดว่าหากเลเยอร์ทั้งหมดเป็นแพ็กเกจใน WAR/EAR เดียว ก็สามารถปรับขนาดในแนวตั้งได้ ปรับขนาดแนวนอนได้เท่านั้นใช่ไหม? และฉันไม่เห็นว่าการปรับขนาดแนวนอนเป็นรูปแบบที่เหมาะสมที่สุดในการปรับขนาด - person arya; 01.06.2012
comment
ดูเหมือนว่าจะไม่ใช่การปรับขนาดแนวตั้ง แต่คุณปรับขนาดทั้งสององค์ประกอบในแนวนอนด้วยขนาดที่แตกต่างกันที่เป็นไปได้: คุณสามารถมี 3 fronends และ 20 backends เป็นต้น ในกรณีของสงครามเดี่ยว - 25 แบ็กเอนด์เพื่อให้เหมือนเดิม - person alexey28; 01.06.2012
comment
ใช่แล้ว alexey28 ดังนั้นการมี WAR หลายอันจึงเป็นทางเลือกที่ดีกว่าใช่ไหม และถ้าใช่แอปพลิเคชันที่มี WAR เดียวจะอ้างว่าสามารถปรับขนาดได้อย่างไรเนื่องจากแอปพลิเคชันส่วนใหญ่ (เรียกว่าปรับขนาดได้) ที่ฉันเห็นว่าถูกปรับใช้ในคอนเทนเนอร์เดียวเป็น WAR เดียว .... - person arya; 01.06.2012
comment
สามารถปรับขนาดได้สองวิธี: 1. โซลูชันของคุณเอง - คุณมีไคลเอ็นต์บางตัวที่ดำเนินการโหลดบาลานซ์และมีที่อยู่ของแบ็กเอนด์ที่ลงทะเบียนไว้ที่คลัสเตอร์ (สองสงคราม) 2. คุณใช้โซลูชันการทำคลัสเตอร์ที่มีอยู่: การสร้างคลัสเตอร์ของเซิร์ฟเวอร์แอป (ฉันคิดว่า Tomcat สามารถทำได้) และใช้คลัสเตอร์ของเซิร์ฟเวอร์ฐานข้อมูล ในกรณีนี้สามารถนำ NoSQL มาพิจารณาได้ แต่นี่เป็นโซลูชันที่มีความรับผิดชอบมากในการใช้ NoSQL (สงครามเดี่ยว) - person alexey28; 01.06.2012
comment
alexey29...ฉันขอโทษ ...ไม่เข้าใจมุมมองของคุณเกี่ยวกับ NoSQL คุณคิดว่าจะสามารถทดแทน RDBMS ได้ในกรณีใด จริงๆ แล้วฉันยังไม่คุ้นเคยกับแนวคิด NoSQL มากนัก... - person arya; 01.06.2012