Muszę napisać menedżera systemu powiadomień.
Oto moje wymagania:
Muszę być w stanie wysłać powiadomienie na różnych platformach, które mogą być zupełnie inne (na przykład muszę mieć możliwość wysłania wiadomości SMS lub e-mail).
Czasami powiadomienie może być takie samo dla wszystkich odbiorców na danej platformie, ale czasami może to być powiadomienie na odbiorców (lub kilku) na platformę.
Każde powiadomienie może zawierać ładunek specyficzny dla platformy (na przykład wiadomość MMS może zawierać dźwięk lub obraz).
System musi być skalowalny , muszę być w stanie wysłać bardzo dużą liczbę powiadomień bez awarii aplikacji lub serwera.
Jest to proces dwuetapowy. Najpierw klient może wpisać wiadomość i wybrać platformę, na którą ma zostać wysłany, a powiadomienia należy utworzyć w celu przetworzenia w czasie rzeczywistym albo później.
Następnie system musi wysłać powiadomienie do dostawcy platformy.
Na razie jednak mam kilka, ale nie wiem, jak będzie skalowalny lub czy to dobry projekt.
Myślałem o następujących obiektach (w pseudo języku):
Notificationobiekt ogólny :
class Notification {
String $message;
Payload $payload;
Collection<Recipient> $recipients;
}
Problem z następującymi obiektami polega na tym, że mam 1.000.000 odbiorców? Nawet jeśli Recipientobiekt jest bardzo mały, zajmie zbyt dużo pamięci.
Mógłbym również utworzyć jedno powiadomienie dla odbiorcy, ale niektórzy dostawcy platformy wymagają ode mnie wysyłania go partiami, co oznacza, że muszę zdefiniować jedno powiadomienie z kilkoma odbiorcami.
Każde utworzone powiadomienie może być przechowywane w trwałym magazynie, takim jak DB lub Redis.
Czy dobrze byłoby agregować to później, aby upewnić się, że jest skalowalne?
Na drugim etapie muszę przetworzyć to powiadomienie.
Ale jak mogę odróżnić powiadomienie od odpowiedniego dostawcy platformy?
Czy powinienem użyć obiektu takiego jak MMSNotificationrozszerzenie abstract Notification? czy coś w tym stylu Notification.setType('MMS')?
Myślę, że aby umożliwić przetwarzanie wielu powiadomień w tym samym czasie, system kolejki przesyłania wiadomości, taki jak RabbitMQ, może być właściwym narzędziem. Czy to jest
Pozwoliłoby mi to ustawić w kolejce wiele powiadomień i umożliwić kilku pracownikom wyskakiwanie powiadomień i ich przetwarzanie. Ale co, jeśli będę musiał wysyłać odbiorców, jak pokazano powyżej?
Potem wyobrażam sobie, że NotificationProcessorobiekt, do którego mógłbym dodać NotificationHandlerkażdy, NotificationHandlerbyłby odpowiedzialny za połączenie dostawcy platformy i wykonanie powiadomienia.
Mogę również użyć, EventManageraby umożliwić zachowanie wtykowe.
Wszelkie informacje zwrotne lub pomysły?
Dziękuję za poświęcony czas.
Uwaga: Jestem przyzwyczajony do pracy w PHP i jest to prawdopodobnie wybrany przeze mnie język.
Edycja (zgodnie z odpowiedzią morphunreal)
- Ile wiadomości na sekundę wysyłasz (Zdefiniuj poziomy bieżący / początkowy, określ maksymalny poziom, który system powinien obsługiwać przed przeprojektowaniem)
- Jakie ograniczenia sprzętowe ma system (pamięć, procesor itp. Dostępne dla systemu)
- Jak skaluje się sprzęt (tj. Dodając więcej serwerów, przetwarzanie w chmurze itp.)
- W jakich językach / systemach będą generowane powiadomienia?
To sam, jestem odpowiedzialny za programowe tworzenie powiadomień, ale zbudowane z interfejsu użytkownika.
- Czy generator zna odbiorców wiadomości (?), Czy są udostępniane w inny sposób (np. Reguły biznesowe dla niektórych typów alertów są kierowane do niektórych odbiorców)
Powinno być możliwe utworzenie powiadomienia dla określonych odbiorców, grupy odbiorców (na przykład za pomocą systemu tagów) lub dla całej platformy.
- Czy istnieją reguły biznesowe dotyczące dodawania rachunków CC / BCC / Read
Tak. Zauważ, że jest to naprawdę specyficzne dla platformy i odczyt lub DW nie są dostępne na wszystkich platformach.
- Czy generator zna typ wiadomości, którą wysyła (tj. SMS / e-mail), czy też jest oparty na odbiorcy?
Opiera się on na odbiorcy, jednak ponieważ odbiorca jest powiązany z platformą, a platformy mają inny sposób obsługi danych, interfejs użytkownika prawdopodobnie będzie specyficzny dla platformy, umożliwiając konfigurację obrazów, dźwięku lub czegoś takiego.
- Czy generator wymaga potwierdzenia wysyłania / odbierania / odczytu wiadomości (asynchroniczne vs wysyłanie synchroniczne)
Cóż, system powinien być podatny na błędy, ale chcielibyśmy obsłużyć błąd w celu zdefiniowania zestawu reguł, na przykład jeśli serwer jest nieosiągalny, powiadomienie powinno być wymagane do dalszego przetwarzania, ale jeśli powiadomienie jest nieprawidłowe (lub zostało zdefiniowane przez dostawcę platformy) nie należy tego wymagać, ale powiadamiać.
- Czy istnieją wymagania dotyczące przechowywania historii źródeł / odbiorców wiadomości (jak długo?)
Tak, prawdopodobnie chcemy stworzyć statystyki i raporty. * Zdefiniuj punkty końcowe powiadomień
Jakie usługi są używane do wysyłania wiadomości? Zależy, niektóre są klasyczną usługą REST, inne są jakimś egzotycznym protokołem, to naprawdę zależy od dostawcy.
Jakie informacje zwrotne / potwierdzenia są przekazywane (synchronizacja / asynchronizacja)
Zależy, niektóre są zsynchronizowane i odpowiadają z błędem, podczas gdy inne muszą zostać pociągnięte, aby sprawdzić błędy.
- Czy to możliwe, aby dodać nowe punkty końcowe [nawet jeśli tak, to czy to nawet wymaga abstrakcji]
Tak, właściwie nasza aplikacja rośnie i prawdopodobnie chcemy dodać nowego dostawcę, ale jest to stosunek około 1 lub 2 rocznie.