RoadRunner: PHP לא בנוי למות, או גולנג להצלה

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

בשנים האחרונות PHP התקדמה מאוד: אספן האשפה השתפר, רמת היציבות עלתה - כיום ניתן לכתוב דמונים וסקריפטים ארוכים ב-PHP ללא בעיות. זה אפשר לספירל סקאוט ללכת רחוק יותר: RoadRunner, בניגוד ל-PHP-FPM, לא מנקה זיכרון בין בקשות, מה שנותן רווח נוסף בביצועים (למרות שגישה זו מסבכת את תהליך הפיתוח). כרגע אנו מתנסים בכלי זה, אך אין לנו עדיין תוצאות לחלוק. כדי להפוך את ההמתנה להם למהנה יותר, אנו מפרסמים את התרגום של הודעת RoadRunner מ-Spiral Scout.

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

תהנו!

בעשר השנים האחרונות יצרנו אפליקציות לחברות מהרשימה פורצ'ן 500, ולעסקים עם קהל של לא יותר מ-500 משתמשים. כל הזמן הזה, המהנדסים שלנו פיתחו את ה-backend בעיקר ב-PHP. אבל לפני שנתיים, משהו השפיע רבות לא רק על הביצועים של המוצרים שלנו, אלא גם על המדרגיות שלהם - הכנסנו את Golang (Go) לערימת הטכנולוגיה שלנו.

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

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

סביבת הפיתוח היומית שלך ב-PHP

לפני שנדבר על איך אתה יכול להשתמש ב-Go כדי להחיות את מודל ה-PHP הגוססת, בואו נסתכל על סביבת הפיתוח המוגדרת כברירת מחדל של PHP.

ברוב המקרים, אתה מפעיל את היישום שלך באמצעות שילוב של שרת האינטרנט nginx ושרת PHP-FPM. הראשון משרת קבצים סטטיים ומפנה בקשות ספציפיות ל-PHP-FPM, בעוד ש-PHP-FPM עצמו מבצע קוד PHP. ייתכן שאתה משתמש בשילוב הפחות פופולרי של Apache ו-mod_php. אבל למרות שזה עובד קצת אחרת, העקרונות זהים.

בואו נסתכל כיצד PHP-FPM מבצעת קוד יישום. כשמגיעה בקשה, PHP-FPM מאתחל תהליך צאצא של PHP ומעביר את פרטי הבקשה כחלק מהמצב שלה (_GET, _POST, _SERVER וכו').

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

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

חסרונות וחוסר יעילות של סביבת PHP רגילה

אם אתה מפתח PHP מקצועי, אז אתה יודע איפה להתחיל פרויקט חדש - עם בחירת מסגרת. הוא מורכב מספריות הזרקת תלות, ORMs, תרגומים ותבניות. וכמובן, ניתן להכניס בנוחות את כל קלט המשתמש לאובייקט אחד (Symfony/HttpFoundation או PSR-7). מסגרות זה מגניב!

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

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

האם PHP עם Go יכול לשרוד יותר מבקשה אחת?

אפשר לכתוב סקריפטים של PHP שיימשכו יותר מכמה דקות (עד שעות או ימים): למשל משימות cron, מנתחי CSV, queue busters. כולם עובדים לפי אותו תרחיש: הם משחזרים משימה, מבצעים אותה ומחכים למשימה הבאה. הקוד שוכן בזיכרון, חוסך אלפיות שניות יקרות מכיוון שנדרשים שלבים נוספים רבים לטעינת המסגרת והיישום.

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

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

האם אפשר לקחת את המודל של עבודה עם סקריפטים של PHP ארוכי חיים, להתאים אותו למשימות טריוויאליות יותר כמו עיבוד בקשות HTTP, ובכך להיפטר מהצורך לטעון הכל מאפס עם כל בקשה?

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

ידענו שאנחנו יכולים לכתוב שרת אינטרנט ב-PHP טהור (PHP-PM) או באמצעות סיומת C (Swoole). ולמרות שלכל שיטה יש יתרונות משלה, שתי האפשרויות לא התאימו לנו – רצינו עוד משהו. היינו צריכים יותר מסתם שרת אינטרנט - ציפינו לקבל פתרון שיכול להציל אותנו מהבעיות הקשורות ל"התחלה קשה" ב-PHP, שבמקביל ניתן להתאים ולהרחיב בקלות לאפליקציות ספציפיות. כלומר, היינו צריכים שרת יישומים.

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

הקשיים בשילוב שתי שפות תכנות

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

לדוגמה, באמצעות ספרייה מעולה Alex Palaestras, ניתן היה לשתף זיכרון בין תהליכי PHP ו-Go (בדומה ל-mod_php ב-Apache). אבל לספרייה הזו יש תכונות שמגבילות את השימוש בה לפתרון הבעיה שלנו.

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

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

בצד PHP השתמשנו פונקציית חבילה, ובצד Go, הספרייה קידוד/בינארי.

נראה היה לנו שלא מספיק פרוטוקול אחד - והוספנו אפשרות להתקשר net/rpc go שירותי ישירות מ-PHP. מאוחר יותר, זה עזר לנו מאוד בפיתוח, מכיוון שיכולנו לשלב בקלות ספריות Go באפליקציות PHP. את התוצאה של עבודה זו ניתן לראות, למשל, במוצר הקוד הפתוח האחר שלנו גורידג'.

הפצת משימות על פני מספר עובדי PHP

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

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

כתוצאה מכך, קיבלנו שרת PHP עובד המסוגל לעבד כל בקשות המוצגות בצורה בינארית.

כדי שהאפליקציה שלנו תתחיל לעבוד כשרת אינטרנט, היינו צריכים לבחור תקן PHP אמין שיייצג כל בקשות HTTP נכנסות. במקרה שלנו, אנחנו פשוט שינוי צורה בקשת net/http מעבור לפורמט PSR-7כך שהוא תואם לרוב מסגרות ה-PHP הזמינות כיום.

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

היכרות עם RoadRunner - שרת יישומי PHP בעל ביצועים גבוהים

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

כדי להחליף פתרון זה, פרסנו את שרת יישומי PHP/Go הראשון שלנו בתחילת 2018. ומיד קיבל אפקט מדהים! לא רק שנפטרנו לחלוטין משגיאת 502, אלא שהצלחנו לצמצם את מספר השרתים בשני שליש, וחסכנו הרבה כסף וכדורי כאב ראש למהנדסים ומנהלי מוצר.

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

כיצד RoadRunner יכול לשפר את ערימת הפיתוח שלך

בקשה RoadRunner אפשרה לנו להשתמש ב-Middleware net/http בצד ה-Go כדי לבצע אימות JWT לפני שהבקשה מגיעה ל-PHP, כמו גם לטפל ב-WebSockets ובמצב צבירה גלובלי ב-Prometheus.

הודות ל-RPC המובנה, אתה יכול לפתוח את ה-API של כל ספריות Go עבור PHP מבלי לכתוב עטיפות של הרחבות. חשוב מכך, עם RoadRunner אתה יכול לפרוס שרתים חדשים שאינם HTTP. דוגמאות כוללות הפעלת מטפלים ב-PHP AWS למבדה, יצירת שוברי תור אמינים, ואפילו הוספה גר"פ ליישומים שלנו.

בעזרת קהילות PHP ו-Go, שיפרנו את יציבות הפתרון, הגדלנו את ביצועי האפליקציה עד פי 40 בחלק מהבדיקות, שיפרנו כלי איתור באגים, הטמענו אינטגרציה עם מסגרת Symfony והוספנו תמיכה ב-HTTPS, HTTP/2, תוספים, ו-PSR-17.

מסקנה

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

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

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

UPD: אנו מברכים את היוצר של RoadRunner ואת המחבר המשותף של המאמר המקורי - לאכסיס

מקור: www.habr.com