gRPC

gRPC הוא מסגרת Remote Procedure Call שעושה משהו פשוט בצורה מטעה: היא מאפשרת לך לקרוא לפונקציה במחשב אחר כאילו היא רצה מקומית.

אתה קורא לפונקציה. היא רצה במחשב אחר. הרשת נעלמת.

זוהי ההבטחה של RPC, ו-gRPC — שפותח במקור על ידי Google — מקיים אותה עם תשתית מודרנית: HTTP/2 לחיבורים יעילים, Protocol Buffers לסריאליזציה בינארית קומפקטית, ויצירת קוד אוטומטית שנותנת לך פונקציות מוקלדות ממשיות לקרוא להן — במקום בקשות HTTP גולמיות לבנות.

הבעיה שgRPC פותר

אפליקציות מודרניות הן אוספים של שירותים שמדברים אחד עם השני. בקשת משתמש אחת עשויה לגעת באימות, פרופילי משתמשים, מלאי, תשלומים, משלוח, והתראות. זה שישה קריאות רשת לפני שקורה משהו שימושי.

עם REST, כל קריאה משמעה:

• בניית בקשת HTTP
• סריאליזציה של נתונים ל-JSON
• שליחת בייטים דרך הרשת
• ניתוח JSON בצד השני
• טיפול בשגיאות ידנית
• חזרה על זה לכל קריאה בודדת

ניתוח JSON הוא יקר. פרוטוקולי טקסט מסורבלים. HTTP/1.1 דורש חיבור חדש לכל בקשה. REST לא מגדיר רשמית מה שירות מקבל או מחזיר — אתה מקווה שהתיעוד מדויק.

gRPC מחליף את כל זה בפעולה אחת פשוטה: קריאה לפונקציה.

Protocol Buffers: החוזה

אתה מגדיר את השירות שלך בקובץ .proto:

syntax = "proto3";

service UserService {
    rpc GetUser (GetUserRequest) returns (User);
    rpc ListUsers (ListUsersRequest) returns (stream User);
    rpc CreateUser (CreateUserRequest) returns (User);
}

message User {
    string id = 1;
    string name = 2;
    string email = 3;
    int32 age = 4;
}

message GetUserRequest {
    string id = 1;
}

זהו חוזה. המהדר קורא אותו ומייצר קוד ממשי — קוד לקוח שקורא לשיטות אלה, ממשקי שרת שמממשים אותן. ב-Go, Python, Java, C++, או עוד תריסר שפות אחרות.

מספרי השדה (= 1, = 2) הם מזהים יציבים. לעולם אל תשנה אותם. הוסף שדות חדשים, אבל אל תמספר מחדש את הישנים. כך gRPC מטפל בגרסאות מבלי לשבור לקוחות קיימים.

הפורמט הבינארי קטן פי 3-10 מ-JSON ומהיר הרבה יותר לסריאליזציה. השירותים שלך מבלים פחות זמן בניתוח נתונים ויותר זמן בעבודה שימושית.

HTTP/2: חיבור אחד, קריאות רבות

gRPC בנוי על HTTP/2, שפותר חוסר יעילות בסיסי ב-HTTP/1.1.

עם HTTP/1.1, כל בקשה צריכה חיבור משלה — או שאתה מחכה שהבקשה הקודמת תסתיים. שירות שמבצע 100 קריאות לשירות אחר צריך 100 חיבורים, או המתנה סדרתית.

HTTP/2 מרבב הרבה בקשות על גבי חיבור אחד. חיבור TCP אחד בין שני שירותים מטפל בכל התקשורת שלהם. כותרות מתכווצות. מסגור בינארי מתיישב עם הפורמט הבינארי של Protocol Buffers.

התוצאה המעשית: פחות השהייה, פחות משאבים, תפוקה גבוהה יותר.

ארבע דרכים לתקשר

Unary: בקשה אחת, תגובה אחת. הדפוס המוכר.

rpc GetUser (GetUserRequest) returns (User);

Server streaming: בקשה אחת, תגובות רבות. השרת שולח תוצאות כשהן הופכות זמינות, במקום לגרום לך לחכות לכולן.

rpc ListUsers (ListUsersRequest) returns (stream User);

Client streaming: בקשות רבות, תגובה אחת. העלה נתונים בחתיכות, קבל סיכום בסיום.

rpc CreateUsers (stream CreateUserRequest) returns (CreateUsersResponse);

Bidirectional streaming: שני הצדדים שולחים מתי שרוצים. אפליקציות צ׳אט, עריכה שיתופית, סנכרון בזמן אמת.

rpc Chat (stream ChatMessage) returns (stream ChatMessage);

REST נותן לך בקשה-תגובה. gRPC נותן לך ארבעה דפוסים, שנבחרים לכל שיטה בהתאם למה שהנתונים באמת צריכים.

פסקי זמן שמתפשטים

הנה משהו אלגנטי: פסקי הזמן של gRPC זורמים דרך המערכת.

שירות A קורא לשירות B עם פסק זמן של 2 שניות. שירות B קורא לשירות C. שירות C יודע שירש את פסק הזמן הזה — הוא יכול לבדוק כמה זמן נותר. אם פסק הזמן פקע, כולם מפסיקים לעבוד.

לא עוד חישוב תגובה שאף אחד לא יקבל כי המתקשר המקורי ויתר. פסק הזמן אינו רק עניין של הלקוח; זהו הקשר משותף שמונע עבודה מבוזבזת.

הפשרות

לא ניתן להשתמש ב-curl עליו. תעבורת gRPC היא בינארית. אתה צריך כלים מיוחדים לבדוק אותה. REST מנצח מבחינת יכולת ניפוי שגיאות.

דפדפנים לא יכולים לדבר עמו באופן ישיר. gRPC-Web קיים אך דורש פרוקסי. לתקשורת דפדפן-שרת, REST או GraphQL נשארים בחירות טובות יותר.

עקומת הלמידה היא אמיתית. Protocol Buffers, יצירת קוד, סמנטיקה של סטרימינג — יש יותר ללמוד מ״שלח JSON לכתובת URL״.

כמה רשתות שונאות אותו. פרוקסים ארגוניים שבודקים תעבורת HTTP עשויים שלא לטפל היטב ב-HTTP/2 או בפרוטוקולים בינאריים.

אלה אינן סיבות להימנע מ-gRPC. אלה סיבות להשתמש בו היכן שהוא מצטיין: תקשורת שירות-לשירות בתוך התשתית שלך.

אבטחה

gRPC תומך ב-TLS להצפנת תעבורה, אימות מבוסס-טוקן דרך מטאדאטה (כמו כותרות HTTP), ו-TLS הדדי שבו גם הלקוח וגם השרת מאמתים תעודות. Interceptors — middleware של gRPC — מטפלים באימות, רישום, מדדים ומעקב מבלי לזהם את לוגיקת השירות שלך.

מתי להשתמש ב-gRPC

השתמש בו עבור: מיקרו-שירותים שמדברים אחד עם השני, סטרימינג בזמן אמת, מערכות רב-שפתיות שבהן שירותים משתמשים בשפות תכנות שונות, כל מקום שביצועים חשובים ואתה שולט בשני הקצוות.

אל תשתמש בו עבור: ממשקי API פונים לדפדפן, ממשקי API ציבוריים שבהם לא ניתן לשלוט בלקוחות, מצבים שבהם פשטות עולה על ביצועים.

מערכות רבות משתמשות בשניהם. gRPC לתקשורת פנימית שבה יעילות חשובה. REST עבור ה-API הציבורי שבו תאימות חשובה.

התובנה המרכזית

gRPC מצליח כי הוא גורם לרשת להרגיש כאילו היא לא שם. אתה מגדיר חוזה. המהדר מייצר קוד. אתה קורא לפונקציות. הן מתבצעות במחשבים אחרים.

המורכבות של מערכות מבוזרות לא נעלמת — עדיין צריך לטפל בכשלים, בפסקי זמן, ובזמינות חלקית. אבל הנטל המכאני של תקשורת רשת כן נעלם. מה שנשאר הוא העבודה האמיתית: מימוש הלוגיקה שהשירותים שלך קיימים לבצע.

שאלות נפוצות על gRPC

כיצד gRPC משתווה לביצועי REST?

מדידות בעולם האמיתי מראות בדרך כלל ש-gRPC מספק תפוקה גבוהה פי 5-10 והשהייה נמוכה משמעותית בהשוואה ל-API REST מבוסס-JSON. הרווחים מגיעים מסריאליזציה בינארית (נתונים קטנים יותר, ניתוח מהיר יותר), ריבוב HTTP/2 (חיבור אחד מטפל בהכל), ודחיסת כותרות. ההבדל חשוב ביותר לקריאות פנימיות בתדירות גבוהה.

האם אני יכול להשתמש ב-gRPC מדפדפן אינטרנט?

לא ישירות. דפדפנים לא תומכים ב-HTTP/2 trailers שgRPC דורש. gRPC-Web מספק פתרון עוקף באמצעות פרוקסי שמתרגם בין gRPC-Web ל-gRPC מקורי, אבל יש לו מגבלות — אין client streaming או bidirectional streaming. ללקוחות דפדפן, REST או GraphQL הם בדרך כלל בחירות טובות יותר.

מה קורה אם אני צריך לשנות את הגדרות Protocol Buffer שלי?

הוסף שדות חדשים בחופשיות — לקוחות קיימים מתעלמים משדות שהם לא מזהים. לעולם אל תשנה מספרי שדה; הם מזהים קבועים. לעולם אל תסיר שדות בצורה שמשברת תאימות; סמן אותם כמיושנים במקום. עמידה בכללים אלה מאפשרת לך לפתח ממשקי API מבלי לשבור לקוחות קיימים.

האם אני צריך Protocol Buffers כדי להשתמש ב-gRPC?

Protocol Buffers הוא פורמט הסריאליזציה המוגדר כברירת מחדל והמומלץ, אבל gRPC תומך טכנית בפורמטים אחרים כמו JSON. עם זאת, שימוש ב-JSON מבטל חלק גדול מיתרון הביצועים של gRPC. השילוב של gRPC + Protocol Buffers הוא המקום שבו מופיעים היתרונות האמיתיים.