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

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

איך הגענו למיקרו-שירותים

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

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

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

כעת בכלי השירות PaaS CLI נוצר שירות חדש עם פקודה אחת, ומסד נתונים חדש מתווסף עם שניים נוספים ונפרס ל-Stage.

איך להתגבר על עידן "פיצול מיקרו שירותים"

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

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

• רישום;
• מעקב אחר בקשה (ייגר);
• צבירה של שגיאות (Sentry);
• סטטוסים, הודעות, אירועים מ-Kubernetes (עיבוד זרם אירועים);
• מגבלת מירוץ / מפסק זרם (ניתן להשתמש ב-Hystrix);
• שליטה בקישוריות השירות (אנו משתמשים ב-Netramesh);
• ניטור (Grafana);
• הרכבה (TeamCity);
• תקשורת והתראה (Slack, מייל);
• מעקב אחר משימות; (ג'ירה)
• הכנת תיעוד.

כדי להבטיח שהמערכת לא תאבד את שלמותה ותישאר אפקטיבית כשהיא מתרחבת, חשבנו מחדש על ארגון שירותי המיקרו ב-Avito.

איך אנחנו מנהלים שירותי מיקרו

הדברים הבאים עוזרים ליישם "מדיניות מפלגתית" מאוחדת בין שירותי מיקרו של Avito:

• חלוקת תשתיות לשכבות;
• תפיסת פלטפורמה כשירות (PaaS);
• מעקב אחר כל מה שקורה עם שירותי מיקרו.

שכבות הפשטת תשתית כוללות שלוש שכבות. בוא נלך מלמעלה למטה.

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

כל השכבות משולבות על ידי PaaS. והפלטפורמה הזו, בתורה, מורכבת משלושה חלקים.

I. גנרטורים, נשלט באמצעות כלי שירות CLI. היא זו שעוזרת למפתח ליצור מיקרו-שירות בצורה הנכונה ובמינימום מאמץ.

II. אספן מאוחד עם שליטה בכל הכלים באמצעות לוח מחוונים משותף.

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

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

כיצד פועל צינור פיתוח מיקרו-שירות סטנדרטי?

באופן כללי, שרשרת יצירת המיקרו-שירותים נראית כך:

CLI-push → אינטגרציה מתמשכת → אפייה → פריסה → בדיקות מלאכותיות → בדיקות קנריות → בדיקת סחיטה → ייצור → תחזוקה.

בוא נעבור על זה בדיוק בסדר הזה.

CLI-דחיפה

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

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

- יוצר שירות לפי תבנית - צעד אחר צעד, במצב "אשף". יש לנו תבניות לשפות התכנות העיקריות ב-Avito backend: PHP, Golang ו-Python.

- פקודה אחת בכל פעם פורסת סביבה לפיתוח מקומי במכונה ספציפית - Minikube מופעלת, תרשימי Helm נוצרים אוטומטית ומופעלים ב-kubernetes מקומיים.

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

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

- מייצר בדיקות אוטומטיות. בצורה של ריקים, אבל די מתאים לשימוש.

• פריסת Microservice.

פריסת מיקרו-שירות הייתה פעם קצת מטלה עבורנו. נדרשו הדברים הבאים:

I. Dockerfile.

II. Config.
III. תרשים הגה, שהוא עצמו מסורבל וכולל:

- התרשימים עצמם;
- תבניות;
- ערכים ספציפיים תוך התחשבות בסביבות שונות.

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

כן, וב-app.toml עצמו אין מה לעשות לדקה. אנו מציינים היכן וכמה עותקים של השירות לגייס (בשרת הפיתוח, בהיערכות, בהפקה), ומציינים את התלות שלו. שימו לב לגודל הקו = "קטן" בבלוק [מנוע]. זוהי המגבלה שתוקצה לשירות באמצעות Kubernetes.

לאחר מכן, בהתבסס על התצורה, נוצרים אוטומטית כל תרשימי ה-Helm הדרושים ויצירת חיבורים לבסיסי הנתונים.

• אימות בסיסי. גם בדיקות כאלה הן אוטומטיות.
צריך לעקוב אחר:
- האם יש Dockerfile;
- האם יש app.toml;
- האם יש תיעוד זמין?
- האם התלות תקינה?
- האם נקבעו כללי התראה.
לנקודה האחרונה: בעל השירות קובע בעצמו אילו מדדי מוצר לנטר.

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

I. תיאור קצר של השירות. ממש כמה משפטים על מה זה עושה ולמה זה נחוץ.

II. קישור לתרשים אדריכלות. חשוב שבמבט מהיר בו קל להבין, למשל, האם אתה משתמש ב-Redis לשמירה במטמון או כמאגר הנתונים הראשי במצב מתמשך. ב-Avito לעת עתה זהו קישור ל-Confluence.

III. ספר ריצה. מדריך קצר על התחלת השירות ומורכבות הטיפול בו.

IV. שאלות נפוצות, שבו יהיה טוב לצפות מראש את הבעיות שעמיתיך עלולים להיתקל בהן בעת ​​העבודה עם השירות.

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

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

VII. הבעלים או הבעלים של השירות. ברוב המקרים, זה - או אותם - ניתן לקבוע באופן אוטומטי באמצעות PaaS, אך ליתר ביטחון, אנו דורשים מהמפתח לציין אותם באופן ידני.

לבסוף, נוהג טוב לעיין בתיעוד, בדומה לבדיקת קוד.

אינטגרציה מתמשכת

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

לֶאֱפוֹת

השלב הבא הוא שירותי אריזה לפני הפריסה.

• בניית האפליקציה. לפי הקלאסיקה - בתמונת דוקר.
• יצירת תרשימי Helm עבור השירות עצמו ומשאבים נלווים. כולל עבור מסדי נתונים ומטמון. הם נוצרים באופן אוטומטי בהתאם לתצורת app.toml שנוצרה בשלב ה-CLI-push.
• יצירת כרטיסים למנהלי מערכת ליציאות פתוחות (כשזה נדרש).
• הפעלת בדיקות יחידה וחישוב כיסוי קוד. אם כיסוי הקוד נמוך מהסף שצוין, סביר להניח שהשירות לא ימשיך הלאה - לפריסה. אם זה על סף מקובל, אזי לשירות יוקצה מקדם "פסימי": לאחר מכן, אם לא חל שיפור במחוון לאורך זמן, היזם יקבל הודעה שאין התקדמות מבחינת הבדיקות ( וצריך לעשות משהו בנידון).
• התחשבות במגבלות הזיכרון והמעבד. אנחנו כותבים בעיקר שירותי מיקרו בגולנג ומפעילים אותם ב-Kubernetes. מכאן עדינות אחת הקשורה למוזרות של שפת הגולנג: כברירת מחדל, בעת ההפעלה, נעשה שימוש בכל הליבות במכונה, אם לא מגדירים במפורש את המשתנה GOMAXPROCS, וכאשר מספר שירותים כאלה מופעלים על אותה מכונה, הם מתחילים להתחרות על משאבים, להפריע אחד לשני. הגרפים שלהלן מראים כיצד זמן הביצוע משתנה אם אתה מפעיל את היישום ללא מחלוקת ובמצב המירוץ אחר משאבים. (מקורות הגרפים הם כאן).

זמן ביצוע, פחות עדיף. מקסימום: 643ms, מינימום: 42ms. התמונה ניתנת ללחיצה.

זמן לניתוח, פחות עדיף. מקסימום: 14091 ns, מינימום: 151 ns. התמונה ניתנת ללחיצה.

בשלב הכנת ההרכבה, אתה יכול להגדיר משתנה זה במפורש או שאתה יכול להשתמש בספרייה automaxprocs מהחבר'ה מאובר.

לפרוס

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

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

בדיקות סינתטיות

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

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

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

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

ב) אנו מסתכלים על החתך לפי RPS.
כאן אנו מסתכלים על ההבדל בין הגרסה הנוכחית לקודמת ועל הכמות הכוללת. לדוגמה, אם שירות מייצר 100 סל"ד, אז הוא כתוב בצורה גרועה, או שזו הספציפיות שלו, אבל בכל מקרה, זו סיבה לבחון את השירות מקרוב מאוד.
אם, להיפך, יש יותר מדי RPS, אז אולי יש איזה באג וחלק מנקודות הקצה הפסיקו לבצע את המטען, ואחת אחרת פשוט מופעלת return true;

בדיקות קנריות

לאחר שעברנו את המבחנים הסינתטיים, אנו בודקים את המיקרו-שירות על מספר קטן של משתמשים. אנחנו מתחילים בזהירות, עם נתח זעיר מהקהל המיועד של השירות - פחות מ-0,1%. בשלב זה, חשוב מאוד שהמדדים הטכניים והמוצרים הנכונים ייכללו במעקב כדי שיראו את הבעיה בשירות במהירות האפשרית. הזמן המינימלי למבחן קנרי הוא 5 דקות, העיקרי הוא שעתיים. עבור שירותים מורכבים, אנו מגדירים את השעה באופן ידני.
אנו מנתחים:
- מדדים ספציפיים לשפה, בפרט, עובדי php-fpm;
- שגיאות ב- Sentry;
- סטטוסי תגובה;
- זמן תגובה, מדויק וממוצע;
- חביון;
- חריגים, מעובדים ולא מטופלים;
- מדדי מוצר.

בדיקת סחיטה

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

הפקה

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

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

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

שירות

לאחר שהמיקרו-שירות יופעל, נוכל לצרף אליו טריגרים.

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

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

לוּחַ מַחווָנִים

בקיצור, לוח המחוונים הוא לוח הבקרה של כל ה-PaaS שלנו.

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

בסך הכל

לפני הצגת PaaS, מפתח חדש יוכל להשקיע מספר שבועות בהבנת כל הכלים הדרושים להשיק מיקרו-שירות בייצור: Kubernetes, Helm, תכונות TeamCity הפנימיות שלנו, הגדרת חיבורים לבסיסי נתונים ומטמונים בצורה סובלנית לתקלות וכו'. לוקח כמה שעות לקרוא את ההתחלה המהירה וליצור את השירות עצמו.

נתתי דוח בנושא זה עבור HighLoad++ 2018, אתה יכול לצפות בו וידאו и הַצָגָה.

רצועת בונוס למי שקורא עד הסוף

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

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

ניתן להגיש בקשה להשתתפות בטופס גוגל זה. ממך - התשובה לשאלה מדוע עליך להגיע להדרכה ומידע כיצד ליצור איתך קשר. ענו באנגלית, כי כריס יבחר בעצמו את המשתתף שישתתף באימון.
אנו נכריז על שם המשתתף בהדרכה בעדכון לפוסט זה וברשתות החברתיות Avito למפתחים (AvitoTech ב Фейсбуке, Vkontakte, טוויטר) לא יאוחר מ-19 ביולי.

מקור: www.habr.com