שירותי עיצוב ארכיטקטורה עבור 1C-Bitrix

עיצוב ארכיטקטורת פרויקט על 1C-Bitrix: הימנעות מטעויות נפוצות

נתקלנו פעמים רבות בפרויקטים שבהם ארכיטקטורת 1C-Bitrix שגויה הובילה לפגיעה בביצועים. קטלוג של 80K פריטים היה מגיש עמוד ב-5 שניות — אפילו עם מטמון ריק. הארכיטקטורה קובעת את הביצועים ואת עלויות התחזוקה. טעויות ארכיטקטוניות מצטברות, ולאחר שנה הופכות לריפקטורינג גדול שעולה פי כמה מתכנון ראשוני. לפי הניסיון שלנו, עלויות ריפקטורינג כאלה יכולות להיות פי 3–4 מהתקציב המקורי, שלא לדבר על אובדן הכנסות בזמן השבתה. לפי התיעוד הרשמי, החלטות יסודיות על אחסון נתונים ומטמון מתקבלות בהתחלה ומאוחר יותר משתנות בעלות גבוהה — הגירה מלאה של סוגי אחסון יכולה לקחת 6–8 שבועות.

הניסיון שלנו מראה: ארכיטקטורת פרויקט נכונה מההתחלה חוסכת עד 40% מתקציב הפיתוח. אנו מתכננים מבנה נתונים, מטמון, קנה מידה ואינטגרציות — תוך התחשבות בצמיחה ל-500K מוצרים ובעומסי שיא במהלך Black Friday (2000+ RPS). כל פרויקט עובר בדיקות עומס עם תעבורה סינתטית של 10K משתמשים בו-זמנית כדי למנוע הפתעות בייצור. ארכיטקטורה אופטימלית מפחיתה את דרישות האירוח ב-30–50%, וחוסכת $500–$2000 בחודש על תשתית ענן. אם אתם מזהים את התסמינים האלה, צרו קשר לבדיקת ארכיטקטורה לפני שריפקטורינג יקר הופך לבלתי נמנע.

כיצד לבחור סוג אחסון עבור 1C-Bitrix?

זו ההחלטה הארכיטקטונית הראשונה והיקרה ביותר. מעבר מאינפובלוקים ל-Highload מאוחר יותר פירושו שכתוב של כל הרכיבים, התבניות, המסננים ומדדי החיפוש — בדרך כלל בעלות של $20K–$50K עבור חנות בינונית.

אינפובלוקים רגילים עובדים דרך הטבלאות b_iblock_element ו-b_iblock_element_property. מאפיינים מאוחסנים במודל EAV — כל ערך בשורה נפרדת של b_iblock_element_property. עם 50 מאפיינים ו-100K אלמנטים, מקבלים 5 מיליון שורות בטבלה אחת. MySQL מתחיל להיתקע על JOINs במהלך סינון — מסנן פאקטים יכול לקחת 3–5 שניות אפילו עם אינדקסים סבירים.

אינפובלוקים מתאימים ל:

• תוכן עד 10–50K אלמנטים — מאמרים, חדשות, מבצעים
• ישויות שצריכות עורך ויזואלי ומודול SEO
• אלמנטים עם ירושת מאפיינים מסעיפים

בלוקי Highload הם טבלאות שטוחות. ישות אחת — טבלה אחת עם עמודות. אין EAV. סינון על עמודות עם אינדקס עובד בסדר גודל מהר יותר. קטלוג של 200K פריטים עם אינדקס פאקטים (b_catalog_sm_*) מספק מסננים ב-50ms במקום 3 שניות — זה פי 60 מהר יותר מאינפובלוקים על קטלוגים גדולים.

בלוקי Highload נדרשים עבור:

• קטלוגים > 50K פריטים
• נתוני ייחוס שנטענים בכל טעינת עמוד (ערים, מותגים, מאפיינים — לעיתים קרובות 10K+ רשומות)
• נתונים עם כתיבות תכופות — לוגים, פניות, היסטוריה (100+ כתיבות בדקה)
• ישויות הדורשות שאילתות SQL ישירות ואגרגציות

D7 ORM וטבלאות מותאמות אישית — עבור לוגיקה עסקית שלא מתאימה למודל האינפובלוקים. קשרי Many-to-many, שדות מחושבים, אגרגציות מותאמות אישית. Bitrix\Main\ORM\Data\DataManager מספק בטיחות טיפוסים, ולידציה ומערכת אירועים. עם זאת, תצטרכו לכתוב את פאנל הניהול מאפס — בערך 40–60 שעות עבור ישות טיפוסית.

קנה מידה של 1C-Bitrix ללא פגיעה בביצועים

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

השלב הראשון — העברת סשנים מקבצים ל-Redis. בלי זה, שרת אינטרנט שני חסר תועלת: משתמש מתחבר לשרת A, הבקשה הבאה הולכת לשרת B, הסשן לא נמצא — התנתקות. ב-.settings.php:

'session' => ['value' => ['mode' => 'redis', 'host' => '127.0.0.1', 'port' => 6379]] 

הבא:

• nginx upstream או HAProxy מחלקים בקשות. מודול "Web Cluster" של Bitrix תומך בקלאסטרינג, אך דורש רישיון "Business" ומעלה
• CDN לקבצים סטטיים — 'session' => ['value' => ['mode' => 'redis', 'host' => '127.0.0.1', 'port' => 6379]] , JS, CSS. השרת מפסיק לבזבז משאבים על הגשת תמונות (מפחית עומס CPU ב-30–40%)
• שכפול MySQL — master לכתיבות, slave לקריאות. Bitrix תומך בעד 9 חיבורי slave דרך /upload/. עם זאת, יש פיגור שכפול — מוצר נוסף, אבל ב-slave הוא מופיע אחרי 0.5–2 שניות. השתמשו בקריאות דביקות לנתונים קריטיים

קנה מידה אנכי זול ומהיר יותר בהתחלה:

• .settings.php כל שאילתה כבדה. אינדקס מרוכב אחד על EXPLAIN (IBLOCK_PROPERTY_ID, VALUE) מאיץ סינון פי 10
• מטמון רב-שכבתי: מטמון מנוהל של Bitrix → memcached → אתר מרוכב. בדקו את שיעור הפגיעות בפאנל "ביצועים" — אם מתחת ל-90%, משהו לא תקין
• OPcache עם JIT על PHP 8.1+ — האצה חינמית של 15–30%

מצב אתר מרוכב יכול להגיש עמודים ב-0.1 שניות למשתמשים אנונימיים — אנו משתמשים בו עבור 80% מהתעבורה.

הורדת תהליכים כבדים מהמונולית

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

ייבוא/ייצוא הוא הכאב הנפוץ ביותר. החלפה עם 1C דרך b_iblock_element_property נועלת טבלאות אינפובלוקים במהלך הייבוא. 100K פריטים — זה 20–40 דקות שבהן הסינון באתר מואט. פתרון: הורידו את הייבוא ל-worker נפרד דרך RabbitMQ, כתבו לטבלת ביניים, ואז החליפו אטומית.

• חיפוש — Elasticsearch במקום CIBlockCMLImport המובנה. חיפוש טקסט מלא ופאקטים, השלמה אוטומטית, תיקון שגיאות כתיב. העומס על MySQL מוסר לחלוטין. אנו משיגים <100ms לחיפוש טקסט מלא על 500K מוצרים.
• התראות — push, SMS, דוא"ל דרך תור. search.title הוא סינכרוני — עד שהדוא"ל נשלח, המשתמש מחכה לתגובת השרת. תור (רשימת RabbitMQ או Redis) מפחית את זמן התגובה ב-200–500ms.
• יצירת דוחות — PDF, Excel על נפחים גדולים (10K+ שורות). תהליך נפרד, התוצאה — קישור להורדה.

API: REST, GraphQL, Webhooks

REST API של Bitrix (CEvent::Send()) מכסה CRM, משימות, דיסק, אבל לא מכסה קטלוג ואינפובלוקים במידה הנדרשת. עבור SPA על React/Vue, צריך לכתוב נקודות קצה משלכם דרך /rest/.

• GraphQL — עבור אפליקציות מובייל שבהן תעבורה יקרה. הלקוח מבקש רק את השדות הדרושים — גודל המטען קטן ב-60–80%.
• Webhooks — מודל אירועים: הזמנה חדשה → POST לכתובת חיצונית. אין צורך לסקור את ה-API כל 5 דקות.
• גרסאות — Bitrix\Main\Engine\Controller, /api/v1/. בלי זה, עדכוני API שוברים את כל הצרכנים בבת אחת.
• OpenAPI/Swagger — יצירת תיעוד אוטומטית. API ללא תיעוד נשכח אפילו על ידי מחברו לאחר חודש.

מקורות עיקריים של חוב טכני ב-Bitrix

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

1. ליבה ישנה במקום D7 — /api/v2/ במקום LINKED_PRODUCTS. הליבה הישנה לא תומכת בתכונות ORM, איטית יותר (פי 2–3 יותר שאילתות), ו-Bitrix בסופו של דבר תפסיק לתמוך בה.
2. SQL ישיר בתבניות רכיבים — CIBlockElement::GetList() ישירות ב-\Bitrix\Iblock\Elements\ElementTable::getList(). העבירו למחלקות שירות, החליפו ב-ORM.
3. לוגיקה עסקית ב-$DB->Query("SELECT...") — קובץ שאמור להכין נתונים לתבנית, לא לחשב הנחות ולבדוק הרשאות גישה.

גישה: PHPStan רמה 5+ לזיהוי בעיות (אנו מוצאים 50–200 הפרות בפרויקט טיפוסי), מטריצה של "השפעה עסקית / עלות תיקון", ריפקטורינג מדורג לפי ספרינטים. לא הכל בבת אחת — אבל המגמה חייבת להיות יורדת.

הימנעות מריפקטורינג יקר

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

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

תיעוד: ADR במקום קבצי Word

• ADR — Architecture Decision Records. קובץ קצר: הקשר, החלטה, השלכות. כפי שהניסיון מראה, תיעוד החלטה ארכיטקטונית ברגע שהיא מתקבלת חוסך ניחושים אינסופיים אחרי שישה חודשים. לדוגמה, שנה לאחר מכן, מפתח חדש פותח ADR ומבין בחמש דקות למה נבחר Highload לקטלוג, במקום לנחש שלושה ימים.
• דיאגרמות — שרתים, זרמי נתונים, נקודות אינטגרציה. PlantUML או Mermaid, מאוחסנים במאגר ליד הקוד.
• דיאגרמות ER — אינפובלוקים, מאפיינים, קשרים. בלי סכמה, אפילו המחבר לא יזכור אחרי שישה חודשים למה המאפיין template.php מפנה לאינפובלוק אחר דרך binding במקום לספר ייחוס של Highload.
• Runbook — פריסה, גלגול לאחור, קנה מידה, פעולות בזמן קריסה. כי הקריסה תתרחש במוצאי שבת כשהארכיטקט לא זמין.

כיצד אנו מתכננים ארכיטקטורה

1. ניתוח דרישות עסקיות ומאפייני עומס (RPS שיא, גודל קטלוג, תרחישים טיפוסיים)
2. עיצוב מבנה נתונים — בחירת אינפובלוקים/Highload/D7 ORM, קשרים, אינדקסים
3. קביעת סכמות מטמון ותורים (Redis, RabbitMQ, מרוכב)
4. אב-טיפוס ובדיקות עומס על נתונים אמיתיים (200K רשומות, 30+ מאפיינים)
5. תיעוד — ADR, דיאגרמות ER, runbook, מפרטי API
6. סקירת פרויקט — פנימית ועם הלקוח

עבור חנות מקוונת אחת, תכננו ארכיטקטורה על בלוקי Highload ו-Elasticsearch. סינון מוצרים עד 50ms, זמן לתגובה ראשונה 0.3 שניות. חיסכון בעלויות אירוח: 45% בחודש.

היקף העבודה

אנחנו צוות של מומחים מוסמכים עם ניסיון של למעלה מ-8 שנים בהטמעת 1C-Bitrix. סיפקנו ארכיטקטורת פרויקט ל-50+ פרויקטים עם קטלוגים עד 300K מוצרים ועומס עד 10K משתמשים פעילים בו-זמנית. אנו מבטיחים שהארכיטקטורה המתוכננת תעמוד בעומסי שיא ולא תדרוש ריפקטורינג בשלוש השנים הבאות.

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

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