توصیه گارتنر در مورد نحوه انتخاب یک کارگزار رویداد

در تاریخ 22 ژوئن 2020 گارتنر ® گزارش روشنگری دیگری در مورد بازار معماری رویداد محور (EDA) با نام "انتخاب کارگزاران رویداد: بنیاد معماری منتهی به رویداد شما" ، توسط تحلیلگر گری اولیف منتشر کرد. می توانید این گزارش را با کلیک بر روی پیوند بخوانید اما برای دستیابی به دسترسی باید یک Gartner برای اشتراک متخصصان فنی داشته باشید. برای کسانی که دسترسی ندارند ، برخی از جنبه های اصلی گزارش را در زیر خلاصه خواهم کرد.

کارگزاران رویداد گارتنر

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

برای من ، مهمترین راهنمایی از همه این است:

همه کارگزاران رویداد برابر نیستند. حتی اگر شما در حال حاضر یک کاربر متخصص یک یا چند کارگزار رویداد هستید ، هنوز هم باید این اطلاعات را بخوانید ، جذب و ارجاع دهید. شما نمی توانید فرض کنید که محصولات به ظاهر مشابه مطابق با تجربه شما رفتار می کنند ، و این مهم است که بدانید اختلافات در کجا وجود دارد. "1

گارتنر برای بیان این نکته تا حدودی دقیق تر می گوید:

متخصصان فنی برنامه باید ویژگی های عملکردی و عملیاتی کارگزاران رویداد را ارزیابی کرده و تجارت فنی کلیدی را برای انتخاب ابزار مناسب انجام دهند. "

وی گفت: "بر خلاف REST یا GRPC برای ارتباطات درخواست درخواست ، شیوه ها ، استانداردها و رویکردهای EDA با ادغام اندک فراتر از الگوی اساسی ارتباطات-اشتراک (میخانه) متنوع است.انتخاب شما از کارگزاران رویداد بسیار مهم استاز آنجا که قابلیت های خاص آن معماری ، طراحی و عملکرد برنامه های رویداد محور شما را دیکته می کند. "

کارگزاران رویداد از انتشار ارتباطات مشترک پشتیبانی می کنند ، اما محصولات دارای معماری ها و قابلیت های بسیار متنوع هستند. این اختلافات انتخاب را به چالش می کشد. سوء استفاده از الزامات و قابلیت ها برای حل و فصل دردناک و پرهزینه است. "

از این نقل قول های گزارش ، من فکر می کنم این نکته بیان شده است که گارتنر معتقد است درک تفاوت بین کارگزاران رویدادهای مختلف بسیار مهم است. حال بیایید ببینیم که گارتنر در مورد انواع خاصی از کارگزاران چه می گوید.

سه نوع کارگزاران رویداد ، که توسط گارتنر توضیح داده شده است

سه نوع کارگزار رویداد وجود دارد:

توصیه های کارگزار بالاترین سطح گارتنر به این شکل است:

• برای پاسخگویی به نیازهای خود از ساده ترین پیکربندی کارگزار رویداد استفاده کنید - یک سرویس ابر کارگزار رویداد اغلب از پیچیدگی پیکربندی (اما نه همه) جلوگیری می کند. استفاده ، تنظیم و بهره برداری از کارگزاران بسیار در دسترس ، با کارایی بالا ، خوشه ای یک مهندسی و پشتیبانی غیر اصلی است.
• هنگامی که به اتصال مشتری Multiprotocol و تعریف ساختار موضوع انعطاف پذیر نیاز دارید ، یک کارگزار صف گرا را انتخاب کنید و نیازی به حفظ و پخش مجدد پیام ندارید.
• هنگامی که نیاز به حفظ پیام طولانی مدت و پخش مجدد و/یا توان بسیار زیاد دارید ، یک کارگزار ورود به سیستم را انتخاب کنید و می تواند یک ساختار موضوع مسطح را تحمل کند.
• چندین کارگزار رویداد را مستقر کنید که در آن نیازهای شما قابلیت دو یا چند کلاس از انواع کارگزاری را داشته باشد. فرض نکنید که "یک اندازه متناسب با همه" است. وت
• با کنترل ارتباط بین انواع رویداد و مباحث با استفاده از یک رجیستری طرحواره ای خاص یا مستقل ، مدیریت Schema را برای اداره EDA خود اجرا کنید.

توضیحات گارتنر از کارگزاران صف گرا

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

منبع: گارتنر "انتخاب کارگزاران رویداد: پایه و اساس معماری رویداد محور شما ، 22 ژوئن 2020 ، گری اولیف

گارتنر خاطرنشان می کند ، "کارگزاران صف گرا در صورت نیاز به ترکیبی از:

• پشتیبانی چندتروتوکول از معماری های ناهمگن
• ساختار موضوع سلسله مراتبی و الگوهای اشتراک انعطاف پذیر
• پشتیبانی از پردازش صف FIFO علاوه بر Pub-Sub
• یا محدودیت های کارگزاران اشتراک و ورود به سیستم متناسب با نیازهای شما نیست. "

توضیحات گارتنر از کارگزاران ورود به سیستم

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

منبع: گارتنر "انتخاب کارگزاران رویداد: پایه و اساس معماری رویداد محور شما ، 22 ژوئن 2020 ، گری اولیف

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

منبع: گارتنر "انتخاب کارگزاران رویداد: پایه و اساس معماری رویداد محور شما ، 22 ژوئن 2020 ، گری اولیف

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

توضیحات گارتنر در مورد کارگزاران اشتراک گرا

کارگزاران مبتنی بر اشتراک از نیاز به پشتیبانی از پلتفرم عملکرد ابر بومی به عنوان یک سرویس و معماری های بدون سرور متولد شدند. تصویر زیر از گارتنر معماری منطقی آنها را نشان می دهد:

منبع: گارتنر "انتخاب کارگزاران رویداد: پایه و اساس معماری رویداد محور شما ، 22 ژوئن 2020 ، گری اولیف

گارتنر خاطرنشان می کند:

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

اکنون اصول اولیه را می دانید ... اما "شیطان در جزئیات است"

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

همانطور که گارتنر به طور مناسب خاطرنشان می کند:

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

منبع: گارتنر "انتخاب کارگزاران رویداد: پایه و اساس معماری رویداد محور شما ، 22 ژوئن 2020 ، گری اولیف

Gartner یادداشت های کارگزار رویداد و قابلیت های موجود در دسته های زیر متناسب است:

• قابلیت های اتصال مشتری - این ویژگی ها مربوط به نحوه تولید رویداد شما و مصرف کنندگان به کارگزار و نحوه پردازش پیام های رویداد است. این شامل پشتیبانی از پروتکل ها ، پشتیبانی از تراکنش ها و ویژگی های توسعه دهندگان نرم افزار و یکپارچه سازی است.
• قابلیت های تحویل پیام - این ویژگی ها مربوط به نحوه تعریف پیام ها توسط کارگزار رویداد است. این شامل ساختار پیام ، ابرداده و معانی تداوم پیام ، سازمان موضوعی ، پارتیشن بندی موضوع ، مسیریابی ، کیفیت خدمات و تعریف اشتراک است.
• گزینه های استقرار کارگزار-این ویژگی ها مربوط به نحوه استقرار و پیکربندی کارگزار برای برآورده کردن انواع الزامات غیر کاربردی از جمله توان ، تأخیر ، مقاومت و بازپرداخت است.
• قابلیت های مدیریت و عملیات-این ویژگی ها مربوط به مدیریت روزانه محیط کارگزار رویداد و برنامه های رویداد محور شما در اطراف آن است. این شامل رابط های مدیریتی از جمله API ، رابط خط فرمان (CLI) و UIS و همچنین نظارت و تأمین امنیت محیط است. "

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

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

یک فکر نهایی - مدیریت طرحواره رویداد

بدون تکرار کل یادداشت تحقیقاتی 42 صفحه ای، من به سادگی یک بخش مهم نهایی در این تحقیق را برجسته می کنم: مدیریت طرحواره رویداد. گارتنر به درستی خاطرنشان می کند:

ساختار یا طرح بار پیام باید به همان روشی که مشخصات API مورد توافق قرار گرفته و ابلاغ شود. در واقع، اعمال اصول طراحی و تحویل API در EDA مفید است.”

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

• Schema Registry - این یک فروشگاه مرکزی یا مشترک از طرحواره های رویداد یا پیام است که در سیستم استفاده می شود.
• پشتیبانی از فرمت طرحواره - فرمت های بارگذاری مختلف (مانند JSON، XML، Apache Avro و بافرهای پروتکل) دارای قالب های تعریف طرحواره متفاوتی هستند. رجیستری طرح شما باید فرمت هایی را که برنامه های شما منتشر و مصرف می کنند پشتیبانی کند.
• نسخه سازی طرحواره - با اصلاح و بهبود تولیدکنندگان، بارهای رویداد می توانند تغییر کنند. شما باید این تغییرات نسخه را مدیریت کنید.
• اعتبار سنجی طرحواره - اعتبار سنجی طرحواره پیام های فردی می تواند بر روی کارگزار یا در مشتری انجام شود.

در واقع، گارتنر همچنین از "قابلیت های در حال ظهور" صحبت می کند که برخی از فروشندگان به تازگی شروع به ارائه به بازار کرده اند:

• کشف رویداد توسعه دهندگان به کشف API های REST با استفاده از پورتال های توسعه دهنده سلف سرویس عادت کرده اند. زمانی که سازمانی می خواهد دسترسی به سیستم یا رویدادهای تجاری خود را دموکراتیک و توزیع کند، توسعه دهندگان نیز انتظار دارند همین تجربه را داشته باشند.
• تجسم رقص زمانی که فرآیندها توسط رقص (به معنی «زنجیره ای از رویدادها») به جای یک فرآیند ارکستراسیون مرکزی هدایت شوند، تجسم جریان یا وضعیت فرآیند می تواند دشوار باشد. همچنین می تواند بر اساس اینکه مصرف کنندگان در یک مقطع زمانی متصل و فعال هستند، تغییر کند. استفاده مداوم از ابزارهای ردیابی توزیع شده برای تزریق و انتشار شناسه های قابل ردیابی و جمع آوری داده ها می تواند این تجسم را فراهم کند.
• اجرای تابع - کارگزارهای رویداد اغلب برای راه اندازی توابع بدون حالت استفاده می شوند و در یک محیط ابری معمولاً با عملکرد بدون سرور PaaS استفاده می شوند. یک توسعه طبیعی این است که یک تابع زمان اجرا با کارگزار رویداد یکپارچه شود.

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

• از ساده ترین پیکربندی کارگزار رویداد برای رفع نیازهای خود استفاده کنید
• از ویژگی های کلیدی برای انتخاب اساسی نوع کارگزار استفاده کنید
• در صورت لزوم چندین کارگزار رویداد را مستقر کنید
• پیاده سازی مدیریت طرحواره.

اگر مشتری گارتنر هستید ، با دسترسی به تحقیقات متخصصان فنی آنها ، من شما را تشویق می کنم که این گزارش را به طور کامل در https://www. gartner. com/document/3986571 بخوانید.

در این گزارش به عنوان یکی از "کارگزاران صف گرا" یاد شد.

نکته جالب در مورد Solace PubSub+ این است که در حالی که اساساً یک کارگزار صف گرا است ، اما دارای قابلیت پخش مجدد پیام اختیاری نیز هست ، بنابراین پیام ها را در کارگزار حفظ می کند و فقط پس از رسیدن به حد اندازه از پیش تعیین شده ، حذف می شود. می توانید نمای کلی را در اینجا یا نسخه ی نمایشی در YouTube بررسی کنید.

دو قابلیت اول نوظهور (کشف رویداد و تجسم رقص) قابلیت هایی هستند که Solace با پورتال PubSub+ رویداد به بازار عرضه می شود.

_{منبع: 1 گارتنر "انتخاب کارگزاران رویداد: پایه و اساس معماری رویداد محور شما ، 22 ژوئن 2020 ، گری اولیف}

_{سلب مسئولیت گارتنر گارتنر علامت تجاری و علامت خدمات ثبت شده شرکت گارتنر و/یا شرکت های وابسته آن در ایالات متحده و بین المللی است و در اینجا با اجازه استفاده شده است. کلیه حقوق محفوظ است. گارتنر هیچ فروشنده ، محصول یا خدمات نشان داده شده در انتشارات تحقیقاتی خود را تأیید نمی کند و به کاربران فناوری توصیه نمی کند که فقط آن دسته از فروشندگان را با بالاترین رتبه یا سایر تعیین ها انتخاب کنند. انتشارات تحقیقاتی گارتنر شامل نظرات سازمان تحقیقاتی گارتنر است و نباید به عنوان بیانیه واقعیت تفسیر شود. گارتنر با توجه به این تحقیق ، کلیه ضمانت نامه ها ، بیان شده یا ضمنی را رد می کند ، از جمله هرگونه ضمانت از تجارت یا تناسب اندام برای یک هدف خاص.}

راجر سابورین

به عنوان رهبر برنامه روابط تحلیلگر SOLACE ، راجر از پیشینه فنی و تجربه روابط تحلیلگر خود استفاده کرده است تا درک فنی کاملی از معماری رویداد محور ، جریان رویداد و مدیریت رویداد را ایجاد کند که وی برای کمک به تحلیلگران در درک بسیاری از روشهای EDA و رویدادها می تواند به تحلیلگران کمک کند. آخرین روند محاسبات و فناوری را فعال ، مکمل و تسریع کنید.

پس از شروع کار خود به عنوان مشاور برنامه نویس و خدمات حرفه ای ، راجر تمرکز خود را به روابط تحلیلگر با نوآوران اطلاعات کسب و کار Cognos و IBM Analytics و بخش مشاوره خدمات تجاری IBM هنگامی که IBM آنها را به دست آورد ، تغییر داد و به مدت 20 سال اکنون در کنار گارتنر کار می کند، Forrester ، IDC و سایر تحلیلگران برای کمک به آنها در درک موقعیت کارفرمایان وی در چشم انداز IT شرکت.

به مدت 30 سال ازدواج کرد ، راجر پدر افتخار 3 فرزند بزرگسال است و از پروژه های DIY در اطراف خانه لذت می برد و اوقات آرام را در دریاچه می گذراند.