متأسفانه این اصطلاح مشابه روسی زبان خوبی ندارد. ویکی پدیا می دهد "چند اجاره، چند اجاره." گاهی اوقات به این "مالکیت چندگانه" گفته می شود. این اصطلاحات می توانند تا حدودی گیج کننده باشند، زیرا موضوع ذاتاً با اجاره یا مالکیت مرتبط نیست. این مسئله معماری نرم افزار و سازماندهی عملیات آن است. و دومی از اهمیت کمتری برخوردار نیست.
همزمان با طراحی رویکردی به مدل کار ابری (خدمات) در 1C:Enterprise، ما شروع به تدوین درک خود از چند اجاره‌نشینی کردیم. این چند سال پیش بود. و از آن زمان به بعد درک ما به طور مداوم گسترش یافته است. ما دائماً در حال کشف بیشتر و بیشتر جنبه های جدید این موضوع هستیم (مزایا، معایب، مشکلات، ویژگی ها و غیره).
گاهی اوقات توسعه دهندگان چند اجاره ای را به عنوان یک موضوع بسیار ساده درک می کنند: "برای اینکه داده های چندین سازمان در یک پایگاه داده ذخیره شوند، باید یک ستون با شناسه سازمان به همه جداول اضافه کنید و یک فیلتر روی آن تنظیم کنید." البته ما هم از همین لحظه بررسی موضوع را شروع کردیم. اما آنها به سرعت متوجه شدند که این تنها یک پاکسازی بود (به هر حال، آسان نیست). به طور کلی، این یک "کل کشور" است.
ایده اصلی چندتایی را می توان چیزی شبیه به این توصیف کرد. یک برنامه معمولی کلبه ای است که برای اقامت یک خانواده طراحی شده است که از زیرساخت های آن (دیوارها، سقف، تامین آب، گرمایش و غیره) استفاده می کند. یک برنامه چند اجاره ای یک ساختمان آپارتمانی است. در آن هر خانواده از یک زیرساخت استفاده می کند، اما زیرساخت خود برای کل خانه اجرا می شود.
آیا رویکرد چند اجاره ای خوب است یا بد؟ شما می توانید نظرات بسیار متفاوتی در این مورد پیدا کنید. به نظر می رسد که اصلاً "خوب یا بد" وجود ندارد. شما باید مزایا و معایب را در زمینه وظایف خاصی که حل می شود مقایسه کنید. اما این موضوع جداست...
در ساده‌ترین معنای آن، هدف چند اجاره‌نشینی کاهش هزینه‌های نگهداری یک برنامه کاربردی با «اجتماعی کردن» هزینه‌های زیرساخت است. این همان حرکتی است که کاهش هزینه یک برنامه کاربردی با استفاده از یک راه حل تولیدی (احتمالاً با سفارشی سازی و اصلاح) به جای نوشتن آن به صورت «سفارشی» است. تنها در یک مورد توسعه اجتماعی می شود و در مورد دیگر استثمار.
علاوه بر این، تکرار می کنیم، هیچ ارتباط مستقیمی با روش فروش وجود ندارد. معماری چند اجاره‌ای می‌تواند در زیرساخت‌های فناوری اطلاعات شرکتی یا دپارتمان برای خودکارسازی تعداد زیادی از شعب مشابه و شرکت‌های هلدینگ استفاده شود.
می توان گفت که چند اجاره ای فقط به سازماندهی ذخیره سازی داده ها نیست. این مدلی از نحوه عملکرد برنامه به عنوان یک کل است (شامل بخش قابل توجهی از معماری آن، مدل استقرار آن و سازمان نگهداری آن).
به نظر ما سخت ترین و جالب ترین چیز در مورد مدل چند اجاره ای این است که ماهیت برنامه "دوشاخه" است. بخشی از عملکرد با مناطق داده خاص (آپارتمان) کار می کند و به این واقعیت که ساکنان در آپارتمان های دیگر وجود دارد "علاقه مند نیست". و برخی خانه را به عنوان یک کل درک می کنند و برای همه ساکنان به طور همزمان کار می کنند. در عین حال، دومی نمی تواند این واقعیت را نادیده بگیرد که به هر حال اینها آپارتمان های جداگانه هستند و لازم است از سطح لازم از گرانوله بودن و امنیت اطمینان حاصل شود.
در 1C: Enterprise، مدل چند اجاره ای در سطح چندین فناوری پیاده سازی شده است. اینها مکانیسم های پلت فرم 1C: Enterprise، مکانیسم های"و""، مکانیسم ها (کتابخانه های زیرسیستم های استاندارد).
هر یک از این موارد به ساخت زیرساخت کلی یک ساختمان آپارتمان کمک می کند. چرا این در چندین فناوری پیاده سازی می شود و مثلاً در یک پلتفرم اجرا نمی شود؟ اول از همه، به این دلیل که برخی از مکانیسم ها، به نظر ما، برای اصلاح یک گزینه استقرار خاص کاملاً مناسب هستند. اما به طور کلی، این یک سؤال دشوار است و ما دائماً با یک انتخاب روبرو هستیم - در چه سطحی بهتر است این یا آن جنبه چند اجاره ای را اجرا کنیم.
بدیهی است که بخش اساسی مکانیسم ها باید در پلتفرم پیاده سازی شود. خوب، برای مثال، جداسازی واقعی داده ها. اینجاست که مردم معمولاً شروع به صحبت در مورد چند اجاره‌نشینی می‌کنند. اما در نهایت، مدل چند اجاره‌نشینی بخش قابل‌توجهی از مکانیسم‌های پلتفرم را «سفر» کرد و نیازمند اصلاح و در برخی موارد بازاندیشی آنها بود.
در سطح پلتفرم، دقیقاً مکانیسم های اساسی را پیاده سازی کردیم. آنها به شما اجازه می دهند برنامه هایی ایجاد کنید که در یک مدل چند اجاره ای اجرا شوند. اما برای اینکه برنامه‌ها در چنین مدلی «زندگی و کار کنند»، باید سیستمی برای مدیریت «فعالیت‌های زندگی» آنها داشته باشید. فناوری‌های 1cFresh و یک لایه منطق تجاری یکپارچه در سطح BSP مسئول این امر هستند. همانطور که در یک ساختمان آپارتمانی زیرساخت هر چیزی را که ساکنان نیاز دارند فراهم می کند، فناوری های 1cFresh نیز هر آنچه را که برای برنامه های کاربردی در مدل چند اجاره ای نیاز دارند را فراهم می کند. و برای اینکه برنامه ها بتوانند با این زیرساخت تعامل داشته باشند (بدون تغییرات قابل توجه)، "کانکتورهای" مربوطه در قالب زیرسیستم های BSP در آنها قرار می گیرند.
از نقطه نظر مکانیسم های پلت فرم، به راحتی می توان متوجه شد که با کسب تجربه و توسعه مورد استفاده از ابر "1C: Enterprise"، در حال گسترش ترکیب مکانیزم هایی هستیم که در این معماری دخیل هستند. بیایید یک مثال بزنیم. در مدل چند اجاره ای، نقش شرکت کنندگان خدمات برنامه به طور قابل توجهی تغییر می کند. نقش (سطح مسئولیت) کسانی که مسئول اجرای برنامه های کاربردی هستند به طور قابل توجهی افزایش می یابد. برای آنها لازم بود که ابزارهای کنترل برنامه قدرتمندتری داشته باشند. زیرا کاربران برنامه (ساکنان) قبل از هر چیز به ارائه دهنده ای که با آن کار می کنند اعتماد دارند. برای انجام این کار، ما یک برنامه جدید را اجرا کردیم . این مکانیسم به مدیران ارائه‌دهنده اجازه می‌دهد تا آزادی توسعه‌دهندگان برنامه‌ها را به سطح امنیتی مورد نیاز محدود کنند - در اصل، عملکرد برنامه را برای هر مستاجر در یک جعبه ماسه‌بازی خاص جدا کنند.
معماری برای مدیریت برنامه هایی که در حالت چند اجاره ای کار می کنند کمتر جالب نیست (آنچه در فناوری های 1cFresh و BSP پیاده سازی شده است). در اینجا، در مقایسه با مدل استقرار مرسوم، الزامات برای اتوماسیون فرآیندهای مدیریت به طور قابل توجهی افزایش یافته است. ده‌ها چنین فرآیندی وجود دارد: ایجاد مناطق داده جدید ("آپارتمان")، به‌روزرسانی برنامه‌ها، به‌روزرسانی اطلاعات نظارتی، پشتیبان‌گیری و غیره. و البته، الزامات برای سطح قابلیت اطمینان و در دسترس بودن در حال افزایش است. به عنوان مثال، برای اطمینان از تعامل قابل اعتماد بین برنامه‌ها و اجزای سیستم کنترل، فناوری سیستم تماس ناهمزمان را با تحویل تضمینی پیاده‌سازی کردیم.
یک نکته بسیار ظریف نحوه اجتماعی کردن داده ها و فرآیندها است. فقط در نگاه اول ساده به نظر می رسد (اگر برای کسی به نظر برسد). بزرگترین چالش تعادل بین تمرکز داده ها و فرآیندها و تمرکززدایی است. از یک طرف، تمرکز به شما امکان می دهد هزینه ها را کاهش دهید (فضای دیسک، منابع پردازنده، تلاش های مدیر ...). از سوی دیگر، آزادی "مستاجرین" را محدود می کند. این دقیقاً یکی از لحظات "انشعاب" برنامه است، زمانی که توسعه دهنده باید به طور همزمان در مورد برنامه به معنای محدود (خدمت به یک "آپارتمان") و به معنای گسترده (خدمت به همه "مستاجرها" به طور همزمان) فکر کند. .
به عنوان نمونه ای از چنین «معضلاتی»، می توان به اطلاعات نظارتی و مرجع اشاره کرد. البته، وسوسه بزرگی وجود دارد که آن را برای همه "مستأجران" خانه مشترک کنید. این به شما امکان می دهد آن را در یک نسخه ذخیره کنید و آن را برای همه به طور همزمان به روز کنید. اما اتفاق می افتد که برخی از ساکنان نیاز به تغییرات خاصی دارند. به اندازه کافی عجیب، در عمل این اتفاق می افتد، حتی برای اطلاعاتی که توسط تنظیم کننده ها (سازمان های دولتی) مشخص شده است. به نظر می رسد این یک سؤال دشوار است: معاشرت یا عدم معاشرت؟ البته وسوسه انگیز است که اطلاعات را برای همه عمومی و برای کسانی که می خواهند خصوصی کنیم. و این در حال حاضر منجر به اجرای بسیار دشوار می شود. اما ما روی این موضوع کار می کنیم ...
مثال دیگر طراحی اجرای فرآیندهای منظم (اجرا شده بر اساس برنامه زمانبندی، آغاز شده توسط سیستم کنترل و غیره) است. از یک طرف، آنها را می توان برای هر منطقه داده به طور جداگانه پیاده سازی کرد. راحت تر و راحت تر است. اما، از سوی دیگر، چنین دانه بندی ظریفی بار زیادی بر روی سیستم ایجاد می کند. برای کاهش بار، باید فرآیندهای اجتماعی را اجرا کنید. اما آنها نیاز به مطالعه دقیق تری دارند.
البته این یک سوال بسیار مهم را ایجاد می کند. توسعه دهندگان اپلیکیشن چگونه می توانند چند اجاره ای بودن را تضمین کنند؟ برای این کار چه باید بکنند؟ البته، ما در تلاش هستیم تا اطمینان حاصل کنیم که بار مسائل فنی و زیرساختی تا حد امکان بر دوش فناوری ارائه شده قرار می گیرد و توسعه دهنده برنامه فقط به وظایف منطقی تجاری فکر می کند. اما مانند سایر مسائل مهم معماری، توسعه دهندگان برنامه باید درک درستی از کار در مدل چند اجاره ای داشته باشند و در هنگام توسعه برنامه ها کمی تلاش لازم است. چرا؟ زیرا نکاتی وجود دارد که فناوری نمی تواند بدون در نظر گرفتن معنایی داده ها به صورت خودکار ارائه دهد. مثلاً همین تعریف از مرزهای اجتماعی شدن اطلاعات. اما ما سعی می کنیم این مشکلات را کوچک نگه داریم. در حال حاضر نمونه هایی از اجرای چنین برنامه هایی وجود دارد.
یک نکته مهم در زمینه اجرای چند اجاره ای در 1C: Enterprise این است که ما در حال ایجاد یک مدل ترکیبی هستیم که در آن یک برنامه می تواند هم در حالت چند اجاره ای و هم در حالت عادی کار کند. این کار بسیار دشوار و موضوع بحث جداگانه ای است.
منبع: www.habr.com