Architettare una ricerca universale di un prodotto con microservizi

Question

Architettare una ricerca universale di un prodotto con microservizi

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

2

Stiamo costruendo un nuovo prodotto nello spazio immobiliare e gli utenti finali di questo prodotto non sono così esperti di tecnologia. Per avere una migliore esperienza utente con il nostro prodotto, vogliamo che i nostri utenti trovino le cose rilevanti in modo rapido e semplice. A parte una semplice interfaccia utente, una barra di ricerca universale sembra aggiungere valore.

La barra di ricerca con completamento automatico consentirà agli utenti di trovare informazioni quali: la cronologia di fatturazione (pagamenti precedenti, fatture ..), il contenuto della guida, il contenuto di supporto dai ticket dell'helpdesk, i dati dalla cronologia della chat e così via.

Stiamo andando con l'architettura dei microservizi per i nostri servizi come la gestione degli utenti, il sistema dei ticket di aiuto, la chat, il CMS per il contenuto della guida e altro ancora. La domanda è: come possiamo creare questo servizio di ricerca centrale che può indicizzare e archiviare tutti i contenuti utente di tutti questi servizi che l'utente sarà in grado di cercare.

Ogni servizio dovrebbe scaricare i dati in elasticsearch per essere indicizzati e resi disponibili per la ricerca, quindi un servizio di ricerca piuttosto che una query? Di 'quando un ticket di supporto è aperto, o una conversazione chat è chiusa il microservizio rilevante copierà questi dati in un servizio come ricerca elastica? Sarebbe meglio per i microservizi spingere tali dati su una coda che poi viene consumata in elasticsearch?

Sono aperto a qualsiasi idea e idea su come la ricerca è architettata e sulle migliori pratiche in questo. Felice di fornire maggiori informazioni sul nostro servizio se aiuta a ottenere una risposta migliore.

AGGIORNAMENTO:

Esiste un DB per microservizio
La ricerca non deve essere in tempo reale
Non sono troppo preoccupato per il carico e andremo con la ricerca in hosting - AWS cloudsearch o elasticsearch

architecture search-engine elasticsearch

posta mrcasa bengaluru 05.02.2018 - 12:47

fonte

3 risposte

Leggi altre domande sui tag architecture search-engine elasticsearch

Equilibrio tra i confini aggregati e la coerenza del dominio in DDD Esiste uno stile di codifica accettato per più funzioni freccia ES6?

score 2 · Answer 1

Eviterei un 'Servizio centrale' per finire con un grande blob di dati non strutturati.

Presumibilmente una volta che l'utente ha trovato qualcosa lì dentro, vorrai fare qualcosa con il risultato e questo richiederà dati strutturati.

Ogni MicroService dovrebbe essere responsabile dei propri dati e fornire una funzione di ricerca.

Quando l'utente fa una ricerca globale, puoi colpire tutti i MicroServices o eseguire qualche elaborazione per provare a restringere il tipo per primo.

score 1 · Answer 2

We are building a new product in real estate space and the end users of this product are not so tech savvy. To have better user experience with our product, we want our users to find relevant things quickly and easily. Apart from a simple UI, a universal search bar seems to add value.

The search bar with auto-complete will allow users to find information such as - their billing history (past payments, invoices..), help content, support content from helpdesk tickets, data from chat history and such.

Penso che tu abbia fallito nel fare il primo passo del design del software (ricerca di casi d'uso) in modo da buttare ogni genere di assurdità nel tuo progetto (una ricerca universale, una chat, un lavello della cucina, forse un ice- macchina del gelato il giovedì) usando la "logica del fucile" (più proiettili significa più possibilità di colpire un bersaglio, anche quando non si sa dove sia il bersaglio).

Se vuoi che gli utenti trovino le cose rilevanti in modo rapido e semplice, allora devi sapere cosa è rilevante per l'utente specifico in quel momento. Ad esempio, qualcuno che cerca una casa da affittare (in una certa area, in una certa fascia di prezzo) non vorrà una ricerca universale che inquini i risultati della ricerca con la spazzatura destinata alle persone che vendono una casa. Non vogliono una ricerca universale, vogliono una "ricerca specifica caso d'uso".

Per un altro esempio, qualcuno che cerca la cronologia di fatturazione vorrebbe accedere e fare clic su un link "cronologia di fatturazione" per visualizzare un elenco cronologico e non vuole una ricerca su un universo (e probabilmente non vorrà alcun tipo di di ricerca).

score 1 · Answer 3

In qualche modo non sarei d'accordo con @Ewan. Mentre sì, può finire con un grande blob di dati non strutturati, questa è solo una conseguenza inevitabile se non lavori per impedirlo.

In contrappunto, direi che l'internet pubblico è in realtà una raccolta di microservizi, la maggior parte dei quali capita di fornire documenti HTML di un gusto o di un altro. Google, Bing, ecc. Sono essenzialmente servizi di ricerca centrali per quella "impresa".

Quindi, il modo in cui procedo per il tuo caso d'uso sarebbe quello di costruire quel cluster di ricerca centrale (o usare quello di AWS) ma prestare molta attenzione a ciò che indichi, come e in che modo fai riferimento al servizio di origine. Si desidera indicizzare in anticipo e quindi servire su richiesta, nella mia esperienza, che offre la migliore esperienza utente complessiva. La cosa che devi decidere è quante informazioni e in quale schema vuoi memorizzare gli oggetti degli indici. Ciò richiederà un po 'di tuning e dipenderà da quali parti dei dati di origine vuoi essere ricercabili. La risposta potrebbe essere "tutto" ma probabilmente non lo è, e se non lo è, ci sono guadagni di efficienza limitando l'ambito dell'indice.