Come montare un motore di regole in un'architettura di microservizi?

Facciamo un passo indietro per un secondo e valutiamo il nostro punto di partenza prima di scrivere questa risposta di probabile lunghezza del romanzo. Hai:

• Un monolite di grandi dimensioni (il motore delle regole)
• Una grande quantità di dati non modularizzati che vengono inviati alla rinfusa
• È difficile ottenere dati da e verso il motore delle regole
• Non puoi rimuovere il motore delle regole

Ok, questo non è eccezionale per i microservizi. Un problema immediatamente evidente sei ragazzi sembrano fraintendere ciò che microservizi sono.

everyone (calling the rules engine) has to reimplement the fetching of the data, even if they don't need it for themselves;

Devi definire una sorta di API o metodo di comunicazione che i tuoi microservizi utilizzano e che sono comuni. Questa potrebbe essere una libreria che tutti possono importare. Potrebbe essere la definizione di un protocollo di messaggi. Potrebbe utilizzare uno strumento esistente ( cercare i bus dei messaggi di microservizio come un buon punto di partenza) .

La questione della comunicazione interservizi non è un problema "risolto" di per sé, ma a questo punto non è nemmeno un problema "roll your own". Un sacco di strumenti e strategie esistenti possono rendere la tua vita più facile.

Indipendentemente da cosa fai, scegli un sistema singolo e prova ad adattare le tue API di comunicazione per utilizzarlo. Senza un modo definito per interagire con i tuoi servizi, avrai tutti gli svantaggi dei microservizi e dei servizi monolitici e nessuno dei vantaggi di entrambi.

La maggior parte dei tuoi problemi deriva da questo.

the requests to the rules engine are complex;

Rendili meno complessi.

Trova i modi per renderli meno complessi. Sul serio. Modelli di dati comuni, suddividono il tuo motore di regole singolo in più piccoli, o qualcosa del genere. Fai funzionare meglio il tuo motore di regole. Non prendere l'approccio "marmellata tutto nella query e continua semplicemente a renderli complicati" - guarda seriamente cosa stai facendo e perché.

Definisci una sorta di protocollo per i tuoi dati. La mia ipotesi è che voi ragazzi non avete un piano API definito (come sopra) e avete iniziato a scrivere chiamate REST ad hoc quando necessario. Questo diventa sempre più complesso, poiché ora devi mantenere ogni microservizio ogni volta che qualcosa viene aggiornato.

Ancora meglio, non sei esattamente la prima azienda a implementare mai uno strumento di shopping online. Vai a cercare altre aziende.

Ora cosa ...

Dopo questo, hai almeno troncato alcuni dei maggiori problemi.

Il prossimo numero è questa domanda del tuo motore di regole. Spero che questo sia ragionevolmente senza stato, in modo da poterlo scalare. Se lo è, mentre non è ottimale, almeno non morirai in un tripudio di gloria o costruirai folli soluzioni alternative.

Vuoi che il tuo motore di regole sia stateless. Fai in modo che elabori solo i dati. Se lo trovi come collo di bottiglia, fallo in modo da poter eseguire più operazioni dietro a un proxy / bilanciamento del carico. Non ideale, ma ancora praticabile.

Dedica del tempo a considerare se uno qualsiasi dei tuoi microservizi debba essere inserito nel tuo motore di regole. Se si aumenta il sovraccarico del sistema in modo significativo solo per ottenere una "architettura dei microservizi", è necessario dedicare più tempo alla pianificazione.

In alternativa, il tuo motore di regole può essere diviso in pezzi? Potresti ottenere dei guadagni semplicemente facendo dei pezzi dei tuoi servizi specifici per il motore delle regole.

We must also make sure that it does not become a bottleneck – for example some data is rather slow to fetch (10s or even more)

Supponendo che questo problema esista dopo aver risolto i problemi di cui sopra, è necessario investigare seriamente perché questo sta accadendo. Hai un incubo che si sta svolgendo, ma invece di capire perché (10 secondi? Per inviare acquisti dati del portale in giro? Chiamami cinico, ma questo sembra un po 'assurdo) sembra che tu stia rattoppando i sintomi piuttosto che guardare al problema che causa i sintomi in primo luogo.

Hai usato la frase "recupero dati" più e più volte. Sono questi dati in un database? In caso contrario, prendi in considerazione l'idea di fare questo - se stai spendendo così tanto tempo "manualmente" nel recupero dei dati, sembra che usare un vero database sarebbe una buona idea.

Potresti avere un design con un database per i dati che ottieni (a seconda di che cosa si tratta, lo hai menzionato più volte), alcuni motori di regole e i tuoi client.

Un'ultima nota è che vuoi essere sicuro di utilizzare il corretto controllo delle versioni delle tue API e servizi. Una versione minore non dovrebbe rompere la compatibilità all'indietro. Se ti ritrovi a liberare tutti i tuoi servizi allo stesso tempo perché funzionino, non hai un'architettura di microservizio, hai un'architettura monolitica distribuita.

E in ultima analisi, i microservizi non sono una soluzione valida per tutti. Per favore, per il bene di tutto ciò che è santo, non farlo solo perché è la cosa nuova dell'anca.

Con la quantità di informazioni presentate sul motore delle regole e i suoi input e output, penso che il tuo suggerimento no. 2 è sulla strada giusta.

Gli attuali utenti del motore delle regole potrebbero esternalizzare il processo di raccolta delle informazioni richieste a un componente più specifico.

Esempio: stai attualmente utilizzando il motore delle regole per calcolare gli sconti che devono essere applicati ai contenuti del carrello. Gli acquisti precedenti, la geografia e le offerte attuali vi rientrano.

Il nuovo requisito è di utilizzare molte di queste stesse informazioni per le offerte via e-mail ai clienti precedenti in base alle offerte speciali e agli acquisti precedenti. Acquisti precedenti, offerte attuali e future in esso.

Avrei due servizi separati per questo. Entrambi si affiderebbero al servizio del motore delle regole per alcuni dei suoi lavori pesanti. Ognuno di loro raccoglie i dati richiesti necessari per la loro richiesta al motore delle regole.

Il motore delle regole applica solo le regole, i consumatori non devono preoccuparsi dei dati esatti necessari al motore delle regole per il particolare contesto, e questi nuovi servizi di intermediazione fanno solo una cosa: assemblare il contesto e trasmettere la richiesta a il motore delle regole e restituisce la risposta non modificata.

L'aggregazione dei dati richiesti per la decisione deve essere eseguita al di fuori del motore delle regole. Questo perché sono meglio progettati come servizi stateless come quando possibile. Il recupero dei dati richiede necessariamente elaborazione asincrona e mantenimento dello stato. Non importa se il recupero viene eseguito da un proxy che sta affrontando il servizio decisionale, dai chiamanti o da un processo aziendale.

Come pratica per l'implementazione, menzionerò che IBM Operational Decision Manager è inizia a documentare e supporta già l'utilizzo del prodotto all'interno dei contenitori docker . Sono sicuro che anche altri prodotti forniscano questo supporto e che diventeranno mainstream.