لسوء الحظ ، هذا المصطلح ليس له نظير جيد في اللغة الروسية. ويكيبيديا تعطي "متعدد الإيجارات ، إيجار متعدد". يشار إلى هذا أحيانًا باسم "الملكية المتعددة". يمكن أن تكون هذه المصطلحات مربكة إلى حد ما ، لأن الموضوع لا يرتبط بطبيعته بالإيجار أو الملكية. هذه مسألة هندسة البرمجيات وتنظيم عملها. وهذا الأخير لا يقل أهمية.
بدأنا في تشكيل فهمنا لمفهوم تعدد الإيجارات في نفس الوقت الذي بدأنا فيه تصميم نهج لنموذج الخدمة السحابية 1C: عملية المؤسسة. كان هذا قبل عدة سنوات. ومنذ ذلك الحين ، يتسع فهمنا باستمرار. نحن نكتشف باستمرار المزيد والمزيد من الجوانب الجديدة لهذا الموضوع (الإيجابيات والسلبيات والصعوبات والميزات وما إلى ذلك).
في بعض الأحيان ، يفهم المطورون تعدد الشركات على أنه موضوع بسيط للغاية: "من أجل تخزين بيانات العديد من المؤسسات في قاعدة بيانات واحدة ، تحتاج إلى إضافة عمود بمعرف المؤسسة إلى جميع الجداول وتعيين عامل تصفية عليه." بالطبع ، بدأنا أيضًا دراستنا للقضية منذ تلك اللحظة. لكنهم سرعان ما أدركوا أن هذا كان مجرد فسحة واحدة (أيضًا ، بالمناسبة ، ليست سهلة). بشكل عام ، هذا "بلد كامل".
يمكن وصف الفكرة الأساسية لمؤسسات متعددة الإيجارات بشيء من هذا القبيل. التطبيق الشائع هو كوخ عائلي واحد يستخدم بنيته التحتية (الجدران والسقف وإمدادات المياه والتدفئة وما إلى ذلك). تطبيق متعدد الايجارات هو مبنى سكني. في ذلك ، تستخدم كل عائلة نفس تكوين البنية التحتية ، ولكن يتم تنفيذ البنية التحتية نفسها للمنزل بأكمله ككل.
هل نهج تعدد الإيجارات جيد أم سيئ؟ هناك آراء مختلفة جدًا حول هذا. يبدو أنه لا يوجد "جيد أو سيء" على الإطلاق. أنت بحاجة إلى مقارنة الإيجابيات والسلبيات في سياق مهام محددة لحلها. لكن هذه قضية منفصلة ...
في أبسط معانيها ، فإن الهدف من التعددية هو تقليل تكلفة صيانة التطبيق من خلال "تقاسم" تكاليف البنية التحتية. هذه هي نفس حركة تقليل تكلفة التطبيق من خلال استخدام حل الإعارة (ربما مع التخصيص والتحسين) ، وليس كتابة "حسب الطلب". فقط في حالة واحدة تكون التنمية اجتماعية ، وفي الحالة الأخرى - الاستغلال.
ونكرر أنه لا يوجد ارتباط مباشر بطريقة البيع. يمكن أيضًا استخدام الهندسة المعمارية متعددة المؤسسات في البنية التحتية لتكنولوجيا المعلومات الخاصة بالشركات أو الإدارات لأتمتة عدد كبير من الفروع من نفس النوع ، والمؤسسات القابضة.
يمكننا أن نقول أن الشركات المتعددة ليست مجرد مسألة تنظيم تخزين البيانات. هذا هو نموذج التطبيق بأكمله (بما في ذلك جزء مهم من جوانب بنيته ، ونموذج النشر ، وتنظيم الخدمة).
يبدو لنا أن الأمر الأكثر صعوبة وإثارة للاهتمام في نموذج التعددية هو أن جوهر التطبيق "متشعب". يعمل جزء من الوظيفة مع مناطق بيانات محددة (شقق) و "غير مهتم" بحقيقة وجود مستأجرين في شقق أخرى. والبعض يرى المنزل ككل ويعمل على الفور لجميع السكان. في الوقت نفسه ، لا يمكن للأخير تجاهل حقيقة أن هذه لا تزال شقق منفصلة ، ومن الضروري ضمان المستوى الضروري من الدقة والأمان.
في 1C: Enterprise ، يتم تنفيذ نموذج التعددية على مستوى العديد من التقنيات. هذه هي آليات 1C: منصة المؤسسة ، الآليات"و""، الآليات (مكتبات النظم الفرعية القياسية).
يساهم كل عنصر من هذه العناصر في إنشاء البنية التحتية العامة لمبنى سكني. لماذا يتم تطبيق هذا في العديد من التقنيات وليس في واحدة ، على سبيل المثال ، في منصة؟ بادئ ذي بدء ، لأنه ، في رأينا ، من المناسب تمامًا تعديل بعض الآليات لخيار نشر معين. لكن بشكل عام ، هذا ليس سؤالًا سهلاً ، ونحن نواجه دائمًا خيارًا - على أي مستوى من الأفضل تنفيذ جانب أو آخر من جوانب التعددية.
من الواضح أن الجزء الأساسي من الآليات يجب أن يتم تنفيذه في المنصة. حسنًا ، على سبيل المثال ، الفصل الفعلي للبيانات. ما الذي يبدأ عادة محادثة حول الشركات المتعددة. لكن في النهاية ، "سافر" نموذج الشركات المتعددة الاستئجار عبر جزء كبير من آليات المنصة وتطلب تحسينها ، وفي بعض الحالات ، إعادة التفكير.
على مستوى المنصة ، قمنا بتنفيذ الآليات الأساسية بالضبط. أنها تسمح لك بإنشاء تطبيقات تعمل في نموذج متعدد الشركات. ولكن لكي "تعيش وتعمل" التطبيقات في مثل هذا النموذج ، يجب أن يكون لديك نظام لإدارة "نشاط حياتها". 1cFresh تقنيات وطبقة موحدة من منطق الأعمال على مستوى BSP هي المسؤولة عن ذلك. تمامًا كما هو الحال في مبنى سكني ، توفر البنية التحتية للمقيمين كل ما يحتاجون إليه ، لذلك توفر تقنيات 1cFresh كل ما هو ضروري للتطبيقات التي تعمل في نموذج متعدد الشركات. وحتى تتمكن التطبيقات من التفاعل مع هذه البنية التحتية (بدون تعديلات كبيرة) ، يتم وضع "الموصلات" المقابلة في شكل أنظمة فرعية BSP.
فيما يتعلق بآليات النظام الأساسي ، من السهل أن نرى أنه عندما نكتسب الخبرة ونطور السحابة 1C: حالة استخدام المؤسسة ، نقوم بتوسيع قائمة الآليات التي تشارك في هذه البنية. لنأخذ مثالاً واحداً. في نموذج التوظيف المتعدد ، تتغير أدوار المشاركين في خدمة التطبيق بشكل كبير. يتم زيادة دور (مستوى المسؤولية) للمسؤولين عن تشغيل التطبيقات بشكل كبير. أصبح من الضروري بالنسبة لهم أن يكون لديهم أدوات تحكم في التطبيق أكثر قوة. لأن مستخدمي التطبيق (المقيمين) يثقون أولاً وقبل كل شيء بالمزود الذي يعملون معه. للقيام بذلك ، قمنا بتنفيذ الإصدار 8.3 جديد . تسمح هذه الآلية لمسؤولي الموفر بتقييد حرية مطوري التطبيقات إلى المستوى الضروري من الأمان - في الواقع ، لعزل تشغيل التطبيق لكل مستأجر في وضع حماية معين.
لا تقل أهمية التصميم عن إدارة التطبيقات التي تعمل في وضع التشغيل المتعدد (ما يتم تنفيذه في تقنيات 1cFresh و BSP). هنا ، بالمقارنة مع نموذج النشر المعتاد ، تزداد متطلبات أتمتة عمليات الإدارة بشكل كبير. هناك العشرات من هذه العمليات: إنشاء مناطق بيانات جديدة ("شقق") ، وتحديث التطبيقات ، وتحديث المعلومات التنظيمية ، والنسخ الاحتياطي ، وما إلى ذلك ، وبالطبع ، تتزايد متطلبات مستوى الموثوقية والتوافر. على سبيل المثال ، لضمان تفاعل موثوق بين التطبيقات ومكونات نظام التحكم ، قمنا بتطبيق تقنية نظام استدعاء غير متزامن مع تسليم مضمون.
النقطة الدقيقة للغاية هي الطريقة التي يتم بها مشاركة البيانات والعمليات. يبدو الأمر بسيطًا (إذا بدا لشخص ما) فقط للوهلة الأولى. أكبر صعوبة هي التوازن بين مركزية البيانات والعمليات واللامركزية. من ناحية أخرى ، تسمح لك المركزية بتقليل التكاليف (مساحة القرص ، موارد المعالج ، جهود المسؤول ...). من ناحية أخرى ، يقيد حرية "السكان". هذه مجرد لحظة من لحظات "تشعب" التطبيق ، عندما يحتاج المطور إلى التفكير في نفس الوقت في التطبيق بالمعنى الضيق (خدمة "شقة" واحدة) وبمعنى عام (خدمة جميع " المستأجرين "مرة واحدة).
كمثال على مثل هذه "المعضلة" ، يمكن الاستشهاد بمعلومات مرجعية. بالطبع ، هناك إغراء كبير لجعله مشتركًا لجميع "سكان" المنزل. يتيح لك ذلك تخزينه في نسخة واحدة ، وتحديثه للجميع مرة واحدة. ولكن يحدث أن بعض المستأجرين يحتاجون إلى تغييرات محددة. من الغريب أن يحدث هذا في الممارسة العملية ، حتى بالنسبة للمعلومات التي يحددها المنظمون (هيئات الدولة). اتضح سؤال صعب: الاختلاط أو عدم الاختلاط؟ من المغري ، بالطبع ، تقديم معلومات عامة للجميع وخاصة لمن يرغبون. وهذا يؤدي بالفعل إلى تنفيذ صعب للغاية. لكننا نعمل على ذلك...
مثال آخر هو تصميم تنفيذ العمليات المنتظمة (يتم تشغيلها وفقًا لجدول زمني ، ويبدأ بواسطة نظام التحكم ، وما إلى ذلك). من ناحية ، يمكن تنفيذها لكل منطقة بيانات على حدة. إنه أسهل وأكثر ملاءمة. ولكن ، من ناحية أخرى ، فإن مثل هذه التفاصيل الدقيقة تخلق عبئًا كبيرًا على النظام. لتقليل العبء ، من الضروري تنفيذ العمليات الاجتماعية. لكنهم يحتاجون إلى مزيد من الدراسة الدقيقة.
بالطبع هذا يطرح سؤالا مهما جدا. وكيف يمكن لمطوري التطبيقات التأكد من أنهم يعملون في وضع التشغيل المتعدد؟ ما الذي يجب عليهم فعله من أجل هذا؟ بالطبع ، نحن نسعى جاهدين للتأكد من أن عبء المشكلات التكنولوجية والبنية التحتية يقع على عاتق التكنولوجيا الموردة قدر الإمكان ، ولا يفكر مطور التطبيق إلا في مهام منطق الأعمال. ولكن كما هو الحال مع القضايا المعمارية الهامة الأخرى ، يحتاج مطورو التطبيقات إلى بعض الفهم للعمل في نموذج متعدد الشركات وسيتطلب الأمر بعض الجهد في تطوير التطبيق. لماذا؟ لأن هناك لحظات لا تستطيع التكنولوجيا توفيرها تلقائيًا دون مراعاة دلالات البيانات. على سبيل المثال ، نفس تعريف حدود التنشئة الاجتماعية للمعلومات. لكننا نحاول أن نجعل هذه الصعوبات صغيرة. توجد بالفعل أمثلة على تنفيذ مثل هذه التطبيقات.
من النقاط المهمة في سياق تنفيذ تعدد الإيجارات في 1C: Enterprise هي أننا نقوم بإنشاء نموذج هجين يمكن أن يعمل فيه تطبيق واحد في الوضع متعدد الاستئجار وفي الوضع العادي. هذه مهمة صعبة للغاية وهي موضوع مناقشة منفصلة.
المصدر: www.habr.com