מיכאיל סלוסין. מפגש גולנג. שימוש ב-Go בקצה האחורי של אפליקציית Look+

מיכאיל סאלוסין (להלן – MS): - שלום לכולם! שמי הוא מיכאל. אני עובד כמפתח אחורי ב-MC2 Software, ואדבר על השימוש ב-Go בקצה האחורי של אפליקציית Look+ לנייד.

מישהו כאן אוהב הוקי?

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

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

במה השתמשת בפיתוח?

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

השתמשנו ב-PostgreSQL כמסד הנתונים. ממשק העורך נכתב ב-Ruby on Rails באמצעות פנינת ActiveAdmin. ייבוא ​​סטטיסטיקות מספק סטטיסטיקה נכתב גם הוא ברובי.

עבור בדיקות API של מערכת, השתמשנו ב-Python unittest. Memcached משמש למניעת קריאות תשלום API, "שף" משמש לשליטה בתצורה, Zabbix משמש לאיסוף ולנטר סטטיסטיקות מערכת פנימיות. Graylog2 מיועד לאיסוף יומנים, Slate הוא תיעוד API עבור לקוחות.

בחירת פרוטוקול

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

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

בהתבסס על זה, היו לנו שתי אפשרויות פרוטוקול:

1. Websockets. אבל לא היינו צריכים ערוצים מהלקוח לשרת. היינו צריכים רק לשלוח עדכונים מהשרת ללקוח, כך ש-websocket הוא אפשרות מיותרת.
2. אירועים שנשלחו על ידי שרת (SSE) עלו בדיוק כמו שצריך! זה די פשוט ובעצם מספק את כל מה שאנחנו צריכים.

אירועים שנשלחו על ידי השרת

כמה מילים על איך הדבר הזה עובד...

זה פועל על גבי חיבור http. הלקוח שולח בקשה, השרת מגיב ב-Content-Type: text/event-stream ולא סוגר את הקשר עם הלקוח, אלא ממשיך לכתוב נתונים לחיבור:

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

עכשיו בואו נדבר על איך האינטראקציה עצמה עובדת.

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

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

כיצד מתנהל החיבור החי?

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

הבעיה הראשונה שנתקלנו בה הייתה הבאה: על כל חיבור שנפתח עם הלקוח, יצרנו טיימר שתקתק פעם ב-15 שניות - מסתבר שאם היו לנו 6 חיבורים פתוחים עם מכונה אחת (עם שרת API אחד), 6 נוצרו אלף טיימרים. זה הוביל לכך שהמכונה לא החזיקה את העומס הנדרש. הבעיה לא הייתה כל כך ברורה לנו, אבל קיבלנו קצת עזרה ותיקנו אותה.

כתוצאה מכך, כעת הפינג שלנו מגיע מאותו ערוץ שממנו מגיע העדכון.

בהתאם לכך, יש רק טיימר אחד שמתקתק אחת ל-15 שניות.

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

מנגנון שליחת עדכונים

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

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

PostgreSQL: האזינו/הודיעו

מנגנון Listen/Notify ב-Postgres מאפשר להודיע ​​למנויי אירוע שאירוע כלשהו השתנה - רשומה כלשהי נוצרה במסד הנתונים. לשם כך, כתבנו טריגר ופונקציה פשוטים:

בעת הוספה או שינוי של רשומה, אנו קוראים לפונקציית notify בערוץ data_updates, ומעבירים לשם את שם הטבלה ואת המזהה של הרשומה ששונתה או הוכנסה.

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

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

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

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

איך עובד Fan-out?

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

איך זה מיושם ב-Go:

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

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

יש גם שיטת הרשמה שמוסיפה את הערוץ ל"מאזינים":

קיימת שיטת Unsubscribe, אשר מסירה את הערוץ מהמאזינים אם הלקוח מתנתק, וכן שיטת Publish, המאפשרת לשלוח הודעה לכל המנויים.

שאלה: - מה מועבר בערוץ הזה?

גברת: – המודל שהשתנה או הפינג מועבר (בעצם רק מספר, מספר שלם).

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

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

תשתית

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

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

יש גם יבואן סטטיסטיקה. יש DB Slave שממנו מתבצעים גיבויים מעת לעת. יש Pigeon Pusher, אפליקציה ששולחת הודעות דחיפה ללקוחות, וגם דברים של תשתית: Zabbix, Graylog2 ו- Chef.

למעשה, התשתית הזו מיותרת, כי ניתן להגיש 100 אלף עם פחות שרתים. אבל היה ברזל - השתמשנו בו (אמרו לנו שאפשר - למה לא).

היתרונות של Go

לאחר שעבדנו על האפליקציה הזו, הופיעו יתרונות כה ברורים של Go.

• ספריית http מגניבה. עם זה אתה יכול ליצור די הרבה מחוץ לקופסה.
• בנוסף, ערוצים שאפשרו לנו ליישם בקלות רבה מנגנון לשליחת הודעות ללקוחות.
• הדבר הנפלא Race detector איפשר לנו לחסל כמה באגים קריטיים (תשתית בימוי). כל מה שעובד בבימוי מושק, מורכב עם מפתח Race; ובהתאם לכך, אנו יכולים להסתכל על תשתית ההיערכות כדי לראות אילו בעיות פוטנציאליות יש לנו.
• מינימליזם ופשטות השפה.

אנחנו מחפשים מפתחים! אם מישהו רוצה, בבקשה.

שאלות

שאלה מהקהל (להלן – ב): – נראה לי שפספסת נקודה אחת חשובה לגבי Fan-out. האם אני צודק בהבנתי שכאשר אתה שולח תגובה ללקוח אתה חוסם אם הלקוח לא רוצה לקרוא?

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

בתוך: - האם לא ניתן היה לשלוח מיד רשומה ל-Lenen/Notify, ולא לטבלת מזהים?

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

בתוך: – האם לקוחות מקבלים עדכונים על התאמות שהם לא מעוניינים בהם?

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

בתוך: – למה יצרת ORM משלך?

אלכסיי (אחד המפתחים של Look+): – באותה תקופה (זה היה לפני שנה) היו פחות ORMs מאשר עכשיו, כאשר יש די הרבה כאלה. הדבר האהוב עלי ברוב ה-ORMs בחוץ הוא שרובם פועלים על ממשקים ריקים. כלומר, השיטות ב-ORMs האלה מוכנות לקבל כל דבר: מבנה, מצביע מבנה, מספר, משהו לגמרי לא רלוונטי...

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

בתוך: - כמה אנשים השתתפו?

גברת: – בשלב הראשוני השתתפו שני אנשים. התחלנו איפשהו ביוני, ובאוגוסט החלק העיקרי היה מוכן (הגרסה הראשונה). היה שחרור בספטמבר.

בתוך: - איפה שאתה מתאר SSE, אתה לא משתמש בפסק זמן. למה?

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

בתוך: - באילו כלי עזר נוספים השתמשת?

גברת: – השתמשנו באופן הפעיל ביותר ב-govet וב-golint כדי להפוך את הסגנון למאוחד, כמו גם ב-gofmt. שום דבר אחר לא היה בשימוש.

בתוך: - במה השתמשת כדי לנפות באגים?

גברת: - איתור באגים בוצע ברובו באמצעות בדיקות. לא השתמשנו באף באגים או ב-GOP.

בתוך: – האם אתה יכול להחזיר את השקופית שבה מיושמת הפונקציה Publish? האם שמות משתנים באות אחת מבלבלים אותך?

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

בתוך: - איכשהו זה עדיין לא אינטואיטיבי...

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

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

בתוך: – האם קיימות חבילות ניהול תלות של צד שלישי?

גברת: – השתמשנו ב-go dep.

בתוך: - היה משהו על וידאו בנושא הדו"ח, אבל לא היה שום דבר בדו"ח על וידאו.

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

בתוך: – אמרת שזה מוזרם ללקוחות?..

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

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

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com