Κοινή χρήση τεχνολογίας

Κατασκευή έργου Spring Cloud

2024-07-12

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

Διαχωρισμός υπηρεσιών:

1. Αρχή της ενιαίας ευθύνης: Σε μια αρχιτεκτονική μικροϋπηρεσιών, μια υπηρεσία θα πρέπει να είναι υπεύθυνη μόνο για μία λειτουργία ή επιχειρηματικό τομέα.

2. Αυτονομία υπηρεσίας: Η αυτονομία υπηρεσίας σημαίνει ότι κάθε μικρουπηρεσία πρέπει να έχει υψηλό βαθμό αυτονομίας, δηλαδή, κάθε υπηρεσία θα πρέπει να μπορεί να αναπτυχθεί ανεξάρτητα, να ελεγχθεί ανεξάρτητα, να κατασκευαστεί ανεξάρτητα, να αναπτυχθεί ανεξάρτητα και να λειτουργήσει ανεξάρτητα.

3. Μονόδρομη εξάρτηση

Πρέπει να υπάρχει μονόδρομη εξάρτηση μεταξύ των μικροϋπηρεσιών και οι κυκλικές εξαρτήσεις και οι αμφίδρομες εξαρτήσεις απαγορεύονται αυστηρά.

Κυκλική εξάρτηση: Α->Β->Γ->Α

Αμφίδρομη εξάρτηση: A->B,B->A

Παράδειγμα:

1. Λίστα παραγγελιών

2. Λίστα προϊόντων

Υπηρεσία παραγγελίας: Δώστε αναγνωριστικό παραγγελίας και λάβετε στοιχεία παραγγελίας

Υπηρεσία προϊόντος: Επιστρέψτε τα στοιχεία του προϊόντος με βάση το αναγνωριστικό προϊόντος

Όταν ζητάτε πληροφορίες παραγγελίας με βάση μια παραγγελία, λάβετε λεπτομέρειες προϊόντος με βάση το αναγνωριστικό προϊόντος στην παραγγελία.

ολοκληρώσει:

Ιδέα υλοποίησης: Η υπηρεσία παραγγελίας-υπηρεσίας στέλνει ένα αίτημα http στην υπηρεσία προϊόντος-υπηρεσίας, συγχωνεύει το επιστρεφόμενο αποτέλεσμα με το αποτέλεσμα της παραγγελίας και το επιστρέφει στον καλούντα

Μέθοδος υλοποίησης: Χρησιμοποιώντας το RestTemplate που παρέχεται από την Spring

1. Ορίστε το RestTemplate

@Διαμόρφωση

δημόσια τάξη BeanConfig{
@Φασόλι

δημόσιο RestTemplate restTemplate{

επιστροφή νέου RestTemplate();

      }

}

2. Χρησιμοποιήστε το restTemplate στον ελεγκτή παραγγελίας

RestTemplate:

Υπόλοιπο(Σχετικά μεπαρουσίαση μικρόtate Τranfer) αντιπροσωπεύει τη μεταφορά κατάστασης πόρων επιπέδου

Πόροι: Τα δεδομένα στο Διαδίκτυο, όπως εικόνες, βίντεο, κείμενα κ.λπ. είναι όλα πόροι

Επίπεδο παρουσίασης: η μορφή αναπαράστασης των πόρων (για παράδειγμα, η μορφή αναπαράστασης του κειμένου είναι txt, η μορφή αναπαράστασης της εικόνας είναι jpg και ορισμένοι πόροι εκφράζονται σε json, xml ή δυαδικό κ.λπ.)

Μεταφορά κατάστασης: Όταν έχουμε πρόσβαση σε πόρους μέσω του δικτύου και εκτελούμε (προσθήκη, τροποποίηση, διαγραφή, κ.λπ.) τους πόρους, θα προκαλέσει την αλλαγή της κατάστασης των πόρων Για να το θέσω απλά: Το REST περιγράφει μια μορφή αλληλεπίδρασης μεταξύ Πελάτη και Διακομιστή το ίδιο το δίκτυο REST δεν είναι πρακτικό, χρησιμοποιώντας τον τρόπο σχεδίασης RESTful API (διεπαφή δικτύου REST).

Το ξεκούραστο στυλ έχει γενικά τα ακόλουθα χαρακτηριστικά:

1. Πόροι

2. Ενοποιημένη διεπαφή: Για λειτουργίες σε πόρους, όπως η απόκτηση, η δημιουργία, η τροποποίηση και η διαγραφή, αυτά τα παράθυρα αντιστοιχούν στις μεθόδους GET, POST, PUT και DELETE που παρέχονται από το πρωτόκολλο http. Με άλλα λόγια, εάν χρησιμοποιείτε μια διεπαφή τύπου RESTful , από τη διεπαφή Μπορείτε να εντοπίσετε μόνο τους πόρους του, αλλά δεν έχετε τρόπο να γνωρίζετε ποιες λειτουργίες έχει πραγματοποιήσει : GET/blog/{blogId }: Ιστολόγιο ερωτήματος DELETE/blog/{blogId} Διαγραφή ιστολογίου)

Μειονεκτήματα RESTful API:

1. Η μέθοδος λειτουργίας είναι επαχθής, συνήθως, διακρίνει τις ενέργειες σε πόρους σύμφωνα με το GET, το POST, το PUT και το DELETE.
Η μέθοδος HTTP δεν μπορεί να παρατηρηθεί άμεσα και πρέπει να παρατηρηθεί μέσω εργαλείων όπως η καταγραφή πακέτων Θα είναι πιο διαισθητική εάν η ενέργεια τοποθετηθεί στη διεύθυνση URL.
Ευνοεί περισσότερο την ομαδική κατανόηση και επικοινωνία.
2. Ορισμένα προγράμματα περιήγησης δεν είναι πολύ φιλικά στην υποστήριξη αιτημάτων εκτός από το GET και το POST και απαιτούν πρόσθετη επεξεργασία.
3. Η υπερβολική έμφαση στους πόρους, ωστόσο, οι πραγματικές επιχειρηματικές ανάγκες μπορεί να είναι πιο περίπλοκες και οι ανάγκες δεν μπορούν να καλυφθούν απλώς με την προσθήκη, τη διαγραφή, την τροποποίηση και την αναζήτηση
Το RESTful API θα αυξήσει τη δυσκολία και το κόστος ανάπτυξης.

Υπάρχει πρόβλημα με το έργο
1. Κατά την εξ αποστάσεως κλήση, η IP και ο αριθμός θύρας της διεύθυνσης URL είναι κωδικοποιημένα (http://127.0.0.1:9090/product/) Εάν αλλάξετε την IP, πρέπει να τροποποιήσετε τον κωδικό.
κώδικας
2. Πώς μπορεί ο καλών να μην βασίζεται στην IP του παρόχου υπηρεσιών;
3. Ανάπτυξη πολλαπλών μηχανών, πώς να μοιραστείτε την πίεση;
4. Όταν πραγματοποιείτε απομακρυσμένες κλήσεις, είναι πολύ εύκολο να γράψετε το λάθος URL και η δυνατότητα επαναχρησιμοποίησης δεν είναι υψηλή Πώς να πραγματοποιήσετε κομψές απομακρυσμένες κλήσεις;
5. Όλες οι υπηρεσίες μπορούν να καλέσουν αυτήν τη διεπαφή Υπάρχουν κίνδυνοι;