Come configurare la logica del servizio di notifica?

2

Stiamo creando un servizio di notifica il cui compito è inviare notifiche push all'utente finale. Esistono due tipi di notifiche

  1. Notifica di gruppo in cui inviamo la stessa notifica di testo a tutti gli utenti di un gruppo. Ciò è facilmente ottenibile poiché tutti si iscrivono a un gruppo e inviamo una notifica a un gruppo.

  2. Notifica personalizzata in cui inviamo notifiche di testo specifiche a ciascun utente.

La mia domanda è (per la notifica personalizzata) qual è il modo migliore per architettare il nostro servizio di notifica.

Approccio 1: manteniamo la logica di selezionare gli utenti in base alla logica delle app sul servizio applicativo in cui creiamo messaggi per ciascun utente e poi inviamo gruppi di utenti con un messaggio al servizio di notifica per inviarli?

Seleziona utenti in base alla logica dell'applicazione (sul server app) - > Effettua il loop su ciascun utente e crea il messaggio personalizzato (sul server dell'app) - > Crea gruppi di utenti 1K con un messaggio e invialo al servizio di notifica (sul server delle app) - > Invia notifica (servizio di notifica)

  • Aggiunge carico sul server delle applicazioni

Approccio 2: consentiamo al servizio di notifica di accedere direttamente al database dell'app e recuperare gli utenti, creare il loro messaggio e inviarli?

Seleziona utenti - > Fai il loop per creare un messaggio - > Invia a ciascun utente (Tutto sul servizio di notifica)

  • In questo approccio, il servizio di notifica deve accedere al DB di app e molte regole di app vanno qui, non sembra giusto. Poiché renderà il servizio di notifica contiene molta logica dell'app.
  • Prendi il carico del server delle app perché tutto deve essere fatto dal servizio di notifica.

Cosa suggerite voi ragazzi? C'è qualche altro approccio che possiamo prendere in considerazione. Considerando che potremmo aver bisogno di inviare notifiche personalizzate a milioni di utenti.

    
posta mitesh sharma 17.12.2017 - 09:31
fonte

1 risposta

2

Penso che la risposta alla tua domanda sia come identificare i limiti del servizio. L'approccio di base è che ogni servizio dovrebbe possedere tutti i dati necessari per svolgere il proprio lavoro. Quindi i servizi non sono definiti da livelli orizzontali, come nel caso delle alcune linee guida SOA , ma piuttosto tramite sezioni verticali . È una parte concreta della funzionalità aziendale o di un processo aziendale, con i suoi controllori, la logica del dominio e l'interfaccia utente. Dovrebbe essere autonomo, quindi non ha bisogno di dati o comportamenti di altri servizi.

Considerando il tuo esempio, è probabile che il tuo servizio di notifica faccia parte di un servizio logico più ampio. Ad esempio, se il tuo dominio riguarda una rete di vendita al dettaglio, e un giorno c'è un enorme sconto e vuoi avvisare tutti i tuoi clienti. È necessario avere il numero di telefono del cliente, informazioni sullo sconto (probabilmente su misura per un particolare tipo di cliente) e un testo di notifica. Chi gestisce le regole aziendali di sconto? Quale servizio possiede i dati dei clienti? Scommetto che è un servizio di vendita. Quindi il servizio di notifica è sicuramente una parte di esso. Quindi questo servizio di vendita dovrebbe avere il proprio database con tutti i dati necessari per inviare una notifica.

Se stai riflettendo su problemi di prestazioni, è possibile estrarre questa funzionalità di notifica nella propria macchina fisica e, in caso di necessità, aggiungere solo un po 'di macchine. Inoltre, non è necessario creare un database separato per questa nuova funzionalità, poiché i limiti del servizio sono logici, non fisici.

Ecco una serie di post che risolve questi problemi in maggior dettaglio.

    
risposta data 17.12.2017 - 11:43
fonte