JSON-RPC? קח REST מסובך

אני בטוח שהכותרת גרמה לתגובה בריאה - "טוב, זה התחיל שוב..." אבל הרשו לי ללכוד את תשומת לבכם למשך 5-10 דקות, ואשתדל לא לאכזב את ציפיותיכם.

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

כדי שיהיה ברור מה זה RPC, אני מציע לשקול את התקן JSON-RPC 2.0. עם REST אין בהירות. וזה לא אמור להיות. כל מה שאתה צריך לדעת על REST - לא ניתן להבחין בו HTTP.

בקשות RPC הן מהירות ויעילות יותר מכיוון שהן מאפשרות לך לבצע בקשות אצווה.

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

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

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

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

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

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

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

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

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

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

כעת נספור כמה בקשות REST ו-RPC "הולידו" בתשתית הנבדקת?

בקשות
תיבת דואר נכנס
לאחור
ל-DBMS
למטמון רך (Redis)
סך הכל

REST
1 / 32 *
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] במקרה הטוב (אם נעשה שימוש במטמון המקומי) בקשה אחת (אחת!), במקרה הרע 1 בקשות נכנסות.

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

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

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

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

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

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

בקשות RPC אמינות יותר מכיוון שהן יכולות לבצע בקשות אצווה בתוך עסקה אחת

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

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

אבל האם בקשות אצווה אמינות כפי שהן נראות? בואו נסתכל על מקרה: אנחנו יוצרים משתמש, מעשירים את הפרופיל שלו בתיאור כלשהו ושולחים לו SMS עם סוד להשלמת הרישום. הָהֵן. שלוש שיחות בבקשת אצווה אחת.

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

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

אוקיי, בואו נדמיין שהתאמצנו (!) וחשבנו על האפשרות מתי ניתן יהיה להשלים את הבקשה באופן חלקי בהצלחה. וננסה להשלים את השאר שוב לאחר מרווח זמן מסוים (איזה? האם החזית מחליטה?). אבל ההגרלה נשארה אותו הדבר. לבקשה לשלוח SMS יש סיכוי של 50/50 להיכשל שוב.

מסכים, מצד הלקוח השירות לא נראה אמין כמו שהיינו רוצים... מה עם REST?

REST משתמש שוב בקסם של HTTP, אבל עכשיו עם קודי תגובה. כאשר מתרחשת שגיאה 503 בשער ה-SMS, הקצה האחורי משדר שגיאה זו למאזן. המאזן מקבל שגיאה זו ומבלי לנתק את הקשר עם הלקוח, שולח את הבקשה לצומת אחר, אשר מעבד בהצלחה את הבקשה. הָהֵן. הלקוח מקבל את התוצאה הצפויה, והתשתית מאשרת את התואר הגבוה שלה "נגיש ביותר". המשתמש מרוצה.

ושוב זה לא הכל. המאזן לא קיבל סתם קוד תגובה של 503. כשמגיבים, לפי התקן, רצוי לספק קוד זה עם הכותרת "Retry-After". הכותרת מבהירה למאזן שלא כדאי להפריע לצומת זה במסלול זה לזמן מוגדר. והבקשות הבאות לשליחת SMS יישלחו ישירות לצומת שאין לו בעיות עם שער ה-SMS.

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

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

סף הכניסה ל-REST נמוך יותר

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

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

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

אבל לגבי RPC - אתה יכול. מספיק לקחת את המפרט שלו. אז אתה צריך JSON-RPC טיפש? או שזה עדיין מסובך REST? אתה תחליט.

אני מאוד מקווה שלא בזבזתי את זמנך.

מקור: www.habr.com