לגבי ריבוי דירות

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

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

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

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

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

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

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

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

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

ב-1C:Enterprise, מודל ריבוי הנכסים מיושם ברמת מספר טכנולוגיות. אלו הם המנגנונים של פלטפורמת 1C:Enterprise, המנגנונים של1C: טכנולוגיה לפרסום פתרונות 1cFresh"ו"1C: טכנולוגיית פיתוח פתרונות 1cFresh", מנגנונים BSP (ספריות של תת-מערכות סטנדרטיות).

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

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

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

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

מעניינת לא פחות היא הארכיטקטורה לניהול יישומים הפועלים במצב ריבוי דירות (מה מיושם בטכנולוגיות 1cFresh ו-BSP). כאן, בהשוואה למודל הפריסה המקובל, הדרישות לאוטומציה של תהליכי ניהול מוגברות משמעותית. ישנם עשרות תהליכים כאלה: יצירת אזורי נתונים חדשים ("דירות"), עדכון אפליקציות, עדכון מידע רגולטורי, גיבויים וכדומה. וכמובן, הדרישות לרמת האמינות והזמינות הולכות וגדלות. לדוגמה, כדי להבטיח אינטראקציה אמינה בין יישומים ורכיבי מערכת בקרה, הטמענו טכנולוגיית מערכת שיחות אסינכרונית עם אספקה ​​מובטחת.

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

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

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

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

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

מקור: www.habr.com