Οι πελάτες μας στο Move.com έχουν γράψει αυτό το υπέροχο ιστολόγιο για το πώς χρησιμοποίησαν το Tyk Operator για να βελτιστοποιήσουν τη διαχείριση API τους με ομοσπονδιακή αυτονομία. Αφαιρέστε το, φίλοι!
Θα σας πω μια ιστορία. Ναι, αυτή είναι μια τεχνική ανάρτηση ιστολογίου, αλλά η ιστορία προέλευσης είναι συχνά το πιο σημαντικό πράγμα που πρέπει να γνωρίζετε όταν αποφασίζετε εάν θα χρησιμοποιήσετε ή όχι τεχνολογία. Τι ώθησε την ομάδα να χρησιμοποιήσει μια δεδομένη τεχνολογία; Τι πρόβλημα λύνει; Μην ανησυχείς. θα έρθουν πολλές τεχνικές λεπτομέρειες, ώστε να μπορείτε να γέρνετε πίσω και να νιώσετε άνετα.
Ας ξεκινήσει η ιστορία.
Το έτος ήταν το 2021 και η πανδημία βρισκόταν σε πλήρη εξέλιξη. Πολλοί από εμάς δεν είχαμε φύγει από τα σπίτια μας εδώ και μήνες…μπορεί να πλένουμε ακόμα τα παντοπωλεία μας με το Windex. Σε αυτό το πλαίσιο, ξεκινήσαμε ένα μεγάλο έργο στο Realtor.com για να αναθεωρήσουμε το επίπεδο API και να μεταμορφώσουμε τον τρόπο με τον οποίο αλληλεπιδρούν οι ομάδες υποστήριξης και διεπαφής μας.
Έλλειψη κοινής υποδομής
Βλέπετε, είχαμε μπει all in για μικροϋπηρεσίες και πληρώνουμε το τίμημα. Εάν οι μικροϋπηρεσίες είναι το παροιμιώδες σφυρί, δεν είναι κάθε μέρος της στοίβας τεχνολογίας σας καρφί. Ορισμένα κομμάτια της πλατφόρμας σας μπορούν και πρέπει να παρέχονται ως κοινόχρηστα στοιχεία σε ομάδες. Το πιο σημαντικό, για τους σκοπούς μας σε αυτό το άρθρο, είναι απαραίτητο να παρέχουμε κοινόχρηστη υποδομή επιπέδου αιχμής και API.
Μας έλειπε τελείως αυτή η κοινή υποδομή και κάθε ομάδα υποστήριξης έλυνε το πρόβλημα της παροχής API σε ομάδες πελατών με διαφορετικό τρόπο. Οι ομάδες μοιράστηκαν ορισμένες λύσεις backend-for-frontend, αλλά χρειάζονταν περισσότερη συνέπεια μεταξύ των ομάδων.
Αυτό οδήγησε σε πολλαπλασιασμό λύσεων για τη διαχείριση API, συμπεριλαμβανομένων αρκετών διπλότυπων εφαρμογών για περιορισμό ρυθμού, επικύρωση διακριτικών και λίστες αποκλεισμού/επιτρεπόμενων IP.
Επιπλέον, υπήρχαν πολλοί τρόποι δρομολόγησης της κυκλοφορίας στα backend, συμπεριλαμβανομένων των API Gateways, των διανομών CloudFront και των ALB.
Πολύπλοκα ζητήματα μας κρατούν πίσω
Με αυξημένη επιφάνεια API προς διαχείριση, οι ομάδες μας αντιμετώπισαν διάφορα ζητήματα:
- Η ανάγκη ανάπτυξης αλλαγών σε πολλά σημεία.
- Διπλό έργο, καθώς κάθε σημείο εισόδου χρειαζόταν το δικό του σύνολο εργαλείων ακραίας στρώσης.
- Περισσότερη επιφάνεια για άμυνα κατά της επίθεσης.
Αυτή η εξάπλωση των τελικών σημείων API ήταν επώδυνη για την αλληλεπίδραση των ομάδων πελατών μας – προκαλώντας την προσθήκη πολλών πρόσθετων επιχειρηματικών λογικών στη βάση κώδικα πελατών μας με τη μορφή εντολών πριονωτή αν.
Ξέραμε ότι όλη αυτή η πολυπλοκότητα μας εμπόδιζε, αλλά από πού να ξεκινήσουμε; Είχαμε πολλά προβλήματα να αντιμετωπίσουμε. Η ενοποίηση της σύνταξης και της σημασιολογίας των API μας πίσω από το GraphQL είναι μια σχετική αλλά ξεχωριστή ιστορία για άλλη φορά. Προς το παρόν, θα επικεντρωθούμε στο ζήτημα της εξάπλωσης της υποδομής δικτύου και στην έλλειψη συνεπών, υποστηριζόμενων διαδρομών για λειτουργικότητα επιπέδου ακμής, όπως ανίχνευση ρομπότ, περιορισμός ρυθμού, ένεση κεφαλίδας και προσωρινή αποθήκευση.
Αναζήτηση για μια διαφανή λύση API
Λοιπόν, πιάσαμε δουλειά. Συγκεντρώθηκε μια διαλειτουργική ομάδα για να διερευνήσει τις επιλογές και αμέσως, όπως μπορείτε να περιμένετε με οποιαδήποτε πρωτοβουλία πλατφόρμας, αρχίσαμε να ακούμε από μέλη της οργάνωσης που ανησυχούσαν για την απώλεια της αυτονομίας:
- „Θα χρειαστεί να βασιστούμε σε άλλη ομάδα για να μας βοηθήσει να ξεκινήσουμε τα API μας;“
- „Πρέπει να περιμένουμε έναν προγραμματιστή πλατφόρμας να αλλάξει τον περιορισμό των τιμών μας;“
- «Δεν θα μας επιβραδύνει όλο αυτό;»
Αυτά είναι σπουδαία και δικαιολογημένα ερωτήματα. πώς θα μπορούσαμε να αφαιρέσουμε την πολυπλοκότητα μέσω της συγκέντρωσης χωρίς να θυσιάσουμε την ταχύτητα; Σαφώς, αυτή η πλατφόρμα έπρεπε να είναι όσο το δυνατόν πιο διαφανής και αυτοεξυπηρετούμενη για να αποφευχθεί η αντιμετώπισή της ως εμπόδιο ή εμπόδιο.
Εισάγετε Χοντρό
Για να ξεκινήσουμε να χτίζουμε αυτήν την εμπειρία, εξετάσαμε προϊόντα στην αγορά – και εδώ γνωρίσαμε το αξιαγάπητο πράσινο πλάσμα που θα γίνει ο κύριος χαρακτήρας αυτής της ιστορίας. Την ξέρεις…την Tykling!
Τι στον κοσμο…?!? Το πρόφερα κάτω από την ανάσα μου καθώς κοιτούσα ένα εξωγήινο πλάσμα με γυμνό πάτο. Ο συνάδελφός μου, ο Μπράιαν, μου είχε στείλει έναν σύνδεσμο προς το Ιστοσελίδα Tykκαι με υποδέχτηκε η χερουβική μασκότ τους με έναν εξίσου χερουβικό γυμνό πισινό.
Η έκπληξή μου έδωσε τη θέση της στο πραγματικό ενδιαφέρον καθώς διάβαζα περισσότερα για το Tyk. Το GraphQL είναι ενσωματωμένο στην πύλη? Γλυκός! Περιορισμός ποσοστού, προσωρινή αποθήκευση και κοινή χρήση API; Πολύ ωραία! Ω, τι είναι αυτό; ΕΝΑ εγγενής χειριστής Kubernetes σας επιτρέπει να διαμορφώσετε την πύλη σας σε απλά αρχεία yaml; Λοταρία!
Αυτό ήταν ένα σημείο καμπής για την ομάδα όταν ανακαλύψαμε το Tyk Operator και συνειδητοποιήσαμε τι μπορούσε να κάνει. Είναι ένα σημείο καμπής για αυτό το άρθρο, καθώς σηματοδοτεί το σημείο όπου γινόμαστε πιο τεχνικοί.
Χοντρός χειριστής
Χοντρός χειριστής είναι ένας τελεστής Kubernetes, ο οποίος, για να απλοποιήσουμε λίγο τα πράγματα, είναι μια διαδικασία που παρακολουθεί συμβάντα που σχετίζονται με προσαρμοσμένους πόρους σε ένα σύμπλεγμα Kubernetes και στη συνέχεια αναλαμβάνει δράση όταν συμβαίνουν αυτά τα συμβάντα.
Ο χειριστής Tyk πραγματοποιεί τις κατάλληλες κλήσεις API στον πίνακα εργαλείων Tyk για να δημιουργήσει, να διαγράψει ή να τροποποιήσει τους ορισμούς και τις πολιτικές ασφαλείας του Tyk API. Σε αυτήν την περίπτωση, οι προσαρμοσμένοι πόροι ονομάζονται εύστοχα APIDefinition και SecurityPolicy.
Αυτό επιτρέπει στις ομάδες να διαμορφώσουν την πύλη και να επωφεληθούν από την εντυπωσιακή συλλογή ενδιάμεσων λογισμικών του Tyk ορίζοντας απλώς έναν ορισμό API και αναπτύσσοντάς τον στο Kubernetes. Με μερικές γραμμές yaml, οι ομάδες θα μπορούσαν να δημιουργήσουν έναν διακομιστή μεσολάβησης από τους κεντρικούς υπολογιστές πύλης στην υπηρεσία τους. Εάν πρόσθεταν μερικά ακόμη, θα μπορούσαν να λάβουν επικύρωση διακριτικού JWT. Προσθέστε μερικά ακόμη, και είχαν ένεση κεφαλίδας ίχνους.
Το καλύτερο από όλα, αυτό έγινε μέσω ενός υπάρχοντος προτύπου API και μοντέλου ανάπτυξης στο Kubernetes. Δεν χρειάζεται να προσθέσετε κάτι νέο! Οι ομάδες ήταν ευχαριστημένες επειδή διατήρησαν την αυτονομία και την πρακτορεία τους, και ήμασταν ευχαριστημένοι ως ομάδα υποστήριξης επειδή μπορούσαμε να μειώσουμε την πολυπλοκότητα και τον φόρτο συντήρησης που περιβάλλουν τα συστήματά μας.
Βάζοντάς τα όλα μαζί
Ας δούμε ένα διάγραμμα υψηλού επιπέδου που περιγράφει λεπτομερώς τη ροή ενός αιτήματος και, στη συνέχεια, μπορούμε να βουτήξουμε σε ένα παράδειγμα του πώς μοιάζει ένας από αυτούς τους πόρους ορισμού API.
Όταν ένας πελάτης ζητά ένα από τα API μας, πρώτα δρομολογείται σε ένα σημείο παρουσίας CloudFront που βρίσκεται πιο κοντά του. Εδώ εφαρμόζουμε το AWS WAF και τους σχετικούς κανόνες του τείχους προστασίας και τους ενσωματώνουμε στην υπηρεσία ανίχνευσης bot. Επιπλέον, το CloudFront μας έχει διαμορφωθεί για να αποθηκεύει αιτήματα προσωρινής αποθήκευσης με βάση τις κεφαλίδες απόκρισης backend, επιτρέποντάς μας να παρέχουμε ένα επίπεδο κρυφής μνήμης υψηλής απόδοσης στους πελάτες μας.
Μόλις το αίτημα περάσει μέσω του CloudFront, προωθείται σε έναν εξισορροπητή φόρτου εφαρμογής που βρίσκεται μπροστά στην ανάπτυξη της πύλης Tyk. Το Tyk εφαρμόζει οποιοδήποτε διαμορφωμένο ενδιάμεσο λογισμικό και στη συνέχεια, με βάση τον τομέα και τη διαδρομή του αιτήματος, προωθεί το αίτημα στην καθορισμένη υπηρεσία ανάντη.
Ορισμοί Tyk Operator και API
Εντάξει μια χαρά! Βλέπουμε λοιπόν πώς δρομολογούνται τα αιτήματα στις υπηρεσίες μέσω του Tyk Gateway, αλλά πώς ξέρει η πύλη πού να δρομολογήσει οποιοδήποτε μεμονωμένο αίτημα; Εδώ μπαίνουν στο παιχνίδι ο Tyk Operator και οι ορισμοί του API. Ρίξτε μια ματιά στο παρακάτω διάγραμμα:
Ένας προγραμματιστής ορίζει έναν ορισμό API Tyk και στη συνέχεια τον αναπτύσσει στο σύμπλεγμα. Ο τελεστής Tyk, ο οποίος είναι εγγεγραμμένος σε συμβάντα συμπλέγματος που περιλαμβάνουν ορισμούς API, βλέπει ότι ένας νέος ορισμός API έχει προστεθεί στο σύμπλεγμα. Ο χειριστής αναλύει την προδιαγραφή ορισμού API και κάνει τις αντίστοιχες αλλαγές στην πύλη μέσω κλήσεων API του πίνακα εργαλείων. Στη συνέχεια, η πύλη θα επαναφορτωθεί με τη νέα διαδρομή API διαθέσιμη σχεδόν αμέσως.
Σε αυτό το σημείο, ένας οξυδερκής αναγνώστης μπορεί να ρωτήσει πώς εμποδίζετε δύο διαφορετικές ομάδες να χρησιμοποιήσουν την ίδια διαδρομή για να δρομολογήσουν ένα αίτημα. Σε τελική ανάλυση, εάν οι ομάδες έχουν την αυτονομία να αναπτύξουν αυτούς τους πόρους, τι μπορεί να εμποδίσει πολλές ομάδες να διεκδικήσουν την ίδια διαδρομή;
Αυτή είναι μια μεγάλη ερώτηση, και δεν θα την απαντήσω…προς το παρόν, πάντως. Είναι το θέμα μιας άλλης ανάρτησης αυτής της σειράς, οπότε θα πρέπει να επιστρέψετε για να μάθετε περισσότερα 😀.
Ορισμός API – ένα παράδειγμα
Εν πάση περιπτώσει, υποσχέθηκα ότι θα σας δείξω ένα παράδειγμα Ορισμός APIοπότε ας πάμε σε αυτό:
apiVersion: tyk.tyk.io/v1alpha1 kind: ApiDefinition metadata: name: user-delete spec: active: true name: user-delete protocol: http domain: http://my-domain.com proxy: listen_path: /api/v1/users/delete strip_listen_path: true target_url: https://my-upstream-service.com/users/delete jwt_policy_field_name: pol # The id for the policy to apply for all requests to this endpoint jwt_default_policies: ["my-policy"] # jwt_source contains the base64 encoded url for the jwks endpoint. jwt_source: >- "my-jwks-endpoint-b64-encoded" jwt_signing_method: rsa # jwt claim containing the consumer id jwt_identity_base_field: sub active: true auth: auth_header_name: Authorization enable_jwt: true
Στον παραπάνω ορισμό, μπορείτε να δείτε ότι αναπτύσσουμε μια διαδρομή για το /api/v1/users/delete.
Τα αιτήματα σε αυτήν τη διαδρομή θα αποστέλλονται με μεσολάβηση στο target_url. Ως μέρος αυτού του αιτήματος, ενεργοποιούμε την επικύρωση jwt για το διακριτικό στην κεφαλίδα εξουσιοδότησης. Μπορούμε να διαμορφώσουμε την επικύρωση διακριτικού παρέχοντας ένα τελικό σημείο jwks ή ένα κλειδί υπογραφής στο jwt_source και κάποια πρόσθετη διαμόρφωση σχετικά με τις ενσωματωμένες αξιώσεις.
Τώρα, κάθε αίτημα σε αυτό το τελικό σημείο σε αυτήν τη διαδρομή πρέπει να περιέχει ένα έγκυρο, μη ληγμένο διακριτικό στην κεφαλίδα εξουσιοδότησης και το μόνο που έπρεπε να κάνουμε ήταν να προσθέσουμε κάποια ελάχιστη διαμόρφωση.
Αυτό είναι! Χρησιμοποιώντας απλούς ορισμούς όπως αυτός, οι ομάδες μπορούν να ζητήσουν και να λάβουν μια διαδρομή API ακολουθώντας τις καλύτερες πρακτικές ασφάλειας, αξιοπιστίας και απόδοσης. Δεν χρειάζεται να κάνετε περιστροφή του CloudFront ή πρόσθετων εξισορροπητών φορτίου. Δεν χρειάζεται να γράψετε προσαρμοσμένα στοιχεία μεσαίου επιπέδου. Απλώς γράψτε ένα μικρό αρχείο yaml και είστε έτοιμοι.
Όπως μπορείτε να πείτε, είμαστε ενθουσιασμένοι με το Tyk και υπάρχουν πολλά περισσότερα που θα θέλαμε να μοιραστούμε. Μείνετε συντονισμένοι σε αυτή τη σειρά για τα ακόλουθα άρθρα:
Μέρος 2: Βελτίωση της εμπειρίας προγραμματιστών με γραφήματα βιβλιοθήκης Tyk και πηδαλίου
Μέρος 3: Επιβολή πολιτικής API με την Tyk και την Kyverno
Μέρος 4: Καταμερισμός της κυκλοφορίας σε πολλές πύλες με κοινή χρήση API Tyk
