۲۹ شهریور ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

چگونه با میکروسرویس های رویداد محور شروع کنیم

ریزسرویس‌های رویداد محور یک راه عالی برای ارائه داده‌های تاریخی و جدید به همه سیستم‌ها و تیم‌هایی هستند که به آن‌ها نیاز دارند، اما آنها با نیازهای سربار و مدیریت اضافی همراه هستند. از کوچک شروع کنید.

ریزسرویس‌های رویداد محور یک راه عالی برای ارائه داده‌های تاریخی و جدید به همه سیستم‌ها و تیم‌هایی هستند که به آن‌ها نیاز دارند، اما آنها با نیازهای سربار و مدیریت اضافی همراه هستند. از کوچک شروع کنید.

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

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

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

من

آیا میکروسرویس های رویداد محور برای شما مناسب هستند؟

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

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

از لحاظ تاریخی، معمولاً این الگو را هنگام استخراج داده‌ها از سیستم‌های پردازش تراکنش آنلاین (OLTP) برای انجام پردازش تحلیلی آنلاین (OLAP) پیدا می‌کنید. اما با رشد گسترده داده‌ها، الزامات عملکرد و نیازهای تجاری، همین الگوهای استخراج و بارگذاری در حال حاضر برای هر سیستم عملیاتی که به سادگی به داده‌های تجاری رایج برای انجام عملکرد خود نیاز دارد، رایج است. ریزسرویس‌های رویداد محور راهی برای دسترسی به داده‌های تاریخی و جدید در قالب یک گزارش غیرقابل تغییر از رویدادها ارائه می‌دهند.

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

از خدمات ابری مدرن بهره ببرید

هر سرویس جدیدی که ایجاد می‌کنید (خرد یا غیره) به یک خط لوله استقرار، مدیریت کانتینر، نظارت و خدمات مقیاس‌بندی نیاز دارد. ده‌ها ریز سرویس نسبت به یک سرویس یکپارچه به سربار و مدیریت بیشتری نیاز دارند. این سربار به عنوان “مالیات خدمات خرد” شناخته می شود. ساده‌سازی و خودکارسازی عملیات شما به کاهش هزینه کمک می‌کند، اما از نظر تاریخی برای دستیابی به آن نیاز به سرمایه‌گذاری قابل توجهی داشته است.

امروزه، می‌توانیم بیشتر به خدمات ابری مدیریت‌شده برای کاهش مالیات میکروسرویس‌ها تکیه کنیم. استقرار، مدیریت، نظارت، و مقیاس‌بندی Dockerized در Kubernetes در این عصر بسیار رایج و آسان است. به طور مشابه، ایجاد و مدیریت موضوعات کافکا از طریق سرویس‌های ابری، مانند Clonofo a>، راحت تر از همیشه است.

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

کوچک شروع کنید و بر روی سیستم های موجود بسازید

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

Kafka Connect یک گزینه عالی برای راه‌اندازی جداول پایگاه داده رویدادهای خود است. می‌توانید به مجموعه‌ای از پایگاه‌های داده‌های اولیه و ابری، داده‌های تاریخی عکس فوری، داده‌های فیلتر، ستون‌های ماسک و موارد دیگر متصل شوید. پایگاه داده منبع شما مستقل از کافکا کانکت باقی می ماند و به شما این امکان را می دهد که به صورت تدریجی داده های مهم تجاری را بدون تأثیر بر سیستم های موجود منبع یابی کنید.

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

خدمات میکرو متناسب با نیازهای کسب و کار بسازید

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

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

تعداد میکروسرویس خود را کم نگه دارید

یک میکروسرویس لازم نیست کوچک باشد. در واقع، ممکن است مفید باشد که یک میکروسرویس را صرفاً یک سرویس اختصاصی برای زیرمجموعه ای از مشکلات تجاری در نظر بگیرید. یکی از مشکلات اصلی که بسیاری از مردم در آن گرفتار می‌شوند، ساخت میکروسرویس‌ها برای هر بخش از عملکرد است که اغلب به صدها یا هزاران سرویس ختم می‌شود! هدف معماری میکروسرویس‌های رویداد محور، ساخت تا حد امکان سرویس‌ها نیست، بلکه فعال کردن راه‌حل‌های اختصاصی با استفاده از ابزارهای مناسب برای کار است.

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

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

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

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

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

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

ایجاد جعبه ابزاری از ابزارها، زبان‌ها و چارچوب‌های تایید شده

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

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

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

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

از مزیت یکپارچه سازی کامل و تست واحد بهره ببرید

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

معمولاً می‌توانید با بارگیری ورودی‌ها با رویدادهای خاص، میکروسرویس خود را «جعبه سیاه» آزمایش کنید و ببینید چه نتایجی تولید می‌شود. برای رویدادهای خاص کافکا، کافکا دارای یک بروکر تست داخلی، مبتنی بر جاوا و حافظه است. با راه‌اندازی کارگزار، می‌توانید رویدادها را به صورت برنامه‌نویسی تولید کنید و نتایج تولید شده را ارزیابی کنید.

برای آزمایش‌های یکپارچه‌سازی میکروسرویس مبتنی بر کانتینر، می‌توانید نمونه موازی کافکای خود را بچرخانید یا به سادگی به یک خوشه ابری متصل شوید. رویدادهای خود را تولید و مصرف کنید، سپس در پایان همه چیز را پاک کنید.

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

جریان‌های رویداد نیازهای متنوعی را برآورده می‌کنند

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

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

آدام بلمار تکنسین کارکنان در دفتر CTO در Confluent است.

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.