Qualcuno può indirizzarmi a qualcosa che spiegherà quando dovrei creare un'applicazione di Service Fabric di Azure e un'applicazione di servizio app di Azure? Ho un'applicazione che voglio compilare ma non posso determinare se dovrei costruirla usando il servizio di assistenza di Azure o il servizio app di Azure.Servizio app di Azure e fabric di servizio di Azure
Microsoft ha creato document con un confronto per Servizio app di Azure, Macchine virtuali, Fabric di servizio e Servizi cloud.
Purtroppo non ci sono indicazioni ufficiali su quando utilizzare cosa. Sono due piattaforme separate, che seguono diversi paradigmi di sviluppo.
Il servizio app fornisce funzionalità che Service Fabric non fornisce immediatamente. Roba come auto-scala, autenticazione, limitazione della velocità, integrazione con applicazioni SaaS, ecc. Alcune o tutte queste cose potrebbero arrivare a Service Fabric gradualmente, ma direi che, al momento, sono mirate a un pubblico diverso - un un team meno esperto potrebbe trovare più facile lavorare con il servizio app.
Service Fabric rende invece più semplice la composizione delle parti. Ad esempio, nell'approccio "tradizionale", se hai un'API che parla con un archivio dati e una cache per evitare di martellare l'archivio dati, dovresti gestire i vari scenari di tolleranza agli errori. Con Service Fabric la tua cache può essere inserita all'interno del processo API in una raccolta affidabile e non dovrai occuparti di avere un componente cache esterno. I dati sono collocati insieme al servizio (più veloce da recuperare/modificare!) Ed è affidabile poiché è distribuito su tutti i nodi in cui è distribuito il servizio. Cosa simile alle code. Se si pensa a un sistema di tipo di flusso di lavoro, in cui vi è un'API, un servizio di lavoro e una coda che si trova tra loro e consente loro di comunicare, è necessario gestire 3 diversi componenti e la comunicazione tra di essi. Con Service Fabric la coda entra nell'applicazione. E questo è solo la metà :) si ottiene anche il potere di utilizzare il modello di attore per il calcolo distribuito senza i soliti malumori di concorrenza. Infine, con Service Fabric ottieni il vantaggio di avere un ambiente di sviluppo più completo sul tuo box locale: non devi occuparti di creare code, ecc. Su un account di sviluppo di Azure o qualcosa del genere.
Vale anche la pena notare che non vi è nulla che vi impedisca di utilizzare entrambi i paradigmi: immaginate due app con almeno una di esse come app di fabric di servizi, che espongono le API e un'app per la logica che si trova in cima a quelle.
La tua decisione dovrebbe essere basata su ciò che stai cercando di costruire, in quanto tempo, quando vuoi rilasciare (Service Fabric è attualmente solo in anteprima privata quindi ci vorrà un po 'prima che arrivino a GA) e che tipo di squadra hai. Immagino che con il servizio app sarà facile andare a fondo anche se non hai un team con esperienza massiccia, ma Service Fabric ti darà più potenza, flessibilità e controllo.
Grazie Charisk, questo sicuramente aiuta. Penso che il modello ibrido sia attraente. Vorrei sfruttare la semplicità e le funzionalità aggiunte di un servizio app per le mie app Web e API, ma vorrei creare il back-end del sistema utilizzando il fabric di servizio. Scaverò nella comprensione di come farlo di più. Spero che ci sia un modo per ottenere il meglio da entrambi i mondi. :) – StewartArmbrecht
Il servizio di app è un servizio più gestito, SF è più gestibile da solo e puoi girare anche nei tuoi locali. SF ha un supporto migliore per lo stack non MS ad esempio app native ecc.
Come indica il documento "Service Fabric è una buona scelta se si sta creando una nuova app o si riscrive un'app esistente per utilizzare un'architettura di microservizio . "
Se il tuo hosting di alcune app non dovrebbe essere guardando SF, D'altra parte se la distribuzione di più di 10 servizi di esso diventa una soluzione migliore.
Nota anche SF ha un meccanismo di archiviazione dati incluso nei servizi.È buono a 3 cose 1) Enormi cluster di dati 2) Dati semplici, spesso nei servizi Micros I DB diventano un onere pesante poiché ogni servizio dovrebbe avere i propri dati e cose come SQL sono un po 'eccessivo quando si ha solo 1-3 tabelle. 3) Memoria di stato per il modello di programmazione Actor.
Penso che le app SF e Web affideranno la base di utenti "Servizio cloud" in futuro.
Non penso ci sia una guida definitiva là fuori - dipende da cosa stai cercando di costruire e che tipo di squadra hai. Forse puoi condividere alcune di quelle informazioni? – charisk
È un'applicazione di gestione progetti aziendale personalizzata che può espandersi in un sistema di gestione dei contenuti e altro ancora. Può essere facilmente realizzato utilizzando le API standard e le app Web, ma non sono sicuro di cosa mi piacerebbe rinunciare. Mi piace la scalabilità del Service Fabric, sia dal punto di vista delle prestazioni che dello sviluppo. Tuttavia, non so cosa mi arrenderei se adottassi questo approccio rispetto all'approccio del servizio app. Quello che speravo era qualcosa che avrebbe delineato i pro ei contro di ciascun approccio. Come decidi tra i due? – StewartArmbrecht
Potresti trovare utile questo articolo per confrontare il servizio app di Azure, le macchine virtuali, il fabric di servizio ei servizi cloud - https://docs.microsoft.com/en-us/azure/app-service-web/choose-web-site- cloud-service-vm – mvark