סקירה כללית של Cloud Service Mesh עם שירותי gRPC בלי שרת Proxy
במדריך הזה מופיע סקירה כללית של הארכיטקטורה של Cloud Service Mesh עם שירותי gRPC ללא proxy, כולל תרחישי שימוש ודפוסי ארכיטקטורה.
מישור הבקרה המנוהל של Cloud Service Mesh מאפשר ניתוב גלובלי, איזון עומסים ומעבר לגיבוי אזורי לתרחישי שימוש ב-Service mesh ובאיזון עומסים. ההגדרה הזו כוללת פריסות שמשלבות שרתי proxy מסוג sidecar ושרתי proxy מסוג gateway. התמיכה ב-Cloud Service Mesh לאפליקציות gRPC בלי שרת Proxy מציעה מודל פריסה נוסף שבו אפליקציות gRPC יכולות להשתתף ב-Service mesh בלי להזדקק ל-קובץ עזר חיצוני.
בדוגמה טיפוסית, לקוח gRPC יוצר חיבור לשרת gRPC שמארח את הלוגיקה של ה-backend. Cloud Service Mesh מספק ללקוחות gRPC מידע על השרתים שאליהם צריך לפנות, על אופן איזון העומסים של בקשות למספר מופעים של שרת ועל הפעולות שצריך לבצע לגבי בקשות אם השרת לא פועל.
סקירה מלאה על אופן הפעולה של Cloud Service Mesh זמינה במאמר סקירה כללית על Cloud Service Mesh.
איך Cloud Service Mesh עובד עם אפליקציות gRPC
Cloud Service Mesh מגדיר לקוחות gRPC עם גרסת gRPC נתמכת, בדומה להגדרת פרוקסי מסוג sidecar כמו Envoy. עם זאת, לאפליקציות gRPC ללא proxy שמחוברות ישירות ל-Cloud Service Mesh לא נדרשים שרתי proxy מסוג sidecar. במקום זאת, Cloud Service Mesh משתמש בממשקי xDS API בקוד פתוח כדי להגדיר ישירות אפליקציות gRPC. אפליקציות gRPC האלה פועלות כלקוחות xDS, ומתחברות למישור הבקרה הגלובלי של Cloud Service Mesh. אחרי שהם מתחברים, אפליקציות gRPC מקבלות הגדרה דינמית ממישור הבקרה, שמאפשרת גילוי נקודות קצה, איזון עומסים, מעבר לגיבוי אזורי ובדיקות תקינות. הגישה הזו מאפשרת דפוסי פריסה נוספים של Cloud Service Mesh.
באיור הראשון, Service mesh מופעלת באמצעות קובץ עזר חיצוני.
כדי להגדיר שרת proxy מסוג קובץ עזר חיצוני, Cloud Service Mesh משתמש בממשקי xDS API. הלקוחות מתקשרים עם השרת דרך ה-proxy של ה-sidecar.
באיור השני, Service mesh מופעלת ללא קובץ עזר חיצוני באמצעות לקוח gRPC בלי שרת Proxy.
אם אתם פורסים רק שירותי gRPC שמערכת Cloud Service Mesh מגדירה, אתם יכולים ליצור רשת שירותים בלי לפרוס פרוקסי בכלל. כך קל יותר להוסיף יכולות של Service mesh לאפליקציות gRPC.
רזולוציית שם
התרת שמות פועלת בפריסות ללא שרת proxy בדרכים הבאות:
- מגדירים את
xdsכסכימת פתרון השמות בערוץ הלקוח של gRPC כשמתחברים לשירות. הפורמט של ה-URI של היעד הואxds:///hostname:port. אם לא מציינים את היציאה, ערך ברירת המחדל הוא 80 – לדוגמה, ב-URI של היעדxds:///example.hostname. - לקוח gRPC מבצע התאמת נתונים (resolve) של
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 הן שלוש כללים שונים.
פתרון שמות עם סוגי פריסה שונים
סכמת תרגום השמות שונה בפריסות בלי שרת Proxy ובפריסות שמשתמשות בשרתי proxy של Envoy.
לקוח gRPC משתמש בסכימת זיהוי השם xds כדי להתחבר לשירות, וכך הלקוח יכול לקבל את הגדרת השירות מ-Cloud Service Mesh. לאחר מכן, לקוח gRPC מתקשר ישירות עם שרת gRPC.
אפשר לשלב בין דפוסי פריסה של קובץ עזר חיצוני ושל בלי שרת Proxy כדי להגדיל את הגמישות. שילוב של תבניות שימושי במיוחד כשהארגון והרשת תומכים בכמה צוותים עם דרישות שונות לגבי תכונות, צרכים תפעוליים וגרסאות gRPC.
באיור הבא, גם לקוחות gRPC ללא proxy וגם לקוחות gRPC עם proxy מסוג sidecar מתקשרים עם שרת gRPC. לקוחות gRPC עם קובצי Proxy מסוג sidecar משתמשים בסכימת פתרון השמות dns.
תרחישים לדוגמה
תרחישי השימוש הבאים יעזרו לכם להבין מתי כדאי להשתמש ב-Cloud Service Mesh עם אפליקציות gRPC בלי שרת Proxy. הפריסה יכולה לכלול אפליקציות gRPC בלי שרת Proxy, אפליקציות gRPC עם קובץ עזר חיצוני או שילוב של שניהם.
יעילות משאבים ב-Service mesh רחבת היקף
אם רשת השירותים שלכם כוללת מאות או אלפי לקוחות ושרתי קצה עורפיים, יכול להיות שתגלו שצריכת המשאבים הכוללת מהפעלת פרוקסי מסוג sidecar מתחילה להצטבר. כשמשתמשים באפליקציות gRPC ללא proxy, לא צריך להוסיף שרתי proxy מסוג sidecar לפריסה. גישה ללא שרת proxy יכולה להוביל לשיפור היעילות.
אפליקציות gRPC עם ביצועים גבוהים
בתרחישי שימוש מסוימים, כל אלפית שנייה של זמן האחזור של הבקשה והתגובה חשובה. במקרה כזה, יכול להיות שתהיה לכם השהיה מופחתת אם תשתמשו באפליקציית gRPC בלי שרת Proxy, במקום להעביר כל בקשה דרך קובץ עזר חיצוני בצד הלקוח, ואולי גם דרך קובץ עזר חיצוני בצד השרת.
Service mesh לסביבות שבהן אי אפשר לפרוס פרוקסי מסוג sidecar
בסביבות מסוימות, יכול להיות שלא תוכלו להריץ שרת proxy מסוג קובץ עזר חיצוני כתהליך נוסף לצד אפליקציית הלקוח או השרת. או שלא תוכלו להגדיר את מחסנית הרשת של המכונה כדי ליירט בקשות ולהפנות אותן מחדש – למשל, באמצעות iptables.
במקרה כזה, אפשר להשתמש ב-Cloud Service Mesh עם אפליקציות gRPC ללא proxy כדי להוסיף לאפליקציות gRPC יכולות של רשת שירותים.
Service mesh הטרוגני
מכיוון שאפליקציות gRPC ללא שרת Proxy ו-Envoy מתקשרות עם Cloud Service Mesh, רשת השירותים יכולה לכלול את שני מודלי הפריסה. הכללת שני המודלים מאפשרת לכם לענות על הצרכים התפעוליים, הביצועיים והפונקציונליים הספציפיים של אפליקציות שונות ושל צוותי פיתוח שונים.
מעבר מ-service mesh עם שרתי proxy ל-mesh בלי שרתי proxy
אם כבר יש לכם אפליקציית gRPC עם שרת proxy מסוג sidecar שמוגדר ב-Cloud Service Mesh, אתם יכולים לעבור לאפליקציית gRPC ללא שרת proxy.
כשלקוח gRPC נפרס עם שרת proxy מסוג קובץ עזר חיצוני, הוא משתמש ב-DNS כדי לפתור את שם המארח שהוא מתחבר אליו. שרת ה-proxy מסוג sidecar מיירט את התעבורה כדי לספק יכולות של Service Mesh.
כדי להגדיר אם לקוח gRPC ישתמש בנתיב בלי שרת Proxy או בנתיב קובץ עזר חיצוני כדי לתקשר עם שרת gRPC, צריך לשנות את סכמת תרגום השם (name resolution) שבה הוא משתמש. לקוחות בלי שרת Proxy משתמשים בסכימת xds לתרגום שם, בעוד שקובץ עזר חיצוני מסוג proxy משתמשים בסכימת dns לתרגום שם. יכול להיות שחלק מלקוחות gRPC ישתמשו אפילו בנתיב בלי שרת Proxy כשהם מתקשרים עם שרת gRPC אחד, אבל ישתמשו בנתיב של קובץ עזר חיצוני כשהם מתקשרים עם שרת gRPC אחר. כך תוכלו לעבור בהדרגה לפריסה בלי שרת Proxy.
כדי להעביר מ-service mesh עם שרתי proxy ל-mesh בלי שרתי 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 לא יכול להשתמש בסכימת פתרון השמותxds.בכל הפריסות של Cloud Service Mesh, סכמת איזון העומסים של שירות לקצה העורפי צריכה להיות
INTERNAL_SELF_MANAGED.
בק-אנד
בשרתי קצה מתארחים מופעים של שרת gRPC. אתם יכולים להשתמש בקבוצות מנוהלות או לא מנוהלות של מכונות ב-Compute Engine ובקבוצות אזוריות של נקודות קצה ברשת ב-Google Kubernetes Engine כשרתי קצה עורפיים לאירוח של מופעי שרת gRPC.
המאמרים הבאים
- בסקירה הכללית מוסבר על ממשקי API לניתוב שירותים ואיך הם פועלים.
- כדי להתכונן להגדרת Cloud Service Mesh עם אפליקציות gRPC בלי שרת Proxy, אפשר לעיין במאמר הכנה להגדרה עם Envoy ועומסי עבודה בלי שרת Proxy.
- מידע על המגבלות שחלות על פריסות gRPC בלי שרת Proxy זמין במאמר מגבלות ב-gRPC בלי שרת Proxy.