В этой статье собраны некоторые общие шаблоны, помогающие инженерам работать с масштабными сервисами, к которым делают запросы миллионы пользователей.
מניסיונו של המחבר, אין זו רשימה ממצה, אבל אכן יָעִיל עצה. אז בואו נתחיל.
תורגם בתמיכה .
שלב ראשון
Перечисленные ниже меры относительно просты в реализации, но дают высокую отдачу. Если вы раньше их не предпринимали, то будете удивлены значительными улучшениями.
תשתית כקוד
Первая часть советов заключается в том, чтобы реализовать инфраструктуру как код. Это означает, что у вас должен быть программный способ развертывания всей инфраструктуры. Звучит замысловато, но на самом деле мы говорим о следующем коде:
Развертывание 100 виртуальных машин
- с Ubuntu
- 2 GB RAM כל אחד
- יהיה להם את הקוד הבא
- עם הפרמטרים האלה
אתה יכול לעקוב אחר שינויים בתשתית שלך ולחזור אליהם במהירות באמצעות בקרת גרסאות.
Модернист во мне говорит, что можно использовать Kubernetes/Docker, чтобы сделать всё выше перечисленное, и он прав.
בנוסף, ניתן לספק אוטומציה באמצעות Chef, Puppet או Terraform.
שילוב ואספקה רציפים
כדי ליצור שירות ניתן להרחבה, חשוב שיהיה צינור לבנות ובדיקה עבור כל בקשת משיכה. גם אם הבדיקה פשוטה מאוד, היא לפחות תבטיח שהקוד שתפרוס יבצע קומפילציה.
Каждый раз на этом этапе вы отвечаете на вопрос: האם ההרכבה שלי תעבור ותעבור מבחנים, האם היא תקפה? זה אולי נראה כמו רף נמוך, אבל זה פותר הרבה בעיות.
אין דבר יותר יפה מלראות את הקרציות האלה
עבור טכנולוגיה זו אתה יכול להעריך Github, CircleCI או Jenkins.
מאזני עומסים
Итак, мы хотим запустить балансировщик нагрузки, чтобы перенаправлять трафик, и обеспечить равную нагрузку на всех узлах или работу сервиса в случае сбоя:
Балансировщик нагрузки, как правило, хорошо помогает распределять трафик. Наилучшей практикой является избыточная балансировка, чтобы у вас не было единой точки отказа.
בדרך כלל, מאזני עומסים מוגדרים בענן שבו אתה משתמש.
RayID, מזהה מתאם או UUID עבור בקשות
האם נתקלת פעם בשגיאת יישום עם הודעה כזו: "משהו השתבש. שמור את המזהה הזה ושלח אותו לצוות התמיכה שלנו"?
Уникальный идентификатор, correlation ID, RayID или любой из вариантов — это уникальный идентификатор, который позволяет отслеживать запрос в течение его жизненного цикла. זה מאפשר לך לעקוב אחר כל נתיב הבקשה ביומנים.
המשתמש מגיש בקשה למערכת א', ואז א' יוצר קשר ב', אשר יוצר קשר עם ג', מאחסן אותו ב-X, ואז הבקשה מוחזרת ל-A
אם היית מתחבר מרחוק למכונות וירטואליות ומנסה להתחקות אחר נתיב הבקשה (ותתאם באופן ידני אילו שיחות מתבצעות), היית משתגע. בעל מזהה ייחודי עושה את החיים הרבה יותר קלים. זהו אחד הדברים הפשוטים ביותר שאתה יכול לעשות כדי לחסוך זמן ככל שהשירות שלך גדל.
רמה ממוצעת
Здесь советы сложнее предыдущих, но правильные инструменты облегчают задачу, обеспечивая окупаемость инвестиций даже для малых и средних компаний.
Централизованное ведение журналов
Поздравляю! Вы развернули 100 виртуальных машин. На следующий день генеральный директор приходит и жалуется на ошибку, которую получил во время тестирования сервиса. Он сообщает соответствующий идентификатор, о котором мы говорили выше, но вам придется просматривать журналы 100 машин, чтобы найти ту, которая вызвала сбой. И ее нужно найти до завтрашней презентации.
אמנם זה נשמע כמו הרפתקה מהנה, אבל עדיף לוודא שיש לך את היכולת לחפש בכל המגזינים במקום אחד. פתרתי את הבעיה של ריכוז יומנים באמצעות הפונקציונליות המובנית של מחסנית ה-ELK: היא תומכת באיסוף יומנים שניתן לחיפוש. זה באמת יעזור לפתור את הבעיה של מציאת יומן ספציפי. כבונוס, אתה יכול ליצור תרשימים ודברים מהנים אחרים כאלה.
Функциональность стека ELK
סוכני ניטור
כעת, כשהשירות שלך פועל, עליך לוודא שהוא פועל בצורה חלקה. הדרך הטובה ביותר לעשות זאת היא להפעיל כמה סוכנים, שעובדים במקביל ובודקים שזה עובד ומבצעים פעולות בסיסיות.
בשלב זה אתה בודק את זה מבנה הריצה מרגיש טוב ועובד מצוין.
Для небольших и средних проектов я рекомендую Postman для мониторинга и документирования API. Но в целом просто следует убедиться, что у вас есть способ узнать, когда произошел сбой, и получить своевременное оповещение.
קנה מידה אוטומטי בהתאם לעומס
Это очень просто. Если у вас есть виртуальная машина, обслуживающая запросы, и она приближается к тому, что 80% памяти занято, то можно либо увеличить ее ресурсы, либо добавить в кластер больше виртуальных машин. Автоматическое выполнение этих операций отлично подходит для эластичного изменения мощности под нагрузкой. Но вы всегда должны быть осторожны в том, сколько денег тратите, и установить разумные лимиты.
В большинстве облачных служб вы можете настроить автоматическое масштабирование, используя большее количество серверов или более мощные серверы.
מערכת ניסויים
דרך טובה להפיץ עדכונים בצורה בטוחה היא להיות מסוגל לבדוק משהו עבור 1% מהמשתמשים במשך שעה. ראיתם, כמובן, מנגנונים כאלה בפעולה. לדוגמה, פייסבוק מציגה לחלקים מהקהל צבע שונה או משנה את גודל הגופן כדי לראות כיצד המשתמשים תופסים את השינויים. זה נקרא בדיקת A/B.
אפילו שחרור פיצ'ר חדש יכול להתחיל כניסוי ואז לקבוע כיצד לשחרר אותו. אתה גם מקבל את היכולת "לזכור" או לשנות את התצורה תוך כדי תנועה בהתבסס על הפונקציה שגורמת לפגיעה בשירות שלך.
רמה מתקדמת
Здесь советы, которые довольно сложно реализовать. Вероятно, вам потребуется немного больше ресурсов, поэтому небольшой или средней компании будет трудно с этим справиться.
Сине-зеленые развертывания
זה מה שאני קורא לדרך ה"ארלנג" להתגלגל. ארלנג הפך בשימוש נרחב כשהופיעו חברות טלפון. החלו להשתמש ב-Softwitch לניתוב שיחות טלפון. המטרה העיקרית של התוכנה במתגים אלו הייתה לא להפסיק שיחות במהלך שדרוגי מערכת. ל-Erlang יש דרך נחמדה לטעון מודול חדש מבלי לקרוס את המודול הקודם.
שלב זה תלוי בנוכחות של מאזן עומסים. נניח שיש לך גרסה N של התוכנה שלך, ואז אתה רוצה לפרוס את גרסה N+1.
אתה היינו יכולים פשוט עצור את השירות והשק את הגרסה הבאה בזמן שעובד עבור המשתמשים שלך וקבל זמן השבתה. אבל נניח שיש לך באמת תנאי SLA קפדניים. אז, SLA 99,99% אומר שאתה יכול ללכת לא מקוון רק ב-52 דקות בשנה.
אם אתה באמת רוצה להשיג אינדיקטורים כאלה, אתה צריך שתי פריסות בו-זמנית:
- זה שהוא ממש עכשיו (נ);
- הגרסה הבאה (N+1).
אתה אומר למאזן העומס לנתב מחדש אחוז מהתנועה לגרסה החדשה (N+1) תוך כדי מעקב פעיל אחר רגרסיות.
כאן יש לנו פריסת N ירוקה שעובדת מצוין. אנו מנסים לעבור לגרסה הבאה של פריסה זו
Сначала мы посылаем действительно небольшой тест, чтобы посмотреть, работает ли наш деплой N+1 с небольшим количеством трафика:
לבסוף, יש לנו קבוצה של בדיקות אוטומטיות שאנו מפעילים בסופו של דבר עד להשלמת הפריסה שלנו. אם אתה מאוד מאוד זהירות, אתה יכול גם לשמור את פריסת ה-N שלך לנצח להחזרה מהירה במקרה של רגרסיה גרועה:
Если хотите перейти на еще более продвинутый уровень, пусть всё в сине-зеленом деплое выполняется автоматически.
זיהוי אנומליות והפחתה אוטומטית
בהתחשב בכך שיש לך רישום מרוכז ואיסוף יומן טוב, אתה כבר יכול להגדיר יעדים גבוהים יותר. לדוגמה, חזה באופן יזום כישלונות. מעקב אחר הפונקציות מתבצע על גבי מסכים ובלוגים ונבנים דיאגרמות שונות - וניתן לחזות מראש מה ישתבש:
לאחר שמזהים חריגות, אתה מתחיל לבחון כמה מהרמזים שהשירות מספק. לדוגמה, עלייה בעומס המעבד עשוי להצביע על כשל בכונן הקשיח, בעוד שעלייה בבקשות עשויה להצביע על כך שעליך להגדיל את קנה המידה. סוג זה של נתונים סטטיסטיים מאפשר לך להפוך את השירות ליזום.
עם התובנות הללו, תוכלו לשנות קנה מידה בכל מימד ולשנות באופן יזום ותגובתי את המאפיינים של מכונות, מסדי נתונים, חיבורים ומשאבים אחרים.
זה הכל!
Этот список приоритетов избавит вас от многих проблем, если вы поднимаете облачный сервис.
כותב המאמר המקורי מזמין את הקוראים להשאיר את הערותיהם ולבצע שינויים. המאמר מופץ כקוד פתוח, בקשות משיכה של המחבר .
מה עוד כדאי לקרוא בנושא:
מקור: www.habr.com