בניית מבנה רב-אתרי על 1C-Bitrix היא הפתרון ההגיוני היחיד כאשר לקוח משיק מותג שני. רישיון כפול, סנכרון כפול עם 1C, פאנל ניהול כפול. חודש לאחר מכן מתברר: בסיס המוצרים משותף, מנהלים נמצאים בפאנלים שונים, סנכרון המלאי נשבר. אנו מתכננים ארכיטקטורות רב-אתריות כבר למעלה מ-10 שנים — שותפי Bitrix מוסמכים עם יותר מ-100 פרויקטים מוצלחים — ומכירים את כל המלכודות: מדליפות מטמון ועד מפות אתר שגויות. צרו קשר לייעוץ — נבחן את הפרויקט שלכם תוך יומיים.
מתי ריבוי אתרים מוצדק?
חברת אחזקות עם חמישה מותגים. זכיינות עם משרדים אזוריים. קבוצת חברות שבה לכל כיוון יש דומיין משלו אך בסיס מוצרים משותף. החלופה היא חמש התקנות Bitrix נפרדות, חמישה רישיונות, חמישה שרתים, חמישה סנכרונים עם 1C. ריבוי אתרים על התקנה אחת — שרת אחד, רישיון אחד (החל מגרסת "Business"), פאנל ניהול אחד. החיסכון ברישיונות ותחזוקה מגיע ל-30–50% (לדוגמה, חיסכון של $3,000 לשנה לכל התקנה). בסיס נתונים משותף מפחית את עלויות הרישוי ב-50% בהשוואה להתקנות נפרדות.
לא מוצדק — כאשר לאתרים אין חפיפה בנתונים, בקהל או בלוגיקה עסקית. אז קישור דרך בסיס נתונים אחד רק מסבך את הפריסה ומגדיל את רדיוס הפגיעה במקרה של תקלה.
ארכיטקטורה: בסיס נתונים משותף לעומת נפרד
Bitrix תומך בשני מצבי ריבוי אתרים.
בסיס נתונים משותף, קבצים משותפים
כל האתרים חיים בבסיס MySQL אחד ובמערכת קבצים אחת. ההפרדה מתבצעת דרך SITE_ID בטבלאות. ניתן לחבר בלוק מידע למספר אתרים דרך b_iblock_site. משתמש שנרשם באתר A מאומת אוטומטית באתר B (טבלת b_user משותפת, סשנים משותפים).
מלכודות:
-
מטמון רכיבים — אם SITE_ID לא מצוין במפתח המטמון, רכיב news.list באתר B יחזיר נתונים שנשמרו במטמון עבור אתר A. רכיבי Bitrix סטנדרטיים בדרך כלל מתחשבים ב-SITE_ID, אך רכיבים מותאמים אישית לא עד שתוסיפו
$this->arParams['CACHE_GROUPS']ותכללו את SITE_ID ב-getAdditionalCacheID(). עם 5 אתרים החולקים קטלוג של 50,000 פריטים, זמן רענון המטמון המלא מצטמצם ב-60% אם המפתחות מוגדרים כראוי. - הרשאות גישה — קבוצות משתמשים משותפות. מנהל תוכן של אתר A עלול לערוך בטעות בלוק מידע של אתר B אם לא מוגדרת מטריצת הרשאות ברמת בלוק המידע.
- מודול SEO — sitemap.xml נוצר דרך seo.sitemap.run. יש ליצור מפה נפרדת לכל SITE_ID, אחרת כתובות URL מאתר B יופיעו במפת האתר של אתר A.
בסיסי נתונים נפרדים
מוגדר דרך .settings.php, סעיף connections. כל אתר מתחבר לבסיס נתונים משלו. בידוד נתונים מלא, אך ללא משתמשים משותפים או בלוקי מידע משותפים. בשימוש נדיר — בעיקר להפרדה מלאה כאשר פאנל ניהול משותף נדרש רק לניהול תשתית השרת.
איך פותרים את בעיית המטמון המשותף?
במבנה רב-אתרי, המטמון הוא כאב הראש המרכזי. ללא קישור ל-SITE_ID, אתר אחד עלול להציג נתונים מאתר אחר. הפתרון הוא ברמת המפתח: ב-result_modifier.php, הוסיפו SITE_ID למפתח המטמון דרך $arParams['CACHE_GROUPS'] ו-CPHPCache::SetCache(). עבור מטמון מרוכב (Composite), הגדירו דומיין נפרד במודול "Composite Site". זה מבטיח שתמונת ה-HTML של אתר A לא תוגש בדומיין B.
מידע נוסף על מנגנוני עוגיות — ויקיפדיה.
בסיס משתמשים משותף
היתרון המרכזי של בסיס נתונים משותף הוא אימות אחיד. משתמש נרשם ב-brand-a.com, מבקר ב-brand-b.com — כבר מאומת. זה עובד דרך טבלת b_user המשותפת וסשנים משותפים.
אבל יש מלכוד. סשנים נשמרים בקבצים כברירת מחדל — ב-/bitrix/sessions/. עם שני דומיינים, עוגיית PHPSESSID לא מועברת ביניהם (דומיינים שונים, עוגיות שונות). פתרונות:
- SSO דרך טוקן — אנו מעבירים טוקן חד-פעמי בכתובת ה-URL בעת מעבר בין דומיינים, ובצד המקבל נוצר סשן. מודול socialservices או handler מותאם אישית.
- דומיין עליון משותף — .company.com, העוגייה מוגדרת על .company.com, עובדת עבור a.company.com ו-b.company.com.
- Redis לסשנים — סשנים נשמרים מרכזית, אך בעיית העוגיות נשארת. Redis פותר משימה אחרת — קנה מידה אופקי, לא אימות חוצה דומיינים.
תוכן: מה לשתף, מה להפריד
בלוקי מידע מחוברים לאתרים דרך הגדרות הניהול. בלוק מידע אחד יכול להיות נגיש במספר אתרים. תרחיש טיפוסי: קטלוג מוצרים — משותף (SITE_ID: s1, s2, s3), חדשות — לכל אתר יש משלו.
נקודה חשובה: מאפייני בלוק המידע משותפים. לא ניתן להוסיף מאפיין "מבצע" רק עבור אתר A אם בלוק המידע מחובר לאתרים A, B, C. כל שלושת האתרים יראו מאפיין זה. פתרון — השתמשו במאפיין מרובה מסוג "קישור לאתר" וסננו ברכיב.
קטלוג מסחרי. מודול הקטלוג מאפשר הגדרת סוגי מחירים שונים לאתרים שונים. אתר סיטונאי מציג מחירים סיטונאיים, אתר קמעונאי מציג מחירים קמעונאיים. יתרות מלאי משותפות או מופרדות דרך קישור לחנויות (b_catalog_store).
הגדרות SEO — תבניות META דרך iblock.type.edit מוגדרות ברמת בלוק המידע, לא ברמת האתר. עבור אתרים שונים עם בלוק מידע אחד, תצטרכו ליצור META פרוגרמטית ב-result_modifier.php, תוך החלפת הערכים הנדרשים לפי SITE_ID.
בעיות נפוצות בקנה מידה
- סנכרון 1C — מודול catalog.import.1c מייבא מוצרים לבלוקי מידע. אם הקטלוג משותף לשלושה אתרים, יש ייבוא אחד. אם לכל אתר יש קטלוג משלו — שלושה סנכרונים נפרדים, שלושה פרופילים ב-1C. עם 50K+ פריטים, כל סנכרון נועל טבלאות ל-15–30 דקות. אנו פורסים אותם על פני cron כדי למנוע חפיפות.
- חיפוש — search.title המובנה מאנדקס את כל האתרים לטבלת b_search_content אחת. התוצאות מסוננות לפי SITE_ID, אך האינדקס משותף. עם 5 אתרים של 100K עמודים כל אחד — אינדקס של חצי מיליון רשומות, אינדוקס מחדש אורך שעות. Elasticsearch במקום החיפוש המובנה — אם נפח הנתונים משמעותי.
- מטמון מרוכב (Composite) — מודול ה-Composite עובד נכון עם ריבוי אתרים אך דורש הגדרה נפרדת לכל דומיין. בלעדיה, תמונת ה-HTML של אתר A עלולה להיות מוגשת בדומיין B.
מה כלול בפיתוח רב-אתרי (תוצרים)
- בדיקת התשתית והאינטגרציות הקיימות.
- עיצוב ארכיטקטורה: מטריצת אתרים, בלוקי מידע, הרשאות גישה, תבניות.
- הגדרת ליבה: יצירת אתרים, קישור דומיינים, הגדרות סשן ומטמון.
- פיתוח תבניות: תבנית בסיס משותפת + תבניות אישיות לכל אתר.
- העברת תוכן והגדרת מודול SEO לכל דומיין.
- הגדרת סנכרון 1C (אם נדרש).
- בדיקת תרחישים חוצי אתרים: אימות, מטמון, מפת אתר.
- הדרכת עורכים לעבודה בפאנל ניהול אחיד.
- ניטור לאחר השקה.
- תיעוד ופרטי גישה.
איך להשוות בין בסיס נתונים משותף לנפרד?
בסיס נתונים משותף זול פי 2 ברישיונות וקל יותר לתחזוקה; נפרד מהיר יותר בעומסי שיא ומבודד תקלות. הבחירה תלויה ב-SLA ובתקציב: עבור רוב הפרויקטים, בסיס נתונים משותף עם מטמון נכון מספיק.
לוחות זמנים משוערים
| היקף | לוחות זמנים |
|---|---|
| 2-3 אתרים, קטלוג משותף, תבניות שונות | 6-10 שבועות |
| 5+ אתרים, קטלוגים נפרדים, SSO | 10-16 שבועות |
| רשת אזורית של 10+ אתרים עם אינטגרציית 1C | 14-24 שבועות |
התמחור מחושב באופן אישי לאחר ניתוח מפורט — נבחן את הפרויקט שלכם תוך יומיים.
אתגרים טיפוסיים ופתרונותיהם
| בעיה | פתרון |
|---|---|
| מטמון מאתר אחד דולף לאתר אחר | הוספת SITE_ID למפתח המטמון של הרכיב |
| אימות לא עובד בין דומיינים | SSO דרך טוקן חד-פעמי או דומיין עוגיות משותף |
| מודול SEO יוצר מפת אתר עם כתובות URL זרות | יצירת מפה נפרדת לכל SITE_ID |
| ייבוא 1C נועל טבלאות | פריסת ייבואים על פני cron ושימוש בפרופילים שונים |
השירותים שלנו כוללים פיתוח רב-אתרי 1C-Bitrix, ארכיטקטורת ריבוי אתרים Bitrix, קטלוג משותף למספר אתרים, אימות אחיד עם SSO, תבניות רב-אתריות, סנכרון 1C לריבוי אתרים, הגדרת מטמון Bitrix והערכת פרויקטים. עם ניסיון של למעלה מ-10 שנים ויותר מ-100 פרויקטי Bitrix רב-אתריים מוצלחים, אנו שותפים מוסמכים. צרו קשר להערכת הפרויקט שלכם. קבלו ייעוץ — נבחר את הארכיטקטורה האופטימלית ללא תשלומי יתר.