פיתוח מסוף מסחר וובי עם גרפים וספר פקודות

מדוע מסוף מסחר וובי מאבד פקודות בשעות שיא

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

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

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

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

מה נותן מסוף מעובד: אפקט במדדים

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

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

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

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

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

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

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

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

כיצד מתבצעת העבודה: שלבי הטמעת המסוף

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

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

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

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

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

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

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

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

תוצרי הפרויקט: תצורות, תרשימים, נהלים

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

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

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

מה היה לפני

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

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

מה שינו ומה נלקח בקבלה

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

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

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

מה לעשות אם המסוף כבר עובד על פתרון מוכן

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

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

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

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

שאלות טכניות שנשאלות לרוב

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

מה קורה בתקלה של ספק נתונים?

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

אפשר להעביר את המסוף הוובי לשרתים שלנו?

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

מה כלול בתמיכה לאחר המסירה?

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

נדון במשימה: מה נדרש מכם בהתחלה

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

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

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

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