2015-01-09 13 views
5

Ho letto the article on Microservices sulla pagina di Martin Fowler e lo trovo piuttosto interessante. Ora pianifico di strutturare un'applicazione Web E-Commerce come proof-of-concept e mi chiedo se il mio concetto sia considerato un'architettura di Microservice.Il mio concetto segue un'architettura Microservice?

L'architettura è composta da 3 componenti:

  • una base javascript applicazione singola pagina, che invia le richieste di AJAX per
  • un server con un'API REST che alimenta i dati JSON ricevuti chiamando altri servizi (credo si chiama questo comportamento gateway API)
  • 3 servizi: CatalogProvider, CustomersProvider, CheckoutProvider

per ora i servizi sono tutti API Punto finale ts di un negozio Magento (PHP). In futuro ho intenzione di scambiare i provider con altri sistemi.

Quindi le mie domande sono:

  • MS sono considerati 'in modo indipendente schierabili'. Capisco che nel mondo di JAVA stiamo parlando di un file JAR o WAR, ma in che modo un servizio PHP è "implementabile in modo indipendente"?

  • Il mio concetto NON segue i principi di un'architettura MS, perché i provider fanno tutti parte di un unico grande sistema (Magento)?

Grazie per la lettura. Sono felice per qualsiasi suggerimento.

risposta

9

Non c'è niente che dice che l'architettura non è un'architettura MS solo perché stai usando Magento e PHP. Ma devi considerare alcune cose:

  • Pensare in termini di poter sempre riscrivere qualsiasi servizio in qualsiasi lingua e distribuire da qualche parte il sistema totale dovrebbe solo continuare a funzionare.

Se i tuoi servizi sono solo trasformazione/interfaccia strettamente collegati a Magento e non puoi semplicemente riscriverli semplicemente in Java/C#/ruby, quindi suppongo tu non abbia un'architettura MS.

Per gli artefatti dispiegabili PHP, in genere si dispone di una strategia di packaging o di controllo delle versioni attorno al servizio. Anche se "deploy" in PHP è in genere solo lo scambio di una cartella di file .php. E non dovresti davvero condividere codice/configurazione tra diversi servizi. Puoi anche guardare deployment tools for PHP se vuoi fare un ulteriore passo.

+0

'Se i tuoi servizi sono solo trasformazione/interfaccia strettamente collegati a Magento e non puoi semplicemente riscriverli in java/C#/ruby ​​facilmente, quindi suppongo tu non abbia un'architettura MS. -> Ho implementato un Modulo Magento, che estende l'API REST e alimenta il client esattamente con la struttura dati che si aspetta. Quindi il servizio è sicuramente strettamente collegato a Magento poiché ad esempio utilizza i suoi modelli .. ma penso che tu possa ancora considerarlo un MSA, no? – Rouzbeh

+0

@Rouzbeh, Una risposta molto tarda su questo thread, ma comunque, eccola qui, dato che tutti i servizi che saranno abilitati su questo approccio risolveranno lo stesso repository/database Magento, e quindi non sono "implementabili indipendentemente", questo non sembra adattarsi all'architettura MS. Inoltre, per esempio, un servizio di ordine dovrà contenere i riferimenti dei clienti per dire chi ha effettuato l'ordine. Penserei che le informazioni minime dei clienti saranno gestite autonomamente da questo servizio di ordine in un formato a suo piacimento. Ciò implicherebbe un bel po 'di denomalizzazione, che è qualcosa che incontreremo quando andremo a cercare un'architettura MS. – user132797

1

Per quanto riguarda l'architettura dei microservizi, esiste il principio SRP. Principio di responsabilità. Ogni servizio ha una propria responsabilità unica. Lo schema DB deve essere scomposto anche. I servizi di esportazione come app all'interno di un'app monolitica non convertono un'applicazione monolitica in un'applicazione di servizio micro.