Tôi có thể điều chỉnh các yêu cầu được tạo bởi ứng dụng được phân phối không?

Question

Ứng dụng của tôi yêu cầu Dịch vụ web; có một tỷ lệ tối đa các yêu cầu mà nhà cung cấp sẽ xử lý, vì vậy tôi cần phải điều chỉnh chúng.

Khi ứng dụng chạy trên một máy chủ, tôi đã sử dụng nó ở cấp ứng dụng: một đối tượng theo dõi số lượng yêu cầu đã được thực hiện cho đến nay và đợi yêu cầu hiện tại vượt quá mức tối đa cho phép tải.

Bây giờ, chúng tôi đang di chuyển từ một máy chủ đơn lẻ sang một cụm, do đó, có hai bản sao của ứng dụng đang chạy.

• Tôi không thể tiếp tục kiểm tra tải trọng tối đa tại mã ứng dụng vì hai nút được kết hợp có thể vượt quá tải cho phép.
• Tôi không thể đơn giản giảm tải trên mỗi máy chủ, bởi vì nếu nút kia không hoạt động, nút đầu tiên có thể gửi nhiều yêu cầu hơn.

Đây là môi trường JavaEE 5. Cách tốt nhất để điều tiết các yêu cầu mà ứng dụng gửi đi là gì?

Answer 1

Vì bạn đã ở trong môi trường Java EE, bạn có thể tạo MDB xử lý tất cả các yêu cầu tới webservice dựa trên hàng đợi JMS. Các cá thể của ứng dụng có thể chỉ cần gửi các yêu cầu của chúng tới hàng đợi và MDB sẽ nhận chúng và gọi dịch vụ webservice.

Hàng đợi thực sự có thể được định cấu hình với số phiên thích hợp sẽ giới hạn quyền truy cập đồng thời vào dịch vụ web của bạn, do đó việc điều chỉnh của bạn được xử lý thông qua cấu hình hàng đợi.

Kết quả có thể được trả lại qua hàng đợi khác (hoặc thậm chí là hàng đợi cho mỗi trường hợp ứng dụng).

Answer 2

Nhiều cách để thực hiện việc này: bạn có thể có "Đại lý điều phối" chịu trách nhiệm giao "mã thông báo" cho máy chủ. Mỗi "mã thông báo" đại diện cho một quyền để thực hiện một nhiệm vụ vv Mỗi ứng dụng cần phải yêu cầu "mã thông báo" để thực hiện cuộc gọi.

Sau khi ứng dụng làm cạn kiệt mã thông báo, nó phải yêu cầu thêm một số trước khi tiếp tục nhấn lại vào Dịch vụ web.

Tất nhiên, điều này tất cả trở nên phức tạp khi có các yêu cầu liên quan đến thời gian của mỗi cuộc gọi mà mỗi ứng dụng thực hiện do đồng thời đối với Dịch vụ Web.

Bạn có thể dựa trên RabbitMQ làm khung tin nhắn: Có sẵn các liên kết Java.

Answer 3

N nút cần giao tiếp. Có nhiều chiến lược khác nhau:

• phát sóng: mỗi nút sẽ phát cho mọi người biết rằng nó đang gọi cuộc gọi và tất cả các nút khác sẽ tính đến. Các nút bằng nhau và duy trì số đếm toàn cầu của mỗi cá thể (mỗi nút biết về cuộc gọi của mỗi nút khác).
• nút chính: một nút là đặc biệt, nút chính và tất cả các nút khác yêu cầu sự cho phép của chủ trước khi thực hiện cuộc gọi. Thầy là người duy nhất biết số lượng toàn cầu.
• chuyên dụng chính: giống như chính, nhưng 'chủ' không thực hiện cuộc gọi trên itslef, chỉ là một dịch vụ theo dõi cuộc gọi.

Tùy thuộc vào mức độ dự đoán của bạn sau này, một hoặc chiến lược khác có thể là tốt nhất. Đối với 2 nút, cách đơn giản nhất là phát sóng, nhưng khi số lượng nút tăng các vấn đề bắt đầu gắn kết (bạn sẽ dành nhiều thời gian hơn để phát sóng và trả lời các broadcats hơn là thực hiện các yêu cầu WS).

Cách các nút giao tiếp, tùy thuộc vào bạn. Bạn có thể mở một đường ống TCP, bạn có thể mở rộng UDP, bạn có thể làm một WS hoàn toàn chính thức cho mục đích này một mình, bạn có thể sử dụng một giao thức chia sẻ tập tin. Dù bạn làm gì, bây giờ bạn không còn ở trong một quá trình để tất cả các ứng dụng fallacies of distributed computing được áp dụng.

Answer 4

Đây là một vấn đề thú vị và độ khó của giải pháp phụ thuộc vào mức độ nghiêm ngặt bạn muốn điều chỉnh.

Giải pháp thông thường của tôi là JBossCache, một phần vì nó được đóng gói với JBoss AppServer, nhưng cũng vì nó xử lý công việc khá tốt. Bạn có thể sử dụng nó như một loại hashmap được phân phối, ghi lại số liệu thống kê sử dụng ở các mức chi tiết khác nhau. Các cập nhật cho nó có thể được thực hiện không đồng bộ, vì vậy nó không làm chậm mọi thứ.

JBossCache thường được sử dụng cho bộ nhớ đệm phân phối nặng, nhưng tôi cũng thích nó cho những công việc có trọng lượng nhẹ hơn. Đó là java thuần túy, và không cần mucking về với JVM (không giống như Terracotta).

Answer 5

Tôi khuyên bạn nên sử dụng beanstalkd để định kỳ bơm một tập hợp các yêu cầu (công việc) vào một ống (hàng đợi), mỗi ống có độ trễ thích hợp. Bất kỳ số lượng chủ đề hoặc quy trình "công nhân" nào sẽ chờ yêu cầu tiếp theo khả dụng và nếu nhân viên kết thúc sớm, họ có thể nhận yêu cầu tiếp theo. Mặt trái là không có cân bằng tải rõ ràng giữa các công nhân, nhưng tôi thấy rằng việc phân phối các yêu cầu trong hàng đợi đã được cân bằng tốt.

Answer 6

Hystrix được thiết kế cho khá nhiều kịch bản chính xác mà bạn mô tả. Bạn có thể xác định kích thước nhóm luồng cho mỗi dịch vụ để bạn có số yêu cầu đồng thời tối đa được đặt và nó xếp hàng đợi các yêu cầu khi hồ bơi đầy. Bạn cũng có thể xác định thời gian chờ cho mỗi dịch vụ và khi một dịch vụ bắt đầu vượt quá thời gian chờ của nó, Hystrix sẽ từ chối các yêu cầu thêm cho dịch vụ đó trong một khoảng thời gian ngắn để cho dịch vụ có cơ hội quay trở lại. Ngoài ra còn có giám sát thời gian thực của toàn bộ cụm thông qua Turbine.