Triển khai hiệu quả nhiều phiên bản của cùng một WAR (các ngữ cảnh khác nhau, cùng một vùng chứa)

Question

Tôi có một WAR (app.war) và một thùng chứa (Tomcat, Jetty, Glassfish, bất kỳ thứ gì). Mục tiêu của tôi là triển khai, theo yêu cầu, hàng trăm trường hợp của cùng một ứng dụng web này trên vùng chứa.

http://foo/app1 --> app.war 
http://foo/app2 --> app.war 
http://foo/app3 --> app.war 
... 
http://foo/appN --> app.war 

Một số cách rõ ràng để đạt được điều này:

• Trong Tomcat, tạo một file context.xml cho mỗi ứng dụng (tên appN.xml), tất cả chỉ vào WAR cùng. thùng đựng khác nhau có phương pháp tương tự
  • Vấn đề với cách tiếp cận này: Nó sẽ nổ thời WAR N, chiếm rất nhiều không gian đĩa
• Sử dụng liên kết tượng trưng để tạo webapp/{app1, app2, APPN} thư mục chỉ vào một phiên bản phát nổ của app.war. Điều này ngăn chặn sự bùng nổ không gian đĩa, nhưng JVM vẫn tải nhiều JAR trùng lặp vào bộ nhớ
• Sử dụng một số thư mục lib được chia sẻ để chứa hầu hết các lọ (và kết hợp hai tùy chọn trước).

Tôi tự hỏi nếu có phương pháp tốt hơn để thực hiện việc này. Lý tưởng nhất, việc tạo một cá thể mới sẽ không chiếm bất kỳ không gian đĩa nào (ngoài các tệp cấu hình cận biên) và chỉ chiếm bộ nhớ liên quan đến các ngăn xếp thực thi luồng và các phân bổ thời gian chạy khác.

Bất kỳ ý tưởng nào?

Answer 1

Hỗ trợ thêm cho những gì bạn tìm kiếm một thời gian trở lại với những gì được gọi là lớp phủ.

http://wiki.eclipse.org/Jetty/Tutorial/Configuring_the_Jetty_Overlay_Deployer

Sao chép một chút từ trang wiki:

• Bạn có thể giữ các tập tin WAR bất biến, thậm chí có chữ ký, do đó nó là rõ ràng phiên bản bạn đã được triển khai.
• Mọi sửa đổi bạn thực hiện để tùy chỉnh/định cấu hình ứng dụng web đều là các WAR riêng biệt và do đó dễ nhận biết để xem xét và di chuyển sang các phiên bản mới.
• Bạn có thể tạo lớp phủ mẫu được tham số chứa các tùy chỉnh và cấu hình chung áp dụng cho nhiều phiên bản của ứng dụng web (ví dụ: để triển khai nhiều người thuê).
• Do triển khai phân lớp xác định rõ ràng các thành phần cụ thể và phổ biến, Jetty có thể chia sẻ trình nạp lớp và bộ đệm tài nguyên tĩnh cho mẫu, giảm đáng kể dung lượng bộ nhớ của nhiều phiên bản.

Answer 2

Bạn có thể định cấu hình Apache trên giao diện người dùng (mod_proxy/mod_proxy_ajp) để trỏ các máy chủ ảo có tên tới một WAR duy nhất được triển khai trên Tomcat. Ứng dụng của bạn phải được thiết kế/viết theo cách để phục vụ tất cả yêu cầu - theo cấu hình cụ thể của từng trang web có thể được lưu trữ trong cơ sở dữ liệu hoặc dưới dạng tệp cấu hình trong ứng dụng của bạn - ứng dụng của bạn sẽ chỉ cần thăm dò tên miền yêu cầu của người dùng đảm bảo cài đặt chính xác được áp dụng (một lần cho mỗi phiên). Nói chung, bạn sẽ có thể giải quyết vấn đề này với một ứng dụng. Các nhà phát triển tuyệt vời là LAZY.

Answer 3

Nếu đây là một thử nghiệm thì bất kỳ phương pháp nào bạn liệt kê đều có thể hoạt động.

Nếu đây là sản phẩm thì tôi khuyên bạn nên chống lại điều này. Trong khi tôi đã không thử nghiệm TẤT CẢ các container, các container tôi đã sử dụng dẫn tôi để được tin rằng nó là nhiều hơn nữa đàn hồi để chỉ đơn giản là cung cấp máy ảo không đầu với container. Máy ảo Linux có thể rất nhỏ và với công nghệ VM, bạn có thể thêm hoặc trừ nhiều trường hợp khi cần.

Nếu bạn thực sự muốn có một giải pháp phát triển động thì bạn nên xem xét để loại bỏ các điểm lỗi duy nhất thay vì sau đó cố gắng gộp toàn bộ thế giới của bạn thành một.

Nếu bạn thực sự cần "tăng/giảm tải" thứ hai thì bạn nên xem AWS hoặc CloundFoundry.

Answer 4

Nếu bạn đang sử dụng Jetty, bạn có thể thêm ngữ cảnh theo chương trình.

WebAppContext webapp = new WebAppContext(); 
webapp.setBaseResource(myBaseDirectory); 
webapp.setContextPath(myContextPath); 

Chỉ cần làm điều này trong vòng lặp cho tất cả các ngữ cảnh của bạn. Nó phải có gần bằng không trên không.

Có thể có cách tương tự để thực hiện điều đó trong Tomcat.

Answer 5

Xin lỗi vì có chút ít chủ đề, nhưng theo quan điểm của tôi, kịch bản của bạn phát ra ứng dụng "đa bên thuê" để bạn có một ứng dụng duy nhất sẽ phục vụ nhiều "người thuê" (khách hàng).

liên quan đến các thiết lập multi-tenancy Với, những yếu tố sau sẽ phải được xem xét:

• Khách hàng không thể truy cập dữ liệu của nhau (nếu họ các dữ liệu được lưu trữ trong cơ sở dữ liệu tương tự, cùng một lược đồ và sử dụng " phân biệt đối xử "trường để tách dữ liệu). Điều này có thể đạt được bằng cách sử dụng Bảo mật mùa xuân với Access Control Lists
• Hibernate đã tích hợp sẵn support for multitenancy apps từ phiên bản 4.0.
• Hai SO câu hỏi có thể hữu ích cũng
  • Multiple Entity Manager issue in Spring when using more than one datasource (cho việc sử dụng các nguồn dữ liệu khác nhau (cơ sở dữ liệu khác nhau hoặc lược đồ chỉ khác nhau trên cơ sở dữ liệu tương tự cho mỗi khách hàng).
  • Multi tenancy support in Java EE 6

Lợi ích của đa nhiệm:

• Mã chia sẻ có nghĩa là một lỗi cố định cho một khách hàng là cố định cho tất cả (điều này cũng có thể là một bất lợi nếu các khách hàng khác nhau có quan điểm khác nhau về những gì cấu thành một lỗi và những gì cấu thành một tính năng).
• Triển khai theo cụm có thể chia sẻ tải giữa khách hàng (tuy nhiên, cần đảm bảo rằng dung lượng tối đa khả dụng cho tất cả khách hàng).

Nhược điểm:

• Mã sẽ là một chút phức tạp hơn như các truy vấn cần phải đảm bảo rằng "phân biệt đối xử" giữa khách hàng hoạt động mà không vô tình để lộ khách hàng để mỗi dữ liệu khác.