הבנת מתווכים בהודעות. לימוד המכניקה של העברת הודעות עם ActiveMQ וקפקא. פרק 1

שלום לכולם!

התחיל לתרגם ספר קטן:
«הבנת Message Brokers",
מחבר: Jakub Korab, מו"ל: O'Reilly Media, Inc., תאריך פרסום: יוני 2017, ISBN: 9781492049296.

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

חלקים שתורגמו עד כה:
פרק 1 - מבוא
פרק 3. קפקא

אפרסם פרקים שהושלמו תוך כדי תרגום.

פרק 1

מבוא

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

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

נשמע מוכר?

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

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

• המערכת לעולם לא תאבד הודעות
• ההודעות יעובדו ברצף
• הוספת צרכנים תהפוך את המערכת למהירה יותר
• הודעות יימסרו פעם אחת בלבד

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

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

לפני שנתחיל, בואו נעבור על היסודות.

מהי מערכת הודעות ולמה היא נחוצה

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

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

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

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

נקודה לנקודה

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

זוהי דוגמה למודל העברת הודעות נקודה לנקודה. הדואר כאן פועל כמנגנון חלוקת חבילות, המבטיח שכל חבילה תועבר פעם אחת. השימוש בדואר מפריד בין פעולת שליחת החבילה לבין משלוח החבילה.
במערכות הודעות קלאסיות, מודל הנקודה לנקודה מיושם באמצעות очереди. התור פועל כמאגר FIFO (כניסה ראשונה, יוצאת ראשונה) שצרכן אחד או יותר יכול להירשם אליו. כל הודעה מועברת בלבד אחד מהצרכנים הרשומים. תורים בדרך כלל מנסים להפיץ הודעות בצורה הוגנת בין הצרכנים. רק צרכן אחד יקבל הודעה זו.

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

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

בעל מנוי

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

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

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

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

דגמים היברידיים

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

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

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

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

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

התרגום נעשה: tele.gg/middle_java

החלק המתורגם הבא: פרק 3. קפקא

להמשך ...

מקור: www.habr.com