אבני בניין של אפליקציות מבוזרות. קירוב אפס

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

מבוא

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

הנושא של יישומים מבוזרים תגובתיים הוא די רחב. כדי לשמור על הפורמט של המאמר, הנושא של הדיון היום יהיה רק ​​סביבות הומוגניות הבנויות על Erlang/Elixir. המערכת האקולוגית של Erlang/OTP מאפשרת לך ליישם ארכיטקטורה תגובתית במינימום מאמץ. אבל בכל מקרה, נצטרך שכבת מסרים.

בסיס תיאורטי

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

הבה נדגיש 4 דרישות עיקריות עבור המערכת הסופית:

• Сמונחה אירועים.
  המערכת תמיד מוכנה לעבור בשטף האירועים ולבצע את הפעולות הנדרשות;
• Мמדרגיות.
  ניתן לשנות קנה מידה של בלוקים בודדים הן אנכית והן אופקית. המערכת כולה חייבת להיות מסוגלת לצמיחה אופקית אינסופית;
• Оסובלנות לתקלות.
  כל הרמות וכל השירותים צריכים להיות מסוגלים להתאושש אוטומטית מתקלות;
• Гזמן תגובה מובטח.
  זמן הוא יקר ומשתמשים לא צריכים לחכות יותר מדי זמן.

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

נקודה נוספת נוספת להעברת ההודעות ככלי תשתית וכבסיס לכל השירותים: נוחות השימוש למתכנתים.

מכוון לאירועים

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

מדרגיות

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

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

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

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

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

סובלנות לתקלות

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

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

היענות

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

סיכום ראשוני

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

סוף החלק הראשון.

תצלום @lucabravo.

מקור: www.habr.com