הבנת מושגים ב-gRPC, מקרים של שימוש, ופרקטיות הטובות ביותר

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

עם הגידול בגודל הנתונים, יש לנו פעילויות כמו סידור, פירוק ועלויות מעבר נוספות לזה. אם כי אנו לא מודאגים ממשאבי המחשב, העיכוב נעשה נטלה. אנו צריכים לצמצם על המעבר. פיתוחו של הרבה פרוטוקולי תקשורת בעבר כדי לטפל בזה. SOAP היה משועמם, ו-REST הוא גרסה מחוקקת אך אנו זקוקים למסגרת יעילה אף יותר. זה המקום שבו קראיות שיטתיות רחוקות – RPC – באים.

במאמר זה, אנו נבין מהו RPC, והביצועים השונים של RPC, עם מיקוד על gRPC, שהוא הביצוע של Google של RPC. נשווה גם REST עם RPC ונבין מגוון רחב של היבטים של gRPC, כולל אבטחה, כלים ועוד רבים.

מה זה RPC?

RPC מסמל Remote Procedure Calls. ההגדרה בשמה עצמו. קריאות שיטתיות פשוט אומרות קריאות פונקציה / שיטה; זה המילה "רחוק" שעושה את כל ההבדל. מה אם אנו יכולים לבצע קריאת פונקציה מרוחקת?

בפשטות, אם פונקציה ממוקמת על שרת ועל מנת לקרוא לה מהצד הלקוח, האם נוכל לפשט את זה לקריאה פשוטה לשיטה/פונקציה? בעצם, מה ש-RPC עושה הוא להעניק את המראה ללקוח שהוא קורא לשיטה מקומית, אך במציאות, הוא קורא לשיטה במחשב רחוק שמספק את הפשטה משכבת הרשת. היופי בכך הוא שהחוזה מתוך עם מאוד קשיח ושקוף (נדון בכך מאוחר יותר בכתבה).

שלבים המעורבים בקריאת RPC:

זרימת קטלג RPC

ככה נראה תהליך רגיל של REST:

RPC מצמצם את התהליך למטה:

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

gRPC: מה, למה ואיך זה

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

ישנם יישומים רבים של RPC. הם הם:

• gRPC (גוגל)

• Thrift (Facebook)

• Finalge (Twitter)

גרסת ה-RPC של Google נקראת gRPC. הוצגה בשנת 2015 וכבר מאז משגשגת. זהו אחד המנועים המבוקשים ביותר לתקשורת בארכיטקטורת מיקרוסרביקות.

gRPC משתמש בבלוקי פרוטוקולים (פורמט הודעות פתוח) כשיטת התקשורת הברירת מחדל בין לקוחות לשרת. כמו כן, gRPC משתמש ב-HTTP/2 כפרוטוקול הברירת מחדל. יש עוד ארבעה סוגים של תקשורת שgRPC תומך בהם:

• טרמינרי [תקשורת לקוחות ושרת טיפוסית]

• זרימת לקוחות בצד

• זרימת שרת בצד

• שידור דו-כיווני

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

כאן, 'Person' היא הודעה שאנו רוצים להעביר (כחלק מבקשת/תשובה) המכילה שדות 'name' (סוג מחרוזת), 'id' (סוג מחרוזת) ו- ’email' (סוג מחרוזת). המספרים 1,2,3 מייצגים את מיקום הנתונים (כמו 'name', 'id' ו- 'has_ponycopter') כשהוא מתורגם לפורמט בינארי.

פעם יצרן ה-Protocol Buffer יצר את קבצי Protocol Buffer עם כל ההודעות, אנו יכולים להשתמש במהדר Protocol Buffer (בינארי) כדי לקמפל את קובץ Protocol Buffer הכתוב, מה שיתאפשר לייצר את כל המחלקות והשיטות הנחוצים לעבודה עם הודעה. לדוגמה, כפי שמוצג כאן, הקוד הנוצר (תלוי בשפה שנבחרה) ייראה כמו זה.

איך אנו מגדירים שירותים?

אנו צריכים להגדיר שירותים המשתמשים בהודעות למעלה להועבר/לקבל.

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

שירותים gRPC מוגדרים גם ב-Protocol Buffers והם משתמשים במילים המפתח "service" ו-"RPC" כדי להגדיר שירות.

תסתכל על תוכן הקובץ proto הבא:

כאן, HelloRequest ו-HelloResponse הם הודעות ו-HelloService מכשיר שירות RPC חד משמעי אחד בשם SayHello המקבל HelloRequest כקלט ומחזיר HelloResponse כפלט.

כפי שצוין, HelloService כיום מכיל רק RPC אחד חד-שלבי. אך יכול להכיל יותר מ-RPC אחד. כמו כן, יכול להכיל מגוון רחב של RPC (חד-שלבי/זרימה על צד הלקוח/זרימה על צד השרת/דו-כיווני).

כדי להגדיר RPC זרימה, כל מה שאתה צריך לעשות הוא לקדימת 'זרימה ' לפני הטיפוס הבקשה/תשובה,הגדרות proto של RPCs זרימה, וקוד מיוצר.

בקישור הקוד הנ"ל:

• streaming.proto: קובץ זה מוגדר על ידי המשתמש

• streaming.pb.go & streaming_grpc.pb.go: קבצים אלה מיוצרים אוטומטית על ידי הפעלת פרוטוקול המהדר פקודה.

gRPC Vs. REST

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

כדי להשוות, אנו זקוקים לפרמטרים. אז בואו נחלק את ההשוואה לפרמטרים הבאים:

• פורמט הודעה: פרוטוקולים באצ'בס vs JSON

  • מהירות הסריקה והפיכת סידורי במקרה של פרוטוקולים באצ'בס הרבה יותר טובה עבור כל גודל הנתונים (קטן/בינוני/גדול). תוצאות בדיקת העמדה. 

  • לאחר סריקה, JSON ניתן לקריאה על ידי בני אדם בעוד פרוטוקולים באצ'בס (בפורמט בינארי) אינם כאלה. לא בטוח אם זו חיסרון או לא מכיוון שלפעמים תרצה לראות את פרטי הבקשה בכלי הפיתוח של גוגל או בנושאי Kafka ובמקרה של פרוטוקולים באצ'בס אינך יכול להבין כלום. 

• תקשורת פרוטוקול: HTTP 1.1 מול HTTP/2T

  • REST מבוסס על HTTP 1.1; התקשורת בין לקוח REST לשרת דורשת חיבור TCP מבוסס שבתורו כולל ידית תלת צעדית. כשאנו מקבלים תגובה מהשרת על ידי שליחת בקשה מהלקוח, החיבור TCP אינו קיים לאחר מכן. חיבור TCP חדש צריך להתחיל על מנת לעבד בקשה נוספת. הקמת חיבור TCP על כל בקשה מוסיפה לעיכוב.

  • אז gRPC שמבוסס על HTTP 2 נתקל באתגר זה על ידי יצירת חיבור מתמשך. עלינו לזכור שחיבורים מתמשכים ב-HTTP 2 שונים מאלו ב-WebSockets שבהם חוט TCP נחטף וההעברת נתונים אינה מתועדת. בחיבור gRPC, ברגע שחיבור TCP מוקמת, היא משומשת שוב עבור מספר בקשות. כל הבקשות מזוג לקוח ושרת זהה מופרדות על חיבור TCP זה.

• רק דאגה לנתונים ולהיגיון: יצירת קוד כאןם בן ראשון

  • תכונות יצירת קוד מועשרות ב-gRPC דרך מהדר protoc הבנוי בתוכו. עם רשת APIs, חיוני להשתמש בכלי זר כגון Swagger לייצור אוטומטי של הקוד לבקשות API בשפות שונות.

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

• מהירות העברת נתונים

  • מאחר והפורמט הבינארי הוא הרבה יותר קל מפורמט JSON, מהירות העברת נתונים במקרה של gRPC גבוהה פי 7 עד 10 מזו של REST.

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

עכשיו שעשינו השוואה בין שני הממשקים: gRPC ו- REST. איזה להשתמש ומתי?

• בארכיטקטורת מיקרוסרביסים עם מיקרוסרביסים קלים רבים, שם יעילות ההעברת מידע היא ברורה, gRPC יהיה בחירה אידיאלית.

• אם יצירת קוד עם תמיכה במספר שפות היא דרישה, gRPC צריך להיות המסגרת המועדפת.

• באמצעות יכולות הזרם של gRPC, אפליקציות בזמן אמת כמו סחר או OTT יהנו מזה מאשר מצליחים באמצעות REST.

• אם פס תמסורת הוא מגבלה, gRPC יספק עיכוב זמן נמוך בהרבה ותוצאות תוך כדי הפעלה.

• אם פיתוח מהיר ואיטרציה במהירות גבוהה היא דרישה, REST צריך להיות אופציה מועדפת.

רעיונות של gRPC

בול טיפוס

למרות שהחיבור הקבוע פותר את בעיית העיכוב, הוא מעלה אתר בונה בצורה של בול טיפוס חדש. מאחר ו-gRPC (או HTTP2) יוצר חיבורים קבועים, אפילו בנוכחות בול טיפוס, הלקוח יוצר חיבור קבוע עם השרת שמאחורי הבול טיפוס. זה דומה למסחר דביק.

אנו יכולים להבין את הבעיה או האתגר דרך דגמא. וקיימים קוד וקבצי ׇפרויקטים ב: https://github.com/infracloudio/grpc-blog/tree/master/grpc-loadbalancing.

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

קרא עוד על בליינד אינטר בgRPC.

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

בנוסף, גם תומך לקוח מותאם אישית בליינד אינטר.

חוזה נקי

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

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

קחו בחשבון את מסד הנתונים הבא:

https://github.com/infracloudio/grpc-blog/tree/master/greet_app     

הלקוח משתמש במנבא (קוד מיוצר מקובץ proto) כדי ליצור אובייקט לקוח ולבצע קריאת פונקציה מרוחקת:

```sh

import greetpb "github.com/infracloudio/grpc-blog/greet_app/internal/pkg/proto"



cc, err := grpc.Dial(“<server-address>”, opts)

if err != nil {

    log.Fatalf("could not connect: %v", err)

}



c := greetpb.NewGreetServiceClient(cc)



res, err := c.Greet(context.Background(), req)

if err != nil {

    log.Fatalf("error while calling greet rpc : %v", err)

}

```

באופן דומה, השרת גם הוא משתמש באותו מנבא (קוד מיוצר מקובץ proto) כדי לקבל אובייקט בקשה וליצור אובייקט תגובה:

```sh

import greetpb "github.com/infracloudio/grpc-blog/greet_app/internal/pkg/proto"



func (*server) Greet(_ context.Context, req *greetpb.GreetingRequest) (*greetpb.GreetingResponse, error) {

 

  // לעשות משהו עם 'req'

 

   return &greetpb.GreetingResponse{

    Result: result,

      }, nil

}

```

שניהם משתמשים באותו מנבא שנוצר מקובץ proto הממוקם כאן.

והסטוב נוצר באמצעות פקודת מהדר proto שמתחת לה. 

```sh

protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative internal/pkg/proto/*.proto

```

בטחון

אימות והרשאה של gRPC פועלים בשני רמות:

• אימות/הרשאה ברמת השיחה בדרך כלל מתבצעת באמצעות טוקנים המופקדים במטדאטה כשהשיחה מתבצעת. דוגמא אימות באמצעות טוקן.

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

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

ממשקי ביניים

ב-REST, אנו משתמשים בממשקי ביניים למטרות רבות כמו:

• מגבלת קצב

• אימות לפני/אחרי בקשה/תגובה

• טיפול באיומים בטחוניים

אנו יכולים להשיג את אותו הדבר גם עם gRPC. השפה שונה ב-gRPC – הם מכונים מכשירים, אך הם מבצעים פעולות דומות.

בסניף ממשקי ביניים של מסד הנתונים 'greet_app', השלמנו מכשירים לתיעוד ומכשירים ל-Prometheus. 

תראו איך המכשירים מוגדרים לשימוש בחבילות Prometheus ותיעוד כאן.

אך אנו יכולים לשלב חבילות אחרות למכשירים למטרות כמו מניעת התנדנדות והחזרה (כדי להתמודד עם ייחודים), מעקב, אפילו אימות, וכן הלאה.

ממשקי ביניים המתמכים על ידי ממשק gRPC.

אריזה, גיבוב גרסאות ונוהלי קוד של קבצי Proto

אריזה

בואו נעקוב אחרי קטע האריזה בהענף האריזה.

ראשית, עליך להתחיל עם 'Taskfile.yaml', המשימה 'gen-pkg' אומרת 'protoc –proto_path=packaging packaging/*.proto –go_out=packaging'. זה אומר ש-‘protoc’ (המהדר) ימיר את כל הקבצים ב-‘packaging/*.proto’ לקבצים ‘go’ השווים על ידי התיוג ‘–go_out=packaging’ בספרייה ‘packaging’ עצמה.

שנית, בקובץ ‘processor.proto’, מוגדרים שני מסרים המכונים ‘CPU’ ו-‘GPU’. בעוד ש-CPU הוא מסר פשוט עם 3 שדות של סוגי נתונים מובנים מראש, GPU מצד שני כולל סוג נתונים מותאם אישית הנקרא ‘Memory’. ‘Memory’ הוא מסר נפרד ומוגדר בקובץ נפרד לגמרי.

אז איך משתמשים ב-‘Memory’ מסר בקובץ ‘processor.proto’? על ידי שימוש ב-ייבוא.

אפילו אם תנסה ליצור קובץ proto על ידי הפעלת המשימה 'gen-pkg' לאחר שציינת ייבוא, זה יזרוק שגיאה. שכן כברירת מחדל ‘protoc’ מניח ששני הקבצים ‘memory.proto’ ו-‘processor.proto’ נמצאים בחבילות שונות. לכן עליך לציין את אותה שם חבילה בשני הקבצים.

ה-‘go_package’ הלא-חובה מעיד על המהדר ליצור שם חבילה כמו ‘pb’ עבור קבצי go. אם היו צריכים להיווצר קבצי proto בשפה אחרת, השם של החבילה יהיה ‘laptop_pkg’.

גישור גרסאות

• יש שני סוגים של שינויים ב-gRPC: שינויים שבירה ושינויים לא שבירה.

• שינויים לא שבירה כוללים הוספת שירות חדש, הוספת שיטה חדשה לשירות, הוספת שדה לבקשה או תגובת proto, והוספת ערך ל-enum

• שינויים שבירה כמו שינוי שם שדה, שינוי סוג נתוני שדה, מספר שדה, שינוי שם או הסרה של חבילה, שירות או שיטות דורשים גרסאות של שירותים

• אופציונלי אריזה.

נוהלי קוד

• הודעת הבקשה חייבת להסתיים בבקשה `CreateUserRequest`

• הודעת התגובה חייבת להסתיים בבקשה `CreateUserResponse`

• במקרה שהודעת התגובה ריקה ניתן להשתמש באובייקט ריק `CreateUserResponse` או להשתמש ב-`google.protobuf.Empty`

• שם החבילה חייב להיות הגיוני וחייב להיות מוגדרת לפי גרסה, למשל: חבילה `com.ic.internal_api.service1.v1`

כלי עבודה

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

• protoc-gen-grpc-gateway – תוסף ליצירת שער REST API עבור gRPC. הוא מאפשר לנקודות gRPC להיות נקודות API REST ומבצע המרה מ-JSON ל-proto. בכללי, אתה מגדיר שירות gRPC עם תגיות מUSTOM והוא מאפשר גישה לשיטות gRPC דרך REST באמצעות בקשות JSON.

• protoc-gen-swagger — תוסף שותף עבור grpc-gateway. הוא מסוגל לייצר swagger.json על סמך ההערות המותאמות אישית הנדרשות ל-gRPC gateway. אפשר לייבא את הקובץ הזה ללקוח REST מבחירתך (כגון Postman) ולבצע שיחות API REST לשיטוטים שחשפת.

• protoc-gen-grpc-web — תוסף המאפשר למסך הקדמי שלנו לתקשר עם הרקע באמצעות שיחות gRPC. פוסט בלוג נפרד על כך בקרוב.

• protoc-gen-go-validators — תוסף המאפשר להגדיר כללי אימות עבור שדות הודעות proto. הוא מייצר שיטת שגיאות Validate() עבור הודעות proto שאפשר לקרוא ב-GoLang כדי לאמת האם הודעת ה-proto תואמת לציפיות הקדומות שלך.

• https://github.com/yoheimuta/protolint — תוסף להוספת כללי lint לקבצי proto

בדיקה באמצעות POSTMAN

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

שים לב: שירותי gRPC יכולים גם להיות בוצעו בדיקות מ-CLI באמצעות כלים כמו evans-cli. אך עבור כך נדרשת השלכה (אם לא מופעלת הנתיב לקובץ proto הוא נדרש) להיות מופעלת בשרתי gRPC. שינויים שצריך לעשות כדי להפעיל השלכה ואיך להיכנס למצב repl של evans-cli. לאחר כניסה למצב repl של evans-cli, שירותי gRPC יכולים להיות בוצעו בדיקות מ-CLI עצמו והתהליך מתואר בדף הגיטהב של evans-cli.

Postman יש גרסה בטא של בדיקת שירותי gRPC.

הנה השלבים של איך אפשר לעשות זאת:

1. פתח את Postman

2. עבור ל-‘APIs’ בסלולר משמאל

3. לחץ על סימן ‘+’ כדי ליצור API חדש: 

4. בחלונית הפתח, הזן את ‘שם’, ‘גרסה’ ו-‘פרטי תכנון’ ולחץ על יצירה [אלא אם כן אתה צריך לייבא ממקורות כמו github/bitbucket]. שלב זה רלוונטי אם אתה רוצה להעתיק ולהדביק את החוזה proto.

5. נוצרת ה-API שלך כמתואר להלן. לחץ על גרסה '1.0.0', עבור להגדרה והזן את חוזה ה-proto שלך.

6. זכור שהמיזוג לא עובד כאן, ולכן יהיה טוב יותר לשמור את כל ה-protos התלויים במקום אחד.

7. הצעדים לעיל יעזרו לשמור על חוזים לשימוש עתידי.

8. לאחר מכן לחץ על 'חדש' ובחר 'בקשת gRPC':

9. הזן את כתובת ה-URI ובחר את ה-proto מרשימת ה-APIs הנשמרים:

10. הזן את הודעת הבקשה שלך ולחץ 'פעל':

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

מסקנה

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

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

הדרך שבה Golang מוכיחה את עצמה כשפת קריאה שמאלית לצד השרת, gRPC מוכיחה את עצמה כמוותרת תקשורת מקובלת.