סטילס מהסרט "היקום הסודי שלנו: החיים הנסתרים של התא"

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

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

בנוסף, צורכי הרגולטורים, הרוסים והזרים, הולכים וגדלים.

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

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

פרהיסטוריה

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

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

דרישות לפתרון חדש

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

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

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

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

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

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

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

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

פיתוח

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

אנו משתמשים בשרת ה-HTTP המובנה ב-Tarantool מכיוון שאיננו צריכים לסיים הפעלות SSL, והביצועים שלו מספיקים לנו.

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

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

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

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

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

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

הטמיע מערכת אימות.

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

• T-Connect: מטפל בחיבורים נכנסים, מעבד מוגבל, צריכת זיכרון נמוכה, חסר מצב.
• IB-Core: הופך את הנתונים שהוא מקבל באמצעות פרוטוקול Tarantool, כלומר, הוא פועל עם טבלאות. זה גם לא מאחסן מצב והוא ניתן להרחבה.
• אחסון: מאחסן נתונים בלבד, אינו משתמש בהיגיון כלשהו. תפקיד זה מיישם את הממשקים הפשוטים ביותר. ניתן להרחבה הודות ל-vshard.

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

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

בדיקה

כבר מתחילת הפרויקט, החלטנו שננסה ליישם פיתוח מונחה מבחן. אנו כותבים בדיקות יחידה ב-Lua באמצעות מסגרת tarantool/tap, ומבחני אינטגרציה ב-Python באמצעות מסגרת pytest. במקביל, אנו מערבים גם מפתחים וגם אנליסטים בכתיבת מבחני אינטגרציה.

כיצד אנו משתמשים בפיתוח מונע מבחן?

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

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

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

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

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

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

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

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

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

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

שירותים

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

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

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

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

מערכות ישנות

לא כל המערכות הוותיקות שלנו יכולות להתקשר אלינו באמצעות HTTP ולהשתמש ב-GraphQL, למרות שהן תומכות בפרוטוקול. לכן, יצרנו מנגנון המאפשר לשכפל נתונים למערכות אלו.

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

שיפורים חדשים

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

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

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

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

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

מסקנה

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

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

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

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

אין שום דבר רע בלואה. כל אחד יכול ללמוד לכתוב בו: מפתח Java, מפתח JavaScript, מפתח Python, Front-end או Back-end. אפילו האנליסטים שלנו כותבים על זה.

כשאנחנו מדברים על העובדה שאין לנו SQL, זה מפחיד אנשים. "איך משיגים נתונים בלי SQL? האם זה אפשרי? בְּהֶחלֵט. במערכת כיתות OLTP, אין צורך ב-SQL. יש אלטרנטיבה בצורת שפה כלשהי שמחזירה אותך מיד לתצוגה מוכוונת מסמך. לדוגמה, GraphQL. ויש אלטרנטיבה בצורה של מחשוב מבוזר.

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

מקור: www.habr.com