סקירה כללית על Cloud Service Mesh עם שירותי gRPC בלי שרת proxy
במדריך הזה נסביר על הארכיטקטורה של Cloud Service Mesh עם שירותי gRPC בלי שרת proxy, כולל תרחישים לדוגמה ותבניות ארכיטקטורה.
מישור הבקרה המנוהל של Cloud Service Mesh מאפשר ניתוב גלובלי, איזון עומסים ויתירות כשל אזורית לתרחישי שימוש של רשת Service Mesh ואיזון עומסים. זה כולל פריסות שמשלבות קובצי עזר חיצוניים ושרתי proxy של שערים. התמיכה של Cloud Service Mesh באפליקציות gRPC בלי שרת Proxy מציעה מודל פריסה נוסף, שבו אפליקציות gRPC יכולות להשתתף ברשת שירות בלי צורך בקובץ עזר חיצוני.
בדוגמה אופיינית, לקוח gRPC יוצר חיבור עם שרת gRPC שמארח את הלוגיקה של הקצה העורפי. Cloud Service Mesh מספק ללקוחות gRPC מידע על השרתים שאליהם צריך לפנות, איך לאזן את העומסים של הבקשות למספר מכונות של שרת ומה לעשות עם הבקשות אם השרת לא פועל.
בסקירה הכללית על Cloud Service Mesh מוסבר איך Cloud Service Mesh פועל.
איך Cloud Service Mesh פועל עם אפליקציות gRPC
Cloud Service Mesh מגדיר לקוחות gRPC עם גרסת gRPC נתמכת, בדומה לאופן שבו מוגדרים שרתי proxy של sidecar כמו Envoy. עם זאת, אפליקציות gRPC בלי שרת Proxy שמחוברות ישירות ל-Cloud Service Mesh לא צריכות קובצי עזר חיצוניים. במקום זאת, Cloud Service Mesh משתמש בממשקי API של xDS בקוד פתוח כדי להגדיר אפליקציות gRPC ישירות. אפליקציות ה-gRPC האלה פועלות כלקוחות xDS, ומתחברות למישור הבקרה הגלובלי של Cloud Service Mesh. אחרי שהן מתחברות, אפליקציות gRPC מקבלות הגדרה דינמית ממישור הבקרה, שמאפשרת גילוי נקודות קצה, איזון עומסים, יתירות כשל אזורית ובדיקות תקינות. הגישה הזו מאפשרת דפוסי פריסה נוספים של Cloud Service Mesh.
באיור הראשון, Service mesh מופעלת באמצעות קובץ עזר חיצוני.
כדי להגדיר קובץ עזר חיצוני, Cloud Service Mesh משתמש בממשקי xDS API. הלקוחות מתקשרים עם השרת באמצעות קובץ העזר החיצוני.
באיור השני, Service mesh מופעלת בלי קובץ עזר חיצוני באמצעות לקוח gRPC בלי שרת proxy.
אם אתם פורסים רק שירותי gRPC שמוגדרים על ידי Cloud Service Mesh, אתם יכולים ליצור רשת שירות בלי לפרוס שרתי proxy בכלל. כך קל יותר להוסיף יכולות של Service mesh לאפליקציות gRPC.
תרגום שם (Name resolution)
תרגום השם פועל בפריסות בלי שרת proxy בדרכים הבאות:
- כשמתחברים לשירות, מגדירים את
xdsכסכימת תרגום השם בערוץ הלקוח של gRPC. הפורמט של ה-URI של היעד הואxds:///hostname:port. אם לא מציינים את היציאה, ערך ברירת המחדל הוא 80 – לדוגמה, ב-URI של היעדxds:///example.hostname. - לקוח ה-gRPC פותר את ה-
hostname:portב-URI של היעד על ידי שליחת בקשה לשירות זיהוי מאזינים (LDS) אל Cloud Service Mesh. - Cloud Service Mesh מחפש את כללי ההעברה שהוגדרו עם יציאה תואמת. לאחר מכן, הוא מחפש את מפת URL התואמת לכלל מארח שתואם ל-
hostname:port. היא מחזירה את הגדרת הניתוב המשויכת ללקוח ה-gRPC.
כללי המארח שאתם מגדירים ב-Cloud Service Mesh צריכים להיות ייחודיים בכל מפות ה-URL. לדוגמה, example.hostname, example.hostname:80 ו-example.hostname:8080 הם כללים שונים.
תרגום שם (name resolution) עם סוגי פריסה שונים
סכמת תרגום השמות שונה בפריסות בלי שרת proxy ובפריסות שמשתמשות בשרתי proxy של Envoy.
לקוח ה-gRPC משתמש בסכימת תרגום השם (name resolution) של xds כדי להתחבר לשירות, וכך הלקוח יכול לקבל את הגדרת השירות מ-Cloud Service Mesh. לאחר מכן, לקוח ה-gRPC מתקשר ישירות עם שרת ה-gRPC.
כדי להגביר את הגמישות, אפשר לשלב בין דפוסי פריסה של קובץ עזר חיצוני ושל פריסה בלי שרת proxy. שילוב של דפוסים שימושי במיוחד כשהארגון והרשת שלכם תומכים בכמה צוותים עם דרישות שונות לתכונות, צרכים תפעוליים וגרסאות gRPC.
באיור הבא, גם לקוחות gRPC בלי שרת proxy וגם לקוחות gRPC עם קובץ עזר חיצוני מתקשרים עם שרת gRPC. לקוחות gRPC עם קובצי עזר חיצוניים משתמשים בסכימת תרגום השם (name resolution) dns.
תרחישים לדוגמה
תרחישי השימוש הבאים יעזרו לכם להבין מתי כדאי להשתמש ב-Cloud Service Mesh עם אפליקציות gRPC ללא שרת proxy. הפריסה יכולה לכלול אפליקציות gRPC בלי שרת Proxy, אפליקציות gRPC עם קובצי עזר חיצוניים או שילוב של שניהם.
יעילות המשאבים ב-Service mesh בקנה מידה גדול
אם Service mesh שלכם כולל מאות או אלפי לקוחות ורכיבי backend, יכול להיות שצריכת המשאבים הכוללת מהפעלת קובצי עזר חיצוניים תתחיל להצטבר. כשמשתמשים באפליקציות gRPC בלי שרת proxy, לא צריך להוסיף קובצי עזר חיצוניים לפריסה. גישה בלי שרת proxy יכולה לשפר את היעילות.
אפליקציות gRPC עם ביצועים גבוהים
בתרחישי שימוש מסוימים, כל אלפית שנייה של זמן אחזור בבקשה ובתגובה חשובה. במקרה כזה, יכול להיות שתהיה פחות זמן אחזור אם תשתמשו באפליקציית gRPC בלי שרת Proxy, במקום להעביר כל בקשה דרך קובץ עזר חיצוני בצד הלקוח, ואולי גם דרך קובץ עזר חיצוני בצד השרת.
Service mesh לסביבות שבהן אי אפשר לפרוס קובצי עזר חיצוניים
בסביבות מסוימות, יכול להיות שלא תוכלו להריץ קובץ עזר חיצוני כתהליך נוסף לצד אפליקציית הלקוח או השרת. יכול להיות גם שלא תוכלו להגדיר את מקבץ הרשת (network stack) של המכונה כדי ליירט בקשות ולהפנות אותן, למשל באמצעות iptables.
במקרה כזה, אתם יכולים להשתמש ב-Cloud Service Mesh עם אפליקציות gRPC בלי שרת proxy כדי להוסיף יכולות של רשת שירות לאפליקציות ה-gRPC.
רשת שירותים הטרוגנית
מכיוון שגם אפליקציות gRPC בלי שרת proxy וגם Envoy מתקשרות עם Cloud Service Mesh, רשת השירות יכולה לכלול את שני המודלים של הפריסה. השילוב של שני המודלים מאפשר לכם לענות על הצרכים התפעוליים, הביצועיים והפונקציונליים הספציפיים של אפליקציות שונות וצוותי פיתוח שונים.
מעבר מ-Service mesh עם שרתי proxy לרשת ללא שרתי proxy
אם כבר יש לכם אפליקציית gRPC עם קובץ עזר חיצוני שהוגדר על ידי Cloud Service Mesh, אתם יכולים לעבור לאפליקציית gRPC בלי שרת proxy.
כשפורסים לקוח gRPC עם קובץ עזר חיצוני, הוא משתמש ב-DNS כדי לזהות את שם המארח שאליו הוא מתחבר. קובץ העזר החיצוני מיירט את תעבורת הנתונים כדי לספק יכולות של Service mesh.
כדי להגדיר אם לקוח gRPC משתמש בנתיב בלי שרת Proxy או בנתיב של קובץ עזר חיצוני כדי לתקשר עם שרת gRPC, צריך לשנות את סכימת תרגום השם (name resolution) שבה הוא משתמש. לקוחות בלי שרת Proxy משתמשים בסכימת תרגום השם xds, ושרתי Proxy של קובצי עזר חיצוניים משתמשים בסכימת תרגום השם dns. יכול להיות שחלק מלקוחות gRPC ישתמשו בנתיב בלי שרת Proxy כשהם מתקשרים עם שרת gRPC אחד, אבל ישתמשו בנתיב של קובץ עזר חיצוני כשהם מתקשרים עם שרת gRPC אחר. כך אפשר לעבור בהדרגה לפריסה בלי שרת proxy.
כדי לעבור מרשת שירות עם שרתי proxy לרשת בלי שרתי proxy, צריך ליצור שירות חדש של Cloud Service Mesh שבו משתמש לקוח ה-gRPC בלי שרת proxy. אתם יכולים להשתמש באותם ממשקי API כדי להגדיר את Cloud Service Mesh לגרסאות הקיימות והחדשות.
ארכיטקטורה ומשאבים
מודל נתוני ההגדרות האישיות של שירותי gRPC בלי שרת Proxy מרחיב את מודל ההגדרות האישיות של Cloud Service Mesh, עם כמה תוספות ומגבלות שמתוארות במדריך הזה. חלק מהמגבלות האלה זמניות, כי gRPC בלי שרת proxy לא תומך בכל התכונות של Envoy, ואחרות נובעות מהשימוש ב-RPC. לדוגמה, אין תמיכה בהפניות אוטומטיות של HTTP שמשתמשות ב-gRPC. כדי להבין את מודל ההגדרות במדריך הזה, מומלץ להכיר את המושגים וההגדרות של Cloud Service Mesh.
בתרשים הבא מוצגים המשאבים שצריך להגדיר לאפליקציות gRPC בלי שרת proxy.
בדיקות תקינות
בדיקת תקינות של gRPC יכולה לבדוק את הסטטוס של שירות gRPC שפועל במכונה וירטואלית (VM) לקצה עורפי או בקבוצת נקודות קצה ברשת (NEG).
אם אי אפשר להשתמש בבדיקת תקינות של gRPC כי שרת ה-gRPC לא מטמיע את פרוטוקול בדיקת התקינות של gRPC, השתמשו בבדיקת תקינות של TCP במקום זאת. אל תשתמשו בבדיקת תקינות של HTTP, HTTPS או HTTP/2.
מידע נוסף זמין במאמרים בדיקת תקינות של gRPC ודגל נוסף לבדיקות תקינות של gRPC.
שירות לקצה העורפי
השירות לקצה העורפי מגדיר איך לקוח gRPC מתקשר עם שרת gRPC.
כשיוצרים שירות לקצה העורפי בשביל gRPC, מגדירים את שדה הפרוטוקול לערך GRPC.
אפליקציות gRPC יכולות לגשת לשירות לקצה העורפי שמוגדר עם פרוטוקול
GRPCגם דרך קובץ עזר חיצוני. במצב כזה, הלקוח של gRPC לא יכול להשתמש בסכימת תרגום השם (name resolution) שלxds.בכל הפריסות של Cloud Service Mesh, סכימת איזון העומסים של שירות הקצה העורפי חייבת להיות
INTERNAL_SELF_MANAGED.
בק-אנדים
מארחים של מכונות שרת gRPC. אתם יכולים להשתמש בקבוצות של מכונות מנוהלות או לא מנוהלות ב-Compute Engine ובקבוצות של נקודות קצה ברשת (NEG) באזורים ב-Google Kubernetes Engine כרכיבי backend לאירוח המכונות של שרת ה-gRPC.
המאמרים הבאים
- בסקירה הכללית מוסבר על ממשקי ה-API לניתוב שירותים ואיך הם פועלים.
- כדי להתכונן להגדרת Cloud Service Mesh עם אפליקציות gRPC בלי שרת Proxy, קראו את המאמר הכנה להגדרה עם Envoy ועומסי עבודה בלי שרת Proxy.
- במאמר מגבלות והגבלות ב-gRPC בלי שרת proxy מפורט מידע על המגבלות שחלות על פריסות של gRPC בלי שרת proxy.