Condivisione della tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Suddivisione del servizio:

1. Principio di responsabilità unica: in un'architettura di microservizi, un servizio dovrebbe essere responsabile solo di una funzione o area di business. Ciascun servizio dovrebbe avere definizioni e confini chiari e concentrarsi solo sulla propria area di business specifica.

2. Autonomia del servizio: autonomia del servizio significa che ogni microservizio dovrebbe avere un elevato grado di autonomia, ovvero ogni servizio deve poter essere sviluppato in modo indipendente, testato in modo indipendente, costruito in modo indipendente, distribuito in modo indipendente e gestito in modo indipendente.

3. Dipendenza unidirezionale

Deve esserci una dipendenza unidirezionale tra i microservizi e le dipendenze circolari e bidirezionali sono severamente vietate.

Dipendenza circolare: A->B->C->A

Dipendenza bidirezionale: A->B,B->A

Esempio:

1. Elenco ordini

2. Elenco prodotti

Servizio ordini: fornire l'ID dell'ordine e ottenere i dettagli dell'ordine

Servizio prodotto: restituisce i dettagli del prodotto in base all'ID prodotto

Quando si richiedono informazioni sull'ordine in base a un ordine, ottenere i dettagli del prodotto in base all'ID prodotto nell'ordine.

compiere:

Idea di implementazione: il servizio servizio-ordine invia una richiesta http al servizio-prodotto, unisce il risultato restituito con il risultato dell'ordine e lo restituisce al chiamante

Metodo di implementazione: utilizzo di RestTemplate fornito da Spring

1. Definire RestTemplate

@Configurazione

classe pubblica BeanConfig{
@Fagiolo

pubblico RestTemplate restTemplate{

restituisci nuovo RestTemplate();

      }

}

2. Utilizza restTemplate nel controller dell'ordine

RiposoModello:

Riposo(Rifpresentativo Stato Tranfer) rappresenta il trasferimento dello stato delle risorse del livello

Risorse: i dati presenti in Internet come immagini, video, testi, ecc. sono tutte risorse

Livello di presentazione: la forma di rappresentazione delle risorse (ad esempio, la forma di rappresentazione del testo è txt, la forma di rappresentazione dell'immagine è jpg e alcune risorse sono espresse in json, xml o binario, ecc.)

Trasferimento di stato: quando accediamo alle risorse attraverso la rete ed eseguiamo operazioni sulle risorse (aggiunta, modifica, eliminazione, ecc.), lo stato della risorsa cambierà. Per dirla semplicemente: REST descrive una forma di interazione tra client e server nella rete. REST stesso non è pratico, utilizzando come progettare l'API RESTful (interfaccia di rete in stile REST).

Lo stile riposante ha generalmente le seguenti caratteristiche:

1. Risorse

2. Interfaccia unificata: per le operazioni sulle risorse, come ottenere, creare, modificare ed eliminare, queste finestre corrispondono ai metodi GET, POST, PUT e DELETE forniti dal protocollo http In altre parole, se si utilizza un'interfaccia in stile RESTful , dall'interfaccia puoi solo individuare le sue risorse, ma non puoi sapere quali operazioni ha eseguito nello specifico. Devi sapere nello specifico quali operazioni hanno avuto luogo e giudicare dal tipo di metodo di richiesta http (ad esempio: lo stesso URL: GET/. blog/{blogId }: interroga il blog DELETE/blog/{blogId} Elimina blog)

Svantaggi dell'API RESTful:

1. Il metodo operativo è complicato. L'API RESTful di solito distingue le azioni operative sulle risorse in base a GET, POST, PUT e DELETE.
Il metodo HTTP non può essere osservato direttamente e deve essere osservato tramite strumenti come l'acquisizione di pacchetti. Sarà più intuitivo se l'azione viene posizionata sull'URL.
È più favorevole alla comprensione e alla comunicazione del team.
2. Alcuni browser non sono molto amichevoli nel supportare richieste diverse da GET e POST e richiedono un'elaborazione aggiuntiva.
3. Enfasi eccessiva sulle risorse Tuttavia, le esigenze aziendali effettive potrebbero essere più complesse e non possono essere soddisfatte semplicemente aggiungendo, eliminando, modificando e cercando
L'API RESTful aumenterà la difficoltà e i costi di sviluppo.

C'è un problema con il progetto
1. Quando si chiama in remoto, l'IP e il numero di porta dell'URL sono codificati (http://127.0.0.1:9090/prodotto/). Se si cambia l'IP, è necessario modificare il codice.
codice
2. Come può il chiamante non fare affidamento sull'IP del fornitore di servizi?
3. Distribuzione su più macchine: come condividere la pressione?
4. Quando si effettuano chiamate remote, è molto facile scrivere l'URL sbagliato e la riusabilità non è elevata. Come implementare le chiamate remote in modo elegante?
5. Tutti i servizi possono richiamare questa interfaccia. Ci sono dei rischi?