Un'API supportata da un RDMS può essere sottoposta a refactoring in Micro services?

Question

Un'API supportata da un RDMS può essere sottoposta a refactoring in Micro services?

#1 da (4 voti)

2

Lavorare su un'API ...

Considerare un database di esempio come il seguente per alcune applicazioni aziendali:

+-------------------------------+
|            tables             |
+-------------------------------+
| account_achievement_mappings  |
| account_company_mappings      |
| account_document_mappings     |
| account_feature_mappings      |
| account_group_mappings        |
| account_notification_mappings |
| accounts                      |
| achievements                  |
| companies                     |
| company_document_mappings     |
| company_feature_mappings      |
| documents                     |
| features                      |
| group_company_mappings        |
| group_document_mappings       |
| group_feature_mappings        |
| groups                        |
| notifications                 |
+-------------------------------+

Nessuna delle tabelle è troppo complicata e le relazioni possono essere facilmente desunte dai loro nomi.

Come ho capito, con un'architettura di micro servizi, ogni micro servizio dovrebbe avere il proprio database.

Mi chiedo se sia possibile suddividere un tale schema in sotto-schemi, in modo che possa quindi refactored da un monolite a una raccolta di micro servizi.

Ad esempio, dal momento che notifications è solo collegato a accounts I anche se tirarlo fuori e creare un motore di notifica potrebbe essere un buon primo candidato.

Modifica:

1) Se i micro servizi condividono un database, il database non diventerebbe un collo di bottiglia?

2) Se riesco a separare il mio database in un insieme di database più piccoli, come gestisco le relazioni? Forse questo significa che non dovrei distruggerli.

api microservices

posta TylerAndFriends 10.03.2016 - 19:08

fonte

1 risposta

Leggi altre domande sui tag api microservices

Aggiunta di una funzione al membro della classe Si tratta di una monade in Java? (parte 2)

score 4 · Accepted Answer

As I understand, with a micro service architecture, each micro service should have its own database.

Non lo considero un dato. Se hai bisogno di due API diverse che richiedono entrambi l'accesso allo stesso database, penserei che due microservizi sarebbero ancora una scelta naturale.

I am wondering if it is possible to break up such a schema into sub-schemas, so that it can then refactored from a monolith to a collection of micro services.

Intendi sottotesti di database? Non penso che tu ne abbia bisogno, a meno che tu non creda che sarebbe vantaggioso per ragioni diverse dall'architettura dei tuoi microservizi.

If micro services share a database, wouldn't the database become a bottleneck?

Improbabile, a meno che tu non abbia un'enorme quantità di traffico. I moderni database relazionali sono progettati per gestire questo tipo di attività multiutente con aplomb.

If I can separate my database into a set of smaller databases, how do I handle the relationships?

Esattamente il motivo per cui non dovresti separarlo in più database.

Non c'è nulla di mistico nei microservizi. I microservizi sono solo una risposta alla complessità dei sistemi monolitici. Come disse una volta Einstein, "Il più semplice possibile, ma non più semplice."