چگونه کارگزار پیام خود را انتخاب کنید

هر کسی که تا به حال یک سیستم توزیع شده ساخته است، باید موضوع ارتباط بین اجزای سیستم را در نظر گرفته باشد. کارگزار پیام معمولاً می تواند برای ارائه ویژگی ها یا ویژگی های ارتباطی خاص، مانند جداسازی موقت یا قابلیت اطمینان استفاده شود. این امر به ویژه در مورد تبادل داده بین برنامه ها، جایی که سیستم توزیع شده از مجموعه ای از سیستم ها تشکیل شده است که پیام ها را با یکدیگر مبادله می کنند، صدق می کند. در مرحله بعدی موضوع پیچیده انتخاب یک کارگزار مطرح می شود. در حالت ایده آل، این انتخاب باید بر اساس ویژگی های ارتباطی مورد انتظار باشد. دیدگاه های مختلف و روش های مختلف درک یک مسئله می تواند به بحث های زیادی در مورد این انتخاب منجر شود. علاوه بر این، با توجه به آنچه که سازمان های انسانی هستند، گاهی اوقات ملاحظات واقعی کمتری مطرح می شوند:

• انتخاب شرکتی یک کارگزار خاص به عنوان یک راه حل جامع (گاهی اوقات به دلایل زیر)؛
• پیش فرضیات در مورد یک مکانیسم خاص یا یک توانایی خاص یک کارگزار.

توجه 1: انتخاب نامناسب به این معنی نیست که "آن کار نخواهد کرد"؛این فقط به این معنی است که شما برخی سوگیری ها را معرفی خواهید کرد و/یا به مکانیسم های جبرانی نیاز دارید که ممکن است از یک سو ناشیانه و دارای اثربخشی نامشخص و از سوی دیگر گران قیمت باشند.

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

یادآوری: انواع کارگزار

بیایید با بررسی سریع اصطلاحات مربوط به انواع کارگزاران شروع کنیم.

• Log-oriented: این اساساً یک گزارش فقط برای نوشتن است. مصرف کنندگان یک پیام را پس از خواندن آن "حذف" نمی کنند، بلکه به سادگی گزارش را بر اساس یک افست مرور می کنند، که با خواندن گزارش، آن را پیش می برند. این افست را می توان در سمت مصرف کننده یا طرف کارگزار مدیریت کرد. در دنیای لاجوردی، این معادل Event Hubs (با یا بدون سطح کافکا) است.
• صف گرا: کارگزار صف هایی را برای هر مصرف کننده ایجاد می کند و از یک سیستم مسیریابی برای هدایت پیام ها به سمت صف مصرف کنندگان استفاده می کند. وقتی مصرف کننده با یک پیام سروکار داشته باشد ، از صف حذف می شود. در لاجورد ، این معادل اتوبوس سرویس است.
• اشتراک-گرا: یک مصرف کننده (مشترک) هم فیلتر را برای انتخاب پیام ها یا رویدادهای مورد علاقه و یک نقطه پایانی که در آن انتظار دارند پیام ها را دریافت کنند ، مشخص می کند. در هنگام اجرای ، کارگزار سپس تعیین می کند که کدام نقطه پایانی (ها) برای هر پیام بر اساس قوانینی که مشخص شده است ، فراخوانی می کند. تفاوت بزرگ بین این و یک کارگزار مبتنی بر صف در این است که در این حالت ، کارگزار به طور فعال پیام را به سمت نقطه پایانی مشترکین سوق می دهد. در لاجورد ، این معادل شبکه رویداد است.

یادآوری: انواع پیام

بیایید یک یادداشت مختصر در دسته های مختلف پیام اضافه کنیم.

• سند: عکس فوری از وضعیت یک شی ، مانند پرونده مشتری یا تصویر سهام.
• فرمان: همانطور که از نام آن پیداست ، این دستور صادر شده است که منعکس کننده انتظار خاص فرستنده با توجه به گیرنده (های) است.
• رویداد: یک واقعیت مشاهده شده ، اتفاقی که افتاده است. به عبارت دیگر: مشاهده تغییر وضعیت.

در نگاه اول ، اگر به این روش بیان شود ، این تمایز بسیار مفید به نظر نمی رسد. این میانبرها دستگاههای mnemonic هستند که ملاحظات مختلفی را در بر می گیرند ، که در زیر شرح داده شده است. سرانجام ، شما می توانید آن را با جزیره Tortuga مقایسه کنید: شما نمی دانید چگونه به آنجا بروید مگر اینکه قبلاً در آنجا بوده اید. این میانبرها فقط در صورتی مؤثر هستند که می دانید چه چیزی در پشت آنها وجود دارد.

ما به تدریج در بخش های بعدی به پایین این خواهیم رسید.

قصد / انتظار

یکی از اولین سؤالات جالب برای پرسیدن این است: آیا سیستم فرستنده هنگام ارسال یک پیام به طور خاص قصد خاصی دارد؟آیا انتظار دارد اتفاقی در انتهای خط رخ دهد؟یا آیا به اتفاقی نیاز دارد تا بتواند به انجام کار خود ادامه دهد؟

اگر اینگونه نباشد ، این سیستم می تواند یک تأمین کننده داده در نظر گرفته شود ، که به بقیه جهان چیزی را که فقط در یک زمان T می دانست ، آگاه می کند. این می تواند باشد:

• به روزرسانی داده ها (عکس های اشیاء تجاری که مسئولیت آن را بر عهده دارند ، یعنی اسناد). در این حالت ، به روزرسانی های اسناد احتمالاً برای مدت زمان محدود معتبر هستند ، اما جدا از این نظر ، انتخاب یک کارگزار بر اساس این معیار به تنهایی دشوار است.
• یا چیزهایی که اتفاق افتاده است (یعنی: وقایع). اگر سیستم فرستنده تنها قصد ضبط این رویدادها را داشته باشد ، پس استفاده از یک کارگزار مبتنی بر ورود به سیستم معمولاً گزینه مناسبی برای این نیاز است اما ، مانند نقطه قبل ، انتخاب یک کارگزار بدون معیارهای بیشتر دشوار است.

اگر نه - به عبارت دیگر ، اگر فرستنده انتظار آینده را داشته باشد - پس نوشتن در یک سیاهه احتمالاً کارآمدترین راه حل نیست. در عوض ، "تولید کننده" یک فرمان صادر می کند و در واقع مانند مشتری که از یک سرویس استفاده می کند رفتار می کند. این دستور ممکن است نیاز داشته باشد:

• برای اطمینان از این که فقط یک بار از آن پیروی می شود و/یا اینکه فقط برای یک دوره زمانی خاص معتبر است-در این حالت ، یک کارگزار مبتنی بر صف کاندیدای خوبی برای ارائه این سطح از عملکرد است.
• یا با استفاده از فیلترها ، فقط به مشترکان خاص (در واقع ارائه دهندگان خدمات) با دقت مسیریابی می شوند. علاوه بر این ، ممکن است نتیجه این دستور با فرمان/پرس و جو اصلی (الگوی معمولی درخواست-پاسخ) ارتباط داشته باشد. در این حالت ، یک کارگزار مبتنی بر صف نیز به ویژه مناسب است.

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

رابطه بین سیستم ها

در پاراگراف قبلی ، من به طور غیرمستقیم مشکل روابط بین سیستم ها را از طریق مفهوم انتظار یا نیت معرفی کردم (دلالت: قصد تولید کننده با توجه به مصرف کننده (ها)).

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

به جز این که ، در واقعیت ، کمی شبیه مرز بین دو کشور است: یک مرز دارای دو طرف است و تشریفات رفتن از یک کشور (متن) به کشور دیگر بستگی به توافق نامه ها (روابط) بین کشورها دارد. بیایید مثال بزنیم: یک سیستم مدیریت انبار جریان تقریباً در زمان واقعی به روزرسانی های سهام را فراهم می کند. در ازای این به روزرسانی های سهام ، هیچ چیز خاصی از هر مصرف کننده انتظار ندارد. این فقط می گوید "چه کسی ممکن است نگران باشد" که یک مورد خاص یک انبار خاص را به مقدار بیان شده (همان سهام ورودی) باقی مانده است. این که آیا سیستم دیگری گوش دادن به این به روزرسانی ها یا خیر ، هیچ فرقی در آن ایجاد نمی کند. مهم نیست که چه چیزی ، حرکت سهام صورت گرفت ، صرف نظر از اینکه کسی علاقه مند است یا خیر.

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

به طور واضح ، این چه تاثیری در رانندگی مرزها دارد؟در واقع ، با تکیه بر یک کارگزار مبتنی بر ورود به سیستم ، که می تواند یک راه حل مناسب از دیدگاه سیستم مدیریت انبار باشد (به فصل بعدی مراجعه کنید) ، بسیار محدود کننده است زیرا پاسخ کارآمد به خواسته های همه مصرف کنندگان امکان پذیر نیست. شما سپس با انتخاب این روبرو هستید که مصرف کنندگان برخی از ویژگی ها را حمل می کنند (به عنوان مثال ، فیلتر کردن جریان برای استفاده از آنها فقط به آنها علاقه مند است) یا ترکیب دو نوع کارگزار برای ارائه خدمات کامل تری به تعداد بیشتری از مصرف کنندگان.

برای ادویه بحث ، می توانید این سؤال را اضافه کنید: چه کسی در همه اینها چه کاری انجام می دهد؟این به معنای افراد است: کدام تیم وظیفه اجرای این یا آن ویژگی را بر عهده دارند. هر پیشرفت یک ساخت و ساز اجتماعی و فنی است ، به این معنی که فراتر از خود "کد" ، برخی از مسئولیت های مسئولیت درگیر هستند. این موضوع به دور از بی اهمیت است و برای اجرای صاف سازمان بسیار مهم است. از جمله موارد دیگر ، این تفاوت بین ادغام تاکتیکی و ادغام استراتژیک است ، اما این یک موضوع برای مقاله دیگری است.

سردرگمی بین نیازهای داخلی و انتظارات خارجی

برای ادامه آن ، یک زمینه از نوع DDD می تواند به یک کارگزار نیاز داشته باشد تا نیازها/مکانیسم های داخلی خود را هدایت کند. در مثال بالا ، سیستم مدیریت انبار ممکن است از چندین سرویس خرد تشکیل شود که هر یک از رویدادها را تولید و مصرف می کنند. این زمینه ممکن است انتشار این رویدادها را در یک کارگزار مبتنی بر ورود به سیستم ضروری کند.

این یک وسوسه قوی برای کشتن دو پرنده با یک سنگ با قرار دادن این کارگزار در برابر مصرف کنندگان خارج از کشور ایجاد می کند. و چرا نه - اما مراقب باشید که نیازهای داخلی را با نیاز مصرف کنندگان خارجی اشتباه نگیرید. اگر این کار را انجام دهید ، ممکن است بار برخی از ویژگی های خاص را بر روی مصرف کننده تغییر دهید وقتی که می توانستند در طرف تولید کننده ارائه شوند و به همین دلیل به اشتراک گذاشته شده اند.

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

توجه: انجام "مسیریابی" بر اساس پارتیشن در یک کارگزار مبتنی بر ورود به سیستم از نظر فنی امکان پذیر است. اما مراقب باشید: این نوعی اتصال است! این راه حل ممکن است در مرزهای یک زمینه قابل قبول باشد ، اما برای یک زمینه شخص ثالث بسیار کمتر قابل قبول است.

مقدار جریان

تاکنون ، ما در مورد وقایع صحبت کرده ایم ، اما بدون پرداختن به تمایز بین وقایع گسسته و جریان رویداد. بیایید تفاوت را با استفاده از نمونه ای از زمینه فیزیک نشان دهیم: موقعیت در مقابل سرعت. هر اندازه گیری موقعیت دارای مقدار خاص خود است که برای برنامه های خاص مفید است (به عنوان مثال ، نظارت بر حضور در یک منطقه) ، اما توالی موقعیت ها می تواند اطلاعاتی را که برای هدف دیگری لازم است ارائه دهد. شما می توانید با برون یابی از دنباله موقعیت ها ، سرعت را بدست آورید: این به طور مؤثر به شما امکان می دهد سرعت را بر اساس اندازه گیری موقعیت نظارت کنید.

به عبارت دیگر ، جریان موقعیت ها معنای خاص خود را دارد که می توانید علاوه بر هر یک از موقعیت های جداگانه از آن استفاده کنید. راه دیگر برای بررسی این مسئله این است که شما در حال افزایش یک سطح از انتزاع از داده های اساسی (مانند مشتق در ریاضیات) هستید. در این نوع وضعیت ، یک کارگزار مبتنی بر ورود به سیستم به شدت توصیه می شود.

توجه: اگرچه این بسیار فراتر از محدوده این بحث است ، اما حتما محدودیت های تحلیل جریان در زمان واقعی را در نظر داشته باشید (در صورت نیاز به زمان واقعی) ، زیرا تنها ابعاد تحلیل مؤثر (ایندکس) زمان و پارتیشن استکلیدهمچنین مراقب عمق تجزیه و تحلیل باشید که باید محدود شود.

مقدار دنباله

نکته مرتبط با توجه به اهمیت دنباله است. برای وضوح بیشتر ، در مورد مدیریت یک مورد غیر عادی در جریان پیام ها فکر کنید: اگر یک پیام یا رویداد (به هر دلیلی) از دست بدهید ، چه کاری باید انجام دهید؟یا وقتی سفارش تغییر می کند؟و از همه مهمتر: تأثیر واقعی بر مصرف کننده چیست؟اهمیت عملکردی چیست؟

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

در موردی مانند این ، انتخاب یک کارگزار صرفاً اشتراک گرا می تواند خطرناک باشد. یک کارگزار ورود به سیستم به وضوح توصیه می شود. از آنجا که مفهوم نظم مهم است ، با این حال ، تقسیم بندی باید با دقت انجام شود.

علاوه بر این ، پرونده غیر عادی چگونه باید پردازش شود؟به عبارت دیگر: در مورد پیامی که نمی توان پردازش کرد ، چه کاری باید انجام دهید؟چهار گزینه ممکن وجود دارد.

• متوقف کردن فرآیند مصرف: این امن ترین و محافظه کارترین حالت با توجه به مقدار دنباله است. به طور کلی برای مقابله با پرونده خطا ابتدا (هر فرآیند) و سپس راه اندازی مجدد پردازش خودکار ، به یک اقدام دستی نیاز دارد. وقتی حجم پیام زیاد باشد یا زمان پردازش محکم باشد ، این گزینه غیر واقعی می شود. با این حال ، این می تواند بهتر از خطر فساد مصرف کننده باشد.
• Deadlettering با هدف ارسال مجدد احتمالی: از نظر فنی امکان پذیر ، اما محدود کننده است. شما نمی توانید به سادگی پیام را در جریان ارسال کنید ، زیرا این امر به فساد دنباله می رسد. مکانیسم مجدد پیام در سمت مصرف کننده باید قوی باشد.
• مرده ساده ("پرش"): این برای پیام های سمی است ، که می تواند هنگام تکامل فرستنده و شروع به انتشار پیام هایی که هنوز (هنوز) با یک مورد استفاده برنامه ریزی شده از مصرف کننده مناسب نیستند ، رخ دهد.
• پخش مجدد از یک نقطه در دنباله: این گزینه با جزئیات بیشتر در زیر شرح داده شده است.

اسطوره "پخش" توسط یک سیستم از یک افست

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

سوالی که باید بپرسید این است: این مورد استفاده شناخته شده در واقع این مورد مورد نیاز است؟

• مراقب باشید که آن را با مکانیسم پشتیبان/ترمیم اشتباه نگیرید: یک سیاهه نباید حاوی عمق بی نهایت وقایع باشد. در دنیای پایگاه داده کاملاً شناخته شده است که ورود به سیستم معامله نباید به طور نامحدود تورم کند. پشتیبان گیری کامل باید به طور مرتب برای خالی کردن سیاههها و نگه داشتن عکس فوری از وضعیت پایگاه داده انجام شود. این بدان معنی است که یک ورود به سیستم جایگزین یک سیستم پشتیبان نمی شود.
• مراقب باشید که این مسئله را با یک مکانیسم بازیابی اطلاعات اشتباه نگیرید: اگر تنها نیاز واقعی اضافه کردن تأخیر بین انتشار و مصرف (به عنوان مثال ، راه اندازی مبهم) است ، راه حل های دیگری نیز وجود دارد ، مانند تنظیم TTL بر روی یک صفدلال. علاوه بر این ، به طور کلی کارآمد نیست که عملکرد اسمی خود را بر روی محدودیت های یک مورد استفاده استثنایی مانند نصب سیستم یا بازیابی اطلاعات قرار دهید.
• برای یک مورد از خطای مجدد ، می توانید مکانیسم "Rewind" / "Replay" را تصور کنید. در این صورت امکان این امر در طراحی و عملیات بسیار مهم است. علاوه بر این:
  • آیا استفاده از Deadlettering + ارسال مجدد در سیستم مبتنی بر صف یا مبتنی بر اشتراک کافی نیست؟به عبارت دیگر: آیا مهم است که کل جریان را از خطا پخش کنید (یعنی این جریان است که دارای یک مقدار است ، با توالی وقایع آن)؟
  • فرآیندهای مصرف باید idempotent باشد. در غیر این صورت درمان می تواند از بیماری بدتر باشد.
  • مراقب تأثیر عملیات باشید: چه محدودیتی برای مصرف کنندگان مربوطه وجود دارد؟به عنوان مثال ، ترمیم قبلی وضعیت مصرف کننده؟قطع سرویس در طول پخش؟و غیره.
  • در مورد اجرای ، از مکانیسم "Rewind" مصرف جریان پیام (یعنی نحوه بازگشت به جبران قبلی) مراقب باشید. این بسته به کارگزار و مصرف کننده می تواند کم و بیش به راحتی انجام شود. با استفاده از مثال یک عملکرد لاجورد: با قطب های رویداد Azure ، به جبران خسارت در یک ذخیره سازی دسترسی دارید. با استفاده از کافکا در سطح مراکز رویداد ، شما دسترسی مستقیم به افست ندارید. شما باید از API های Kafka استفاده کنید. در هر صورت ، این روند باید علاوه بر ابزارها برنامه ریزی شود.

  نتیجه

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

  • اگر همه مصرف کنندگان کنترل شوند (به عنوان مثال ، در یک زمینه ، یا به سادگی به عنوان ورودی آن زمینه ، برای دریافت پیام) ، پس از آن وضعیت مطلوب است-اگر نیازها آن را توجیه می کند-برای اجرای یک کارگزار ورود به سیستم. به طور واضح ، این سناریو در حوزه ای از مسئولیت رخ خواهد داد. به عبارت دیگر ، هنگامی که سیستم های درگیر در مبادله تحت عنوان همان تیم یا در یک مرز ورودی ، یعنی دریافت پیام از سایر زمینه ها (الگوی فن)) قرار می گیرند.
  • از طرف دیگر ، این انتخاب برای افشای مرزهای برون مرزی (یعنی ارسال پیام به مصرف کنندگان از سایر زمینه ها) محدودتر خواهد بود ، یا احتمالاً نیاز به اضافه کردن ابزارهای تعارف (مانند جریان های کافکا یا تجزیه و تحلیل جریان) به ترکیب فناوری دارد.