Ứng dụng web Java cho 5000 ~ Người dùng

Question

Lần đầu tiên (hy vọng không phải là cuối cùng) trong cuộc đời tôi sẽ phát triển một ứng dụng sẽ phải xử lý nhiều người dùng (khoảng 5000) và quản lý nhiều dữ liệu. Tôi đã phát triển một ứng dụng quản lý rất nhiều dữ liệu (khoảng 100 ~ GB dữ liệu, không quá nhiều theo tiêu chuẩn của bạn), nhưng số lượng người dùng khá thấp (khoảng 50).

Dưới đây là danh sách các công cụ/khuôn khổ Tôi nghĩ rằng tôi sẽ được sử dụng: Khung

• Vaadin UI
• Hibernate
• PostgreSQL
• Apache Tomcat
• memcached (để xử lý phiên)

Ứng dụng sẽ chủ yếu là b e chạy bên trong mạng công ty. Nó có thể được chạy trên một cụm máy chủ hay không, phụ thuộc vào số tiền mà công ty muốn chi tiêu để làm cho cuộc sống của nó dễ dàng hơn.

Vì vậy, bạn nghĩ gì về lựa chọn của tôi và tôi nên chú ý đến điều gì?

Chúc mừng

Answer 1

Câu trả lời, như với tất cả các vấn đề liên quan đến hiệu suất/mở rộng quy mô là: nó phụ thuộc.

Không có gì trong khuôn khổ lựa chọn của bạn sẽ khiến tôi nghĩ rằng nó sẽ không thể xử lý một lượng lớn người dùng. Nhưng mà không biết chính xác bạn muốn làm gì hoặc ngân sách của bạn là gì, không thể chọn một công nghệ.

Để đảm bảo rằng ứng dụng của bạn sẽ có quy mô/thực hiện, tôi sẽ xem xét những điều sau đây:

• Giữ bộ nhớ của mỗi phiên thấp. Ví dụ: các công cụ lưu trong bộ nhớ cache trong HttpSession có thể hoạt động khi bạn có 50, nhưng không phải là ý tưởng hay khi bạn có 5000 phiên.
• Thực hiện càng nhiều công việc càng tốt trong cơ sở dữ liệu để giảm lượng dữ liệu đang di chuyển xung quanh (ví dụ: khi xem bảng có nhiều hàng, đảm bảo rằng bạn đã phân trang được thực hiện trong cơ sở dữ liệu vì nhận được 10.000 hàng trở lại Tomcat và sau đó chọn đầu tiên 10 ...)
• Cố gắng hạn chế tối đa tình trạng mà đã được giữ bên trong HttpSession, điều này làm cho nó dễ dàng hơn để cluster.

có lẽ hầu hết các đề xuất quan trọng:

• Sử dụng tải testi ng công cụ để mô phỏng tải trọng cao điểm của bạn và vượt ra ngoài và kiểm tra. JMeter là công cụ tôi sử dụng để thực hiện/tải thử nghiệm.

Khi thử tải, đảm bảo:

• đó bạn thực sự sử dụng 5000 người dùng (do đó 5000 HttpSession s được tạo ra) và sử dụng một loạt các dữ liệu (để tránh luôn đánh bộ nhớ cache).

EDIT:

Tôi không nghĩ rằng 5000 người sử dụng không phải là nhiều và bạn có thể thấy rằng (hiệu suất-khôn ngoan), bạn chỉ cần một máy chủ duy nhất (phụ thuộc vào kích thước của máy chủ và kết quả của thử nghiệm tải, tất nhiên, và bạn có thể xem xét một giải pháp cụm cho failovers anyway ...) để xử lý tải (tức là không phải tất cả một trong 5000 người dùng của bạn sẽ được nhấn một nút đồng thời, bạn sẽ tìm thấy tải đi lên vào buổi sáng (tức là mọi người đều đăng nhập)

Answer 2

Tôi khuyên bạn nên dùng Glassfish cho máy chủ ứng dụng vì Apache Tomcat có thể cung cấp nội dung đơn giản. Và Glassfish đã thực hiện đầy đủ đặc tả Java EE.

Answer 3

Bạn có thể muốn xem xét một máy chủ Apache HTTP ở phía trước các máy chủ Tomcat của bạn Apache sẽ cung cấp: nén, bộ nhớ đệm tĩnh, cân bằng tải và SSL.

Answer 4

Vì bạn đã yêu cầu mọi người cân nhắc, tôi sẽ không giữ lại ý kiến ​​của mình. ORM nói chung, và Hibernate nói riêng, là một anti-pattern. Tôi biết, tôi đã làm việc trong các cửa hàng sử dụng Hibernate trong 9 năm qua. Biết những gì tôi biết bây giờ, tôi sẽ không bao giờ sử dụng nó một lần nữa.

tôi khuyên bạn nên bài viết trên blog này, vì nó đặt nó một cách ngắn gọn hơn tôi có thể:

ORM is an anti-pattern

Nhưng tha thứ cho tôi nếu tôi trích dẫn các bit từ đó blog về ORMs và chống mẫu:

lý do tôi gọi ORM một mô hình chống là bởi vì nó phù hợp với hai tiêu chí tác giả của AntiPatterns sử dụng để phân biệt chống mẫu từ thói quen chỉ xấu, cụ thể:

• Nó ban đầu dường như là có lợi, nhưng về lâu dài có nhiều hậu quả xấu hơn những người tốt
• Một giải pháp thay thế tồn tại mà được chứng minh và có thể lặp lại

lựa chọn công nghệ khác của bạn dường như khỏe. Cá nhân, tôi nghiêng về phía Jetty hơn Tomcat. Có một lý do mà Google nhúng nó vào rất nhiều dự án của họ (nghĩ GWT và PlayN); đó là một mã số trẻ hơn và tôi nghĩ rằng tích cực hơn được phát triển ngay bây giờ mà Eclipse đã thực hiện nó. Chỉ là ý kiến ​​khiêm nhường của tôi.

[CẬP NHẬT] Một liên kết khác, đọc rất dài nhưng khi đưa ra quyết định về kiến ​​trúc, việc đọc là tốt.

Object/Relational Mapping: The Vietnam of Computer Science

Answer 5

Bất kỳ lý do để không sử dụng Spring? Nó đã thực sự trở thành một tiêu chuẩn de-facto trong các ứng dụng java doanh nghiệp.

Mùa xuân cung cấp bộ sưu tập công nghệ cực kỳ mạnh mẽ và linh hoạt để cải thiện phát triển ứng dụng Java dành cho doanh nghiệp của bạn được hàng triệu nhà phát triển sử dụng.

Mùa xuân có trọng lượng nhẹ và có thể ở dạng lớp trung lưu, kết nối giữa vaadin và ngủ đông, ở đó bằng cách tạo ra sự tách lớp sạch. Việc quản lý giao dịch mùa xuân cũng cao hơn so với một ngày ngủ đông. Tôi sẽ đề nghị bạn đi cho đến khi bạn có lý do chính đáng để ngăn bạn.

Answer 6

Tùy thuộc vào đặc điểm kỹ thuật của bạn và mục tiêu trong tương lai tôi có lẽ sẽ rời khỏi phiên bản bình thường của tomcat và đi cho Apache TomEE hoặc sở thích cá nhân của tôi về jBoss. Theo tôi hiểu nó EJB không được hỗ trợ rất tốt trong phiên bản tomcat bình thường và đó là probalby một cái gì đó ngọt ngào để có khi bạn muốn tạo ra một vài dịch vụ, một số dịch vụ singleton cụm và các công cụ khác. Nhưng đây chỉ là pref cá nhân của tôi tất nhiên và nếu đặc điểm kỹ thuật của bạn sẽ không cho phép một máy chủ EE tiên tiến hơn thì bạn nên dính với tomcat trơn.