معماری رویدادمحور و همگام‌سازی دوطرفه داده‌ها در یکپارچه‌سازی سیستم‌ها

مقدمه و مفاهیم پایه

کارکرد هماهنگ نرم‌افزارهای برنامه‌ریزی منابع سازمانی، مالی و موجودی مورد استفاده در کسب‌وکارهای مدرن برای استمرار عملیاتی از اهمیت حیاتی برخوردار است. این نرم‌افزارها که توسط بخش‌های مختلف استفاده می‌شوند، باید بدون هیچ‌گونه تأخیری یکدیگر را تغذیه کنند. ساختارهایی که تحت عنوان یکپارچه‌سازی سیستم‌ها بررسی می‌شوند، جریان داده قابل اعتمادی را بین ERP، حسابداری، پرداخت، پیامک، ایمیل و سیستم‌های شخص ثالث فراهم می‌کنند.

راه‌اندازی معماری رویدادمحور (EDA)

یکپارچه‌سازی‌های نقطه‌به‌نقطه کلاسیک با بزرگ‌تر شدن سیستم‌ها غیرقابل مدیریت می‌شوند. در این نقطه است که معماری رویدادمحور وارد عمل می‌شود. یک تغییر حیاتی که در یک سیستم رخ می‌دهد (مثلاً ایجاد یک سفارش جدید یا تغییر مقدار موجودی) به عنوان یک رویداد در صف نوشته می‌شود.

• به لطف جریان ناهمگام، سیستم تولیدکننده مجبور نیست منتظر پاسخ سیستم مصرف‌کننده بماند.
• صف‌های پیام حتی در زیر بار سنگین از از دست رفتن داده‌ها جلوگیری کرده و از عملکرد مستقل سیستم‌ها پشتیبانی می‌کنند.

همگام‌سازی دوطرفه داده‌ها و حل تداخل

هنگام انجام همگام‌سازی دوطرفه داده‌ها بین پلتفرم‌های مختلف، ممکن است تغییرات هم‌زمانی روی همان داده‌ها ایجاد شود. این وضعیت می‌تواند منجر به ناسگاری داده‌ها شود. برای یک یکپارچه‌سازی سیستم قوی، باید مراحل زیر دنبال شود:

1. مرتب‌سازی زمانی رویدادها.
2. کنترل برچسب زمانی (timestamp) یا شماره نسخه.
3. تعیین استراتژی‌های خودکار حل تداخل (مانند آخرین نویسنده برنده است یا صف تایید دستی).

معیارهای تصمیم‌گیری عملی

هنگام طراحی پروژه یکپارچه‌سازی، حجم سیستم، نیاز به انتقال داده‌های لحظه‌ای و تحمل خطا باید در نظر گرفته شوند. جریان‌های ناهمگام ممکن است برای هر سناریویی مناسب نباشند؛ در نقاطی که نیاز به ثبات لحظه‌ای مانند تطبیق مالی وجود دارد، ممکن است لایه‌های میانی همگام مورد نیاز باشد.

سناریوی فرضی و روند اجرای نمونه

برای ملموس‌تر کردن این ساختار تئوریک، یک خرده‌فروشی متوسط فعال در سطح بین‌المللی را در نظر بگیریم که تجارت الکترونیک و فروشگاه‌های فیزیکی را با هم اداره می‌کند. این کسب‌وکار از یک نرم‌افزار ابری اختصاصی برای مدیریت سفارش و از یک سیستم سنتی ERP برای عملیات پیش‌حسابداری و مالی استفاده می‌کند. هنگامی که مشتری سفارشی را از طریق وب‌سایت ثبت می‌کند، سیستم مدیریت سفارش ابری رویداد "siparis_olusturuldu" را تولید کرده و آن را به صف پیام ارسال می‌کند. سیستم ERP با مصرف این پیام، مقدار موجودی مربوطه را کاهش داده و فاکتور را آماده می‌کند. بزرگ‌ترین دستاورد معماری در این سناریو این است که حتی اگر کندی یا قطعی لحظه‌ای در سیستم پرداخت یا حسابداری رخ دهد، وب‌سایت تجارت الکترونیک می‌تواند به دریافت سفارش‌ها بدون وقفه ادامه دهد. داده‌هایی که با خیال راحت در صف پیام نگه داشته می‌شوند، به محض بالا آمدن سیستم‌ها به ترتیب پردازش می‌شوند. با این حال، یک دادوستد (trade-off) حیاتی وجود دارد که باید در این جریان به آن توجه شود: ساختار ناهمگام در حالی که زمان پاسخ سیستم و مقیاس‌پذیری را به‌طور چشمگیری افزایش می‌دهد، مستلزم چشم‌پوشی از ثبات لحظه‌ای داده‌ها است. تاخیر چند ثانیه‌ای تا زمانی که سیستم مصرف‌کننده پیام را پردازش کند، می‌تواند خطر ناسگاری داده‌ها را در فرآیندهای تجاری که نمی‌توانند تحمل شوند، ایجاد کند. در چنین مواردی، علاوه بر معماری رویدادمحور، باید تراکنش‌های جبرانی (compensating transactions) در مراحل حساس مالی طراحی شوند و مکانیسم‌های بازگشت خودکار در صورت بروز خرابی فعال گردند.

چک‌لیست تفصیلی اجرا و موفقیت

پیش از عملیاتی کردن یک پروژه یکپارچه‌سازی پایدار و مستحکم، مراحلی وجود دارد که تیم‌های فنی باید با دقت کامل آن‌ها را به سرانجام برسانند. نخست، باید اطمینان حاصل شود که ساختار صف نامه مرده یا همان "Dead Letter Queue" در معماری صف پیام راه‌اندازی شده است. پیام‌هایی که قابل پردازش نیستند یا خطا تولید می‌کنند، به جای ورود به یک چرخه بی‌نهایت، باید به این صف هدایت شده و زنگ هشداری را برای تیم‌های عملیاتی به صدا درآورند. دوم، همگام‌سازی ساعت بین سیستم‌ها باید به طور مطلق با استفاده از پروتکل زمان شبکه (Network Time Protocol) انجام شود. وقتی استراتژی‌های حل تداخل مبتنی بر برچسب زمانی اعمال می‌شوند، حتی انحرافات ساعتی در حد میلی‌ثانیه میان سرورها می‌توانند باعث عملکرد نادرست قانون «آخرین نویسنده برنده است» و بازنویسی داده‌های به‌روز شوند. سوم، نسخه‌بندی طرح‌واره (schema) برای تمامی داده‌های بار مفید (payload) انجام شده و لایه‌های آداپتور برای مدیریت ناسازگاری‌های بین نسخه‌های قدیمی و جدید نوشته شوند. در گام چهارم نیز برای قابلیت ردیابی سرتاسری، سیستم‌های لاگ‌گیری توزیع‌شده یکپارچه شده و یک شناسه همبستگی منحصر به فرد به هر رویداد اختصاص یابد. هنگامی که این چک‌لیست به طور کامل اجرا شود، یکپارچه‌سازی‌های سیستم در برابر قطعی‌های احتمالی شبکه، افزایش بار و تداخل داده‌ها مقاوم شده و عملیات کسب‌وکار بدون هیچ‌گونه اختلالی با اطمینان به کار خود ادامه می‌دهد.

منابع

• سیسستم اینتگراسیونلری — سای لاجیک سافتور