אינטגרציה עם CCXT: API אחיד לבורסות כפתרון מלא

אינטגרציית CCXT: היכן נשברת התקשורת עם הבורסות

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

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

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

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

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

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

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

מה נותן שכבת גישה אחודה לבורסות

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

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

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

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

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

מצבי חיבור לבורסות: מה לבחור

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

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

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

שלבי הטמעה: מביקורת ועד מסירה

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: הסרנו התאמות ידניות בין הבורסות

הלקוח — שירות מסחר שעבד עם חמש בורסות בו-זמנית. כל זירה חוברה בקונקטור נפרד: שמות משלה לזוגות מסחר, דיוק משלה למחיר ולנפח, קודי סטטוס משלה להזמנה. הנתונים התאחדו רק בטבלאות של האנליסט, וכל עיכוב בייצוא означаו שההחלטה מתקבלת לפי יתרות מיושנות.

מה היה לפני השינויים

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

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

מה שינינו

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

מה נהיה

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

במה שונה אינטגרציית CCXT מחיבורים ישירים

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

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

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

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

שאלות טכניות נפוצות על חיבור בורסות

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

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

מה יקרה בעת כשל בצד הבורסה?

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

איך מוסיפים בורסה חדשה?

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

אפשר לעבוד עם כמה בורסות בו-זמנית?

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

האם יש מגבלות בכלים?

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

ספרו על המשימה — נחזור עם הערכה ותוכנית

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

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

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

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