Thiết kế hiệu quả cho ứng dụng di động làm mới tự động

Question

Tôi đã được trình bày vấn đề này vài ngày trước. Yêu cầu là thiết kế một ứng dụng dành cho thiết bị di động phục vụ nội dung thể thao cho người dùng (nói bóng đá). Ứng dụng sẽ cho phép người dùng đăng ký vào nhóm cụ thể. Dựa trên lựa chọn nhóm của người dùng, các ứng dụng chỉ phục vụ nội dung liên quan đến nhóm đó trên màn hình chính của người dùng. Tất nhiên người dùng có tùy chọn xem nội dung cho tất cả các đội (thông qua các tùy chọn menu).

Đặc biệt tập trung vào nội dung trên màn hình chính của người dùng sẽ được làm mới tự động và cũng nên cân nhắc rằng người dùng đã (hoặc chưa) đăng ký một nhóm cụ thể.

Để câu hỏi cuối cùng, tôi đã gợi ý sau đây 2 giải pháp:

1) Ứng dụng có thể gửi các yêu cầu nhỏ đến máy chủ đó sẽ chỉ chứa định danh của người dùng, lựa chọn đội của người dùng. Dựa trên lựa chọn nhóm trong yêu cầu đầu vào, máy chủ sẽ chỉ trả lại nội dung liên quan đến nhóm.

2) Nếu khối lượng nội dung ít hơn và số lượng nhóm khác nhau ít thì phát tất cả thông tin và để ứng dụng thực hiện lọc cần thiết (tất nhiên điều này kém hiệu quả hơn so với # 1).

Chia sẻ điều này trên diễn đàn để nhận các quyết định thiết kế khác có thể có. Trong trường hợp đây không phải là diễn đàn phù hợp, vui lòng trả lời trong phần bình luận và tôi sẽ đăng lên diễn đàn thích hợp.

Cảm ơn

Answer 1

Tùy chọn chắc chắn 1).

Chúng tôi đã phát triển điều gì đó tương tự trong ngành khác, nơi người dùng quan tâm đến việc nhận thông tin về các trạng thái của các tài nguyên khác nhau. Kiến trúc giống như sau:

1. Máy chủ giữ tất cả đăng ký của người dùng. Đó là nơi bạn giữ cho mọi thứ như: SubscribedUserId, eventType (chiến thắng, mất mát, numberOfPointsChanged, tất cả, bất kể trường hợp có thể), deliveryChannel (thông báo http, email, push thông báo cho điện thoại di động)
2. Bất cứ khi nào có chuyện xảy ra với tài nguyên, chúng tôi đặt thông điệp vào hàng đợi. Tin nhắn chứa những thứ như: teamEventIsFor, subscriberUser, deliveryChannel, deliveryAddress, vv ...
3. cửa sổ dịch vụ riêng biệt (s) (một để xử lý tất cả các deliveryTypes [email, http, push] hoặc một cho mỗi kênh) tiêu thụ thông điệp xếp hàng và cung cấp nội dung thực tế cho người dùng. Trong trường hợp của bạn, nó sẽ thông qua các thông báo đẩy.

Bây giờ, lưu ý rằng thông báo đẩy không được đảm bảo phân phối (mặc dù bạn có tốc độ phân phối khá tốt) bạn cũng có thể muốn triển khai một số tài nguyên http mà ứng dụng dành cho thiết bị di động có thể thăm dò theo thời gian kiểm tra xem có một số tin tức cho người dùng cụ thể đó không (tùy chọn).

Answer 2

Về cơ bản khi bạn muốn thực hiện hệ thống làm mới tự động, bạn chỉ có hai cách:

1: Khách hàng gửi yêu cầu định kỳ.Đây là đủ nếu:

1. Khoảng cách làm mới không phải là quá ngắn
2. Bạn đừng mong đợi ứng dụng của bạn để chạy cho hàng triệu người
3. Computing kết quả không tốn quá nhiều

Điều này có thể được thực hiện chỉ với một cách sử dụng ngây thơ của một số truy vấn trên một phía máy chủ cơ sở dữ liệu. Tất nhiên nếu bạn cần một số hiệu suất hơn bạn có thể có một số lớp trung gian.

2: Đẩy mạnh kết quả từ các máy chủ: đây là một chút phức tạp hơn để kiến ​​trúc đúng nhưng đây là Somme điểm tốt:

• Bạn gửi dữ liệu chỉ mới cho các khách hàng
• Hiệu suất khôn ngoan đó là tốt nhất

Tuy nhiên các giới hạn quan trọng hơn:

• xử lý mất Connexions hơi khó hơn một chút
• Bạn cần phải nắm bắt mọi sự kiện cập nhật dữ liệu để thúc đẩy làm mới cho khách hàng.

Nhưng vì có nhiều hơn bạn cần giải pháp architure này tồn tại: đây là một trong đó phù hợp là tốt nhất cho bạn trong JavaWorld:

JMS: Java Message Service, mà là một Message Oriented Middleware (MOM).

JMS là một đặc điểm kỹ thuật với triển khai khác nhau, personnaly tôi sẽ đi cho activeMQ là Apache. Đây là một chủ đề về điều đó: Which JMS implementation do you use?

Nếu bạn không/không thể sử dụng JMS thì hãy nhớ điều này: Messare-Oriented-Middleware. Google sẽ giúp bạn tìm thấy những gì bạn cần.

Answer 3

Bạn có tùy chọn thứ ba:

3) Thực hiện theo mẫu đăng ký xuất bản.

Để thực hiện việc này, bạn có thể sử dụng hệ thống như Amazon Simple Notification Service (SNS). Trước tiên, bạn sẽ cần phải thiết lập một ứng dụng nền tảng có chứa khóa API của bạn (cho Android) hoặc khóa riêng tư và chứng chỉ APNS (cho iOS).

Khi người dùng khởi động ứng dụng lần đầu tiên, ứng dụng sẽ yêu cầu người dùng cấp quyền truy cập thông báo đẩy, liên hệ với máy chủ của bạn và gửi mã thông báo (được sử dụng để đăng ký điểm cuối trên ứng dụng nền tảng SNS).

Điều này cho phép bạn gửi thông báo đẩy đến ứng dụng đang chạy trên thiết bị của người dùng (có thể được xử lý âm thầm hoặc được hiển thị dưới dạng thông báo thời gian thực có sẵn dữ liệu mới).

Sau đó, bạn có thể thiết lập Chủ đề cho từng nhóm, mà người dùng nhất định có thể chọn đăng ký. Khi người dùng chọn một nhóm, ứng dụng sẽ gửi yêu cầu tới máy chủ của bạn để đăng ký chủ đề mà bạn chuyển tiếp tới AWS bằng API của họ. Nếu người dùng muốn hủy đăng ký một chủ đề, bạn một lần nữa chuyển tiếp yêu cầu này tới AWS.

Điều này cho phép bạn gửi nội dung cập nhật cho từng nhóm đến chủ đề thích hợp và cung cấp thông tin này cho người dùng đăng ký, mở rộng và theo thời gian thực. Máy chủ của bạn sẽ chỉ cần ping chủ đề một lần và AWS sẽ xử lý việc phân phối cho từng người dùng.

Tất nhiên, bạn sẽ cần triển khai logic để xử lý thông báo, đăng ký, đăng ký, v.v. nhưng nó cho phép người dùng của bạn nhận cập nhật theo thời gian thực.

Xem lại các tùy chọn của bạn:

1) Dễ nhất để triển khai và có thể cần thiết cho các lượt cài đặt mới chưa đăng ký. Bạn sẽ cần điều này một trong hai cách vì vậy tôi sẽ khuyên bạn nên thực hiện phương pháp này ban đầu. Các máy chủ của bạn sẽ được cân nhắc theo tỷ lệ thuận với người dùng, vì vậy bạn nên cân nhắc lựa chọn 3) khi bạn mở rộng (và sử dụng bộ nhớ cache HTTP như véc ni hoặc mực để giảm thiểu tính toán và tải cơ sở dữ liệu)

2) Không cần thiết để truyền thông tin này tới tất cả người dùng của bạn nhưng nó có hiệu quả xuất bản-đăng ký với một chủ đề duy nhất (tất cả người dùng). Sẽ hiệu quả hơn khi chỉ thông báo cho người dùng quan tâm.

3) Đây là tùy chọn khả năng mở rộng nhất và có thêm lợi thế là thời gian thực. Bạn sẽ có thể thông báo cho người dùng về bản cập nhật ngay cả khi họ không sử dụng ứng dụng của bạn vào thời điểm đó. Theo kiến ​​trúc đăng ký xuất bản, chúng tôi sẽ chỉ có thể thông báo cho người dùng về thông tin của bạn và sau khi cập nhật, bạn có thể đặt giá trị thời gian chờ ngăn người dùng cập nhật từ máy chủ của bạn cho đến XX. Bằng cách này, nếu cập nhật thường xuyên hơn giá trị thời gian chờ của bạn, người dùng sẽ không bao giờ cần phải nhấn máy chủ của bạn.