"הולך בנעליים שלי" - רגע, הם מסומנים?

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

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

HighLoad אמיתי

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

צוות מ

למרות העובדה שמרקוס נחשב לפרויקט בתוך X5, הוא מיושם באמצעות גישת מוצר. הצוות עובד על פי Scrum. הפרויקט החל בקיץ שעבר, אך התוצאות הראשונות הגיעו רק באוקטובר - הצוות שלנו הורכב במלואו, ארכיטקטורת המערכת פותחה ונרכש ציוד. כעת יש לצוות 16 אנשים, שישה מהם מעורבים בפיתוח backend ו-frontend, שלושה מהם מעורבים בניתוח מערכות. שישה אנשים נוספים מעורבים בבדיקות ידניות, עומס, אוטומטיות ותחזוקת מוצר. בנוסף, יש לנו מומחה SRE.

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

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

ישיבת צוות מרחוק

פגישות במהלך עבודה מרחוק

ערימת טכנולוגיה של הפתרון

המאגר הסטנדרטי וכלי CI/CD עבור X5 הוא GitLab. אנו משתמשים בו לאחסון קוד, בדיקות רציפות ופריסה לשרתי בדיקה וייצור. אנו משתמשים גם בפרקטיקה של סקירת קוד, כאשר לפחות 2 עמיתים צריכים לאשר שינויים שבוצעו על ידי המפתח בקוד. מנתחי קוד סטטי SonarQube ו-JaCoCo עוזרים לנו לשמור על הקוד שלנו נקי ולהבטיח את הרמה הנדרשת של כיסוי בדיקות יחידה. כל השינויים בקוד חייבים לעבור את הבדיקות הללו. כל סקריפטי הבדיקה המופעלים באופן ידני אוטומטיים לאחר מכן.

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

משימה 1. הצורך בהרחבה אופקית של המערכת

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

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

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

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

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

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

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

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

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

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

משימה 4: עיבוד מחדש וניטור בתור:

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

כדי ליישם סכימה כזו, היינו צריכים את הדברים הבאים: לשלב את הפתרון הזה עם Spring ולהימנע משכפול קוד. במהלך הגלישה ברשת נתקלנו בפתרון דומה המבוסס על Spring BeanPostProccessor, אך הוא נראה לנו מסורבל שלא לצורך. הצוות שלנו עשה פתרון פשוט יותר המאפשר לנו להשתלב במחזור האביב ליצירת צרכנים ובנוסף להוסיף צרכנים לנסות שוב. הצענו אב טיפוס של הפתרון שלנו לצוות האביב, אתה יכול לראות אותו כאן. מספר הצרכנים לנסות מחדש ומספר הניסיונות עבור כל צרכן מוגדרים באמצעות פרמטרים, בהתאם לצרכי התהליך העסקי, וכדי שהכל יעבוד, כל מה שנותר הוא להוסיף את ההערה org.springframework.kafka.annotation.KafkaListener , המוכר לכל מפתחי Spring.

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

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

תפעול פלטפורמה

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

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

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

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

מקור: www.habr.com