ניסיון בפיתוח שירות Refund Tool עם API אסינכרוני על Kafka

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

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

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

לגבי התהליך

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

כלי החזרים כספיים עם API מונחה אירועים

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

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

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

המוטיבציה שלנו:

1. חוק FZ-54 - בקיצור, החוק מחייב לדווח למס' על כל עסקה כספית, בין אם זו החזרה או קבלה, תוך SLA קצר למדי של מספר דקות. אנחנו, כחברת מסחר אלקטרוני, מבצעים לא מעט פעולות. מבחינה טכנית, משמעות הדבר היא אחריות חדשה (ולכן שירות חדש) ושיפורים בכל המערכות המעורבות.
2. פיצול BOB הוא פרויקט פנימי של החברה כדי לשחרר את BOB ממספר רב של תחומי אחריות שאינם הליבה ולהפחית את המורכבות הכוללת שלו.

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

ל-BOB יש גם די הרבה מרכזיות: מערכות תשלום, מערכות משלוח, מערכות הודעות וכו'.

מבחינה טכנית BOB הוא:

• ~150 אלף שורות קוד + ~100 אלף שורות של בדיקות;
• php7.2 + Zend 1 & Symfony Components 3;
• >100 ממשקי API & ~50 אינטגרציות יוצאות;
• 4 מדינות עם היגיון עסקי משלהן.

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

תהליך החזרה

בתחילה, שתי מערכות מעורבות בתהליך: BOB ותשלום. כעת מופיעים שניים נוספים:

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

כעת התהליך נראה כך:

1. BOB מקבל בקשה להחזר.
2. BOB מדבר על כלי ההחזר הזה.
3. כלי ההחזרים אומר לתשלום: "החזר את הכסף".
4. התשלום מחזיר את הכסף.
5. Refund Tool ו-BOB מסנכרנים סטטוסים אחד עם השני, כי בינתיים שניהם צריכים את זה. אנחנו עדיין לא מוכנים לעבור לגמרי ל-Refund Tool, שכן ל-BOB יש ממשק משתמש, דוחות להנהלת חשבונות ובכלל הרבה נתונים שאי אפשר להעביר כל כך בקלות. אתה צריך לשבת על שני כיסאות.
6. הבקשה לפיסקאליזציה נעלמת.

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

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

מהו API מונע אירועים

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

בקצרה מה עשינו:

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

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

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

החלפה אסינכרית כמות שהיא

עבור חילופים אסינכרוניים, מחלקת PHP משתמשת בדרך כלל ב-RabbitMQ. אספנו את הנתונים לבקשה, העמדנו אותם בתור, והצרכן של אותו שירות קרא אותם ושלח (או לא שלח). עבור ה-API עצמו, Lamoda משתמשת באופן פעיל ב-Swagger. אנו מעצבים API, מתארים אותו ב-Swagger ומייצרים קוד לקוח ושרת. אנו משתמשים גם ב-JSON RPC 2.0 משופר מעט.

במקומות מסוימים משתמשים באוטובוסי ESB, חלקם חיים ב-activeMQ, אבל, באופן כללי, RabbitMQ - סטנדרטי.

בורסה אסינכרונית TO BE

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

מיקור אירועים על קפקא הוא דבר טיפוסי. יש פתרון מהגרסת הארגונית הראשית של קפקא קונפלואנט, יש נאקאדי, פתרון מאחי התחום שלנו Zalando. שֶׁלָנוּ מוטיבציה להתחיל עם וניל קפקא - זה אומר להשאיר את הפתרון חופשי עד שנחליט סופית אם נשתמש בו בכל מקום, וגם להשאיר לעצמנו מרחב תמרון ושיפורים: אנחנו רוצים תמיכה עבור שלנו JSON RPC 2.0, גנרטורים לשתי שפות ובואו נראה מה עוד.

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

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

אירועים-אוטובוס

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

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

למה

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

חילופי 1:n+1 (אחד לרבים)

קפקא מקל מאוד לחבר צרכנים חדשים ל-API.

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

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

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

מונע נתונים

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

יומן שכפול

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

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

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

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

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

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

דרישות אירוע:

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

• יושרה אנו מאצילים ל-Events-bus את האימות שהאירוע עקבי והוא יכול לעבד אותו.
• הסדר חשוב. במקרה של חזרה, אנחנו נאלצים לעבוד עם ההיסטוריה. בהתראות, ההזמנה אינה חשובה, אם מדובר בהודעות הומוגניות, המייל יהיה זהה ללא קשר להזמנה שהגיעה ראשונה. במקרה של החזר, יש תהליך ברור, אם נשנה את ההזמנה, יצוצו חריגים, ההחזר לא ייווצר ולא יעובד - נגיע למצב אחר.
• עֲקֵבִיוּת. יש לנו חנות, ועכשיו אנחנו יוצרים אירועים במקום API. אנחנו צריכים דרך להעביר במהירות ובזול מידע על אירועים חדשים ושינויים קיימים לשירותים שלנו. זה מושג באמצעות מפרט משותף במאגר git נפרד ומחוללי קוד. לכן, לקוחות ושרתים בשירותים שונים מתואמים.

קפקא בלמודה

יש לנו שלושה מיצבים של קפקא:

1. יומנים;
2. מחקר ופיתוח;
3. אירועים-אוטובוס.

היום אנחנו מדברים רק על הנקודה האחרונה. ב-events-bus אין לנו התקנות גדולות במיוחד - 3 מתווכים (שרתים) ורק 27 נושאים. ככלל, נושא אחד הוא תהליך אחד. אבל זו נקודה עדינה, ואנחנו ניגע בה עכשיו.

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

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

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

מקרי שימוש של Lamoda Events

אנו משתמשים בארכיטקטורה הבנויה עבור הפעולות הבאות:

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

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

בעיות עיצוב

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

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

זרם נתונים

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

בנושא אחד או בנושאים שונים?

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

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

תחום חדש או אירוע חדש?

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

אם אנו מציגים כלל ל-event-bus ששדה זה נדרש, אזי נאלץ להגדיר כללי אימות נוספים ב-BOB או ב-start event handler. האימות מתחיל להתפשט לאורך השירות - זה לא מאוד נוח.

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

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

ניהול גרסאות לאירועים

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

סדר קריאה מובטח של מחיצות

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

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

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

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

אירועים לעומת פקודות

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

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

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

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

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

ניואנסים

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

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

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

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

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

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

ניטור

אני חושב שהדרך שבה ננטר את זה תהיה ברורה עוד יותר אילו בעיות יש בגישה הקיימת.

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

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

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

יש פרויקט לִנְבּוּרמה שייתן לך מידע נוסף על קפקא. הוא פשוט משתמש ב-API של קבוצת צרכנים כדי לתת את הסטטוס של מצב הקבוצה הזו. בנוסף ל-OK ו-Failed, יש אזהרה, ותוכלו לגלות שהצרכנים שלכם לא יכולים להתמודד עם קצב הייצור – אין להם זמן להגיה את הכתוב. המערכת די חכמה וקלה לשימוש.

כך נראית תגובת ה-API. הנה הקבוצה bob-live-fifa, partition refund.update.v1, status OK, lag 0 - הקיזוז הסופי האחרון כזה וכזה.

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

לסיכום, השימוש באירועים נוח מתי:

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

נראה שלמאמר יש נושא מאוד ספציפי - API אסינכרוני על קפקא, אבל בקשר אליו אני רוצה להמליץ ​​על הרבה דברים בבת אחת.
ראשית, הבא HighLoad ++ אנחנו צריכים לחכות עד נובמבר; באפריל תהיה גרסה של סנט פטרסבורג, וביוני נדבר על עומסים גבוהים בנובוסיבירסק.
שנית, מחבר הדו"ח, סרגיי זאיקה, הוא חבר בוועדת התוכנית של הכנס החדש שלנו לניהול ידע KnowledgeConf. הכנס הוא חד-יומי, יתקיים ב-26 באפריל, אך תוכניתו אינטנסיבית מאוד.
וזה יהיה במאי PHP רוסיה и RIT++ (עם DevOpsConf כלול) - אתה יכול גם להציע את הנושא שלך שם, לדבר על הניסיון שלך ולהתלונן על הקונוסים הממולאים שלך.

מקור: www.habr.com