Progettazione di un'applicazione nel fabric di servizio di Azure

Question

Ho bisogno di aiuto su come pensare di progettare la nostra applicazione per adattarla al nuovo modello di Fabric Service di Azure.

Oggi abbiamo un'applicazione creata su Azure Cloud Services. L'applicazione è basata su DDD e abbiamo contesti separati separati per diverse parti del sottosistema dell'applicazione. I contesti limitati sono oggi ospitati in un ruolo di lavoro che espone questi sottosistemi utilizzando una singola WebAPI.

Inoltre, abbiamo un ruolo Web che ospita il front-end Web e un ruolo di lavoro che elabora una coda in background.

Ci impegniamo a passare a un'architettura di micro servizi. La prima cosa che ho pianificato di fare è stata estrarre tutto il contesto limitato nei propri host API. Ciò comporterà 5-10 nuovi servizi WebAPI a supporto dei nostri sottosistemi.

Alla mia domanda, tutti questi sottosistemi/contesto limitato/host API possono essere la propria applicazione Fabric Service o un servizio all'interno di una singola applicazione Fabric Service?

Ho letto la documentazione, trovato qui Service Fabric Application Model, più e più volte e non riesco a capire dove i miei servizi si inserisce in.

vogliamo che il sistema di supportare diverse versioni dei servizi, e dei servizi dovrebbe anche essere possibile scalare in modo diverso da un altro. Potrebbe anche essere necessario eseguire un micro servizio in una VM di dimensioni maggiori, quindi il resto.

Si prega di qualcuno mi guida in cui si adatta alle mie esigenze.

Answer 1

Penso che tu abbia l'idea giusta, in termini generali, che ogni contesto limitato sia un (micro) servizio. Service Fabric offre due livelli di organizzazione con applicazioni e servizi, in cui un'applicazione è un raggruppamento logico di servizi. Ecco cosa significa per voi:

A livello logico, pensare a un'applicazione come a un insieme di funzionalità coesivo. I servizi che formano collettivamente quell'insieme coerente di funzionalità dovrebbero essere raggruppati come un'applicazione. Puoi chiedere a te stesso, per ogni servizio: "ha senso implementare questo servizio da solo senza questi altri servizi?" Se la risposta è no, allora dovrebbero probabilmente essere raggruppati nella stessa applicazione.

In via di sviluppo, gli strumenti di Visual Studio sono orientati un po 'più verso più servizi in un'unica applicazione, ma è possibile avere più applicazioni in un'unica soluzione.

Operativamente parlando, un'applicazione rappresenta un limite di processo, l'aggiornamento di gruppo, e il gruppo delle versioni:

• Ogni istanza di un'applicazione di creare ottiene un proprio processo (o un insieme di processi, se si dispone di più tipi di servizio a l'applicazione). Istanze di servizio di un tipo di servizio condividi processi host. Le istanze di servizio di diversi tipi di servizio ottengono il proprio processo per tipo.
• L'applicazione è l'unità di aggiornamento di livello superiore, ovvero ogni aggiornamento eseguito è un aggiornamento dell'applicazione. È possibile aggiornare singoli servizi all'interno di un'applicazione (non è sempre necessario aggiornare tutti i servizi all'interno di un'applicazione), ma ogni volta che si esegue un aggiornamento, la versione dell'applicazione cambia.
• È possibile creare istanze affiancate di versioni diverse dello stesso tipo di applicazione nel cluster. Non è possibile creare istanze affiancate di versioni diverse dello stesso tipo di servizio all'interno di un'istanza dell'applicazione.

Il posizionamento e la scala vengono eseguiti al momento del servizio. Ad esempio, è possibile ridimensionare un servizio in un'applicazione e posizionare un altro servizio su una VM più grande.