Triển khai Hệ thống giải thưởng động

Question

Tôi đã phát triển Trò chơi Poker trực tuyến. Nhưng tôi cứ va vào tường. Tôi muốn thực hiện các giải thưởng vào hệ thống, nhưng tôi muốn chúng trở nên năng động. Có nghĩa là tôi không muốn biên dịch lại cho mọi giải thưởng mà tôi muốn thêm vào.

Tôi đã nghĩ đến việc sử dụng mã Python cho mỗi giải thưởng. Sau đó, khi máy chủ kiểm tra xem liệu người dùng có đủ điều kiện cho giải thưởng hay không, nó chạy tập lệnh python với Jython (máy chủ có trong Java và Netty NIO) và nếu hàm trả về một giá trị nào đó, tôi trao giải thưởng cho người dùng. Mà có thể làm việc nhưng có thể có một kỹ thuật hiệu quả hơn ra khỏi đó sẽ không buộc tôi phải chạy hàng trăm kịch bản python mỗi khi tôi cần phải kiểm tra xem một người dùng có một giải thưởng.

Và khi nào là thời điểm tốt nhất để thực hiện các kiểm tra này? Tôi đã suy nghĩ về một hệ thống móc, nơi tôi sẽ chỉ định các móc như ([onconnect] [ondisconnect] [chatmessage.received]). Mà cũng có thể làm việc nhưng cảm thấy một chút thô và tôi vẫn sẽ phải chạy tất cả các kịch bản từ cơ sở dữ liệu.

Answer 1

Nếu tôi là bạn, tôi sẽ có một quy trình hoàn toàn riêng biệt cấp giải thưởng. Nó chạy có lẽ một lần một ngày trên cơ sở dữ liệu nằm bên dưới chứa tất cả dữ liệu người chơi/trò chơi của bạn.

Ứng dụng khách hàng cốt lõi của bạn biết về giải thưởng, nhưng tất cả những gì họ biết về chúng là dữ liệu được tải từ DB - một cái gì đó như tiêu đề, hình ảnh, mô tả, có thể bao nhiêu người có giải thưởng, v.v. (dựa trên các bảng DB), người đã giành được giải thưởng.

Quy trình "giải thưởng" của bạn chỉ cần chạy ở chế độ hàng loạt, một lần mỗi ngày/giờ v.v., và cấp giải thưởng mới cho người chơi đủ điều kiện. Sau đó, ứng dụng cốt lõi đối mặt với khách hàng thông báo cho họ nhưng không thực sự phải biết những thông minh về cách cấp chúng. Điều này mang lại cho bạn sự tự do để biên dịch lại và chạy lại chương trình giải thưởng của bạn bất cứ khi nào bạn muốn mà không có tác động ứng dụng cốt lõi.

Cách tiếp cận khác, tùy thuộc vào mức độ hạn chế của giải thưởng của bạn, sẽ là viết giao diện quy tắc đơn giản cho phép bạn xác định quy tắc trong dữ liệu. Đó là lý tưởng để đạt được những gì bạn mô tả, nhưng đó là một chút công việc không có nhiều phần thưởng, theo ý kiến ​​của tôi.

PS - khi chạy một thứ như máy chủ poker trực tuyến, bạn sẽ luôn gặp phải các phiên bản của sự cố này. Bạn hoàn toàn cần phải phát triển một cách để triển khai mã mới mà không làm mất dịch vụ của bạn hoặc có một cửa sổ thời gian chết. Làm việc xung quanh một giải pháp mã java-centric cho giải thưởng sẽ không giải quyết vấn đề đó cho bạn trong thời gian dài. Bạn nên xem xét các tài liệu về việc chạy các dịch vụ 24/7 thực sự, có một vài cách để giải quyết vấn đề và nó thực sự không phải là khó khăn trong những ngày này.

Answer 2

Theo như tôi hiểu bạn, có thể bạn không phải chạy các quy trình bên ngoài từ ứng dụng của mình hoặc cũng không sử dụng OSGI. Chỉ cần tạo một giao diện Java đơn giản và triển khai từng plugin ('giải thưởng') như một lớp thực hiện giao diện. Sau đó bạn có thể chỉ cần biên dịch bất kỳ plugin mới nào và tải nó dưới dạng tệp lớp từ ứng dụng của bạn tại thời gian chạy bằng cách sử dụng Class.forName(String className). Bất kỳ logic nào bạn cần từ một plugin như vậy sẽ được chứa trong các phương thức trên giao diện.

http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Class.html#forName(java.lang.String)

Answer 3

Có một số lựa chọn tôi có thể nghĩ:

• OSGi như mô tả ở trên - nó đi kèm với một chi phí, nhưng có lẽ là giải pháp chung chung và năng động nhất trên mạng
• Nếu bạn mở để khởi động lại (không biên dịch lại), một bộ sưu tập các lọ trong một thư mục nổi tiếng và mùa xuân sẽ cung cấp cho bạn một giải pháp rẻ hơn nhưng không kém phần chung chung. Chỉ cần có đậu thưởng của bạn thực hiện một giao diện tiêu chuẩn, được đậu, và để cho con số mùa xuân @Autowire tất cả các giải thưởng có sẵn vào kiểm tra của bạn.
• Nếu bạn trao giải thực thi là khá chuẩn, và sự khác biệt duy nhất giữa các giải thưởng là chính quy tắc, bạn có thể có một số loại cấu hình theo kịch bản. Nhiều tùy chọn ở đó, từ python bạn mô tả (ngoại trừ tôi muốn đi cho một vài kịch bản lớn quản lý tất cả các giải thưởng), để biểu thức thông thường cơ bản, với LUA và Drools ở giữa. Trong mọi trường hợp, bạn đang xem xét một số loại quy tắc kiến ​​trúc động cơ, linh hoạt về những gì giải thưởng có thể kích hoạt nhưng không cung cấp tính linh hoạt cao về giải thưởng có thể dẫn đến (ví dụ: hoàn hảo cho thành tích).

Answer 4

Một số ý kiến ​​cho câu trả lời với những ý tưởng hàng loạt: Implementing a Dynamic Award System

Đó quá trình hàng loạt có thể trên máy chủ/máy riêng biệt, vì vậy bạn có thể biên dịch lại ứng dụng hoặc khởi động lại máy chủ bất cứ lúc nào. Có giải thưởng mới có thể được xử lý bằng cách sử dụng ví dụ cách tiếp cận được đề cập với việc thêm các lọ và khởi động lại máy chủ, cũng có thể thực hiện các tác vụ mới mẻ bất cứ lúc nào và cứ thế. Vì vậy, ứng dụng cốt lõi của bạn đang chạy 99% thời gian, máy chủ batch có thể được khởi động lại thường xuyên. Vì vậy, hàng loạt máy riêng biệt là tốt để có.

Khi bạn cần triển khai phiên bản ứng dụng cốt lõi mới, tôi nghĩ bạn chỉ có thể dừng, triển khai và bắt đầu với thông báo bảo trì cho người dùng. Cách tiếp cận đó được sử dụng ngay cả với các phòng chơi poker hàng đầu với phần mềm tuyệt vời (ví dụ: FullTiltPoker đã làm như vậy, ngay bây giờ nó bị hỏng do mất giấy phép, nhưng trang web của họ nói 'Cập nhật hệ thống' :)).

Do đó, một cách tiếp cận để cập nhật phiên bản là triển khai lại/khởi động lại sau giờ làm việc.

Một cách tiếp cận khác là cập nhật theo thời gian thực. Như một quy luật, nó được thực hiện bằng cách di chuyển người dùng theo từng nhóm sang phiên bản mới. Vì vậy, đồng thời một số người dùng đang sử dụng phiên bản cũ, một số mới. Không phải là khá mát mẻ cho phần mềm poker là người dùng với các phiên bản khác nhau có thể tương tác. Nhưng nếu bạn chắc chắn về khả năng tương thích của các phiên bản, bạn có thể đi theo cách tiếp cận đó, kiểm tra phiên bản máy khách của người dùng ví dụ khi đăng nhập.

Trong câu trả lời của tôi, tôi đã cố gắng nói rằng bạn không cần phải giới thiệu 24/7 hỗ trợ logic cho mã của bạn. Để lại các vấn đề sẵn có của hệ thống cho phần cứng (failovers, loadbalancers, vv). Bạn có thể làm theo bất kỳ kỹ thuật nào bạn đã sử dụng để viết mã, chỉ bạn cần nhớ rằng logic cốt lõi cốt lõi của bạn được triển khai không thường xuyên (ví dụ: mỗi tuần một lần) và phần lô có thể được cập nhật/khởi động lại bất cứ lúc nào nếu cần.