هی هابر!
یادآوری می کنیم که دنبال کتاب در مورد ما یک اثر به همان اندازه جالب در مورد کتابخانه منتشر کرده ایم .
در حال حاضر، جامعه فقط در حال یادگیری محدودیت های این ابزار قدرتمند است. از این رو اخیرا مطلبی منتشر شد که ترجمه آن را به شما معرفی می کنیم. نویسنده از تجربه خودش می گوید که چگونه می توان کافکا استریم را به یک ذخیره سازی داده توزیع شده تبدیل کرد. از خواندن لذت ببرید!
کتابخانه آپاچی در سراسر جهان در شرکت ها برای پردازش جریان توزیع شده در بالای آپاچی کافکا استفاده می شود. یکی از جنبه های مورد توجه این چارچوب این است که به شما امکان می دهد وضعیت محلی تولید شده بر اساس پردازش نخ را ذخیره کنید.
در این مقاله، من به شما خواهم گفت که چگونه شرکت ما موفق شد در هنگام توسعه محصولی برای امنیت برنامه های ابری، از این فرصت سودآور استفاده کند. با استفاده از Kafka Streams، ما میکروسرویس‌های حالت مشترک ایجاد کردیم، که هر یک به عنوان منبعی مقاوم در برابر خطا و بسیار در دسترس از اطلاعات قابل اعتماد در مورد وضعیت اشیاء در سیستم عمل می‌کنند. برای ما، این یک گام به جلو هم از نظر قابلیت اطمینان و هم از نظر سهولت پشتیبانی است.
اگر به یک رویکرد جایگزین علاقه مند هستید که به شما امکان می دهد از یک پایگاه داده مرکزی واحد برای پشتیبانی از وضعیت رسمی اشیاء خود استفاده کنید، آن را بخوانید، جالب خواهد بود...
چرا فکر می کردیم زمان آن رسیده است که روش کار با حالت مشترک را تغییر دهیم
ما نیاز به حفظ وضعیت اشیاء مختلف بر اساس گزارش های عامل داشتیم (به عنوان مثال: آیا سایت مورد حمله قرار گرفته است)؟ قبل از مهاجرت به Kafka Streams، ما اغلب به یک پایگاه داده مرکزی واحد (+ API سرویس) برای مدیریت دولتی متکی بودیم. این رویکرد دارای معایبی است: حفظ ثبات و هماهنگی به یک چالش واقعی تبدیل می شود. پایگاه داده ممکن است به یک گلوگاه تبدیل شود یا در نهایت به آن ختم شود و از غیرقابل پیش بینی بودن رنج می برند.
شکل 1: یک سناریوی حالت تقسیم معمولی قبل از انتقال به
Kafka و Kafka Streams: عوامل دیدگاه های خود را از طریق API ارتباط می دهند، وضعیت به روز شده از طریق پایگاه داده مرکزی محاسبه می شود.
با Kafka Streams آشنا شوید و ایجاد ریز سرویس‌های دولتی مشترک را آسان می‌کند
حدود یک سال پیش، تصمیم گرفتیم برای رسیدگی به این مسائل، به سناریوهای دولتی مشترک خود نگاهی دقیق بیندازیم. ما بلافاصله تصمیم گرفتیم Kafka Streams را امتحان کنیم - ما می دانیم که چقدر مقیاس پذیر، بسیار در دسترس و تحمل خطا است، چه عملکرد پخش جریانی غنی دارد (تبدیل ها، از جمله حالت های حالت). همان چیزی که ما به آن نیاز داشتیم، ناگفته نماند که سیستم پیام رسانی در کافکا چقدر بالغ و قابل اعتماد شده است.
هر یک از میکروسرویس‌های دولتی که ما ایجاد کردیم بر روی نمونه‌ای از Kafka Streams با توپولوژی نسبتاً ساده ساخته شده‌اند. این شامل 1) یک منبع 2) یک پردازنده با یک ذخیره کلیدی دائمی 3) یک سینک:
شکل 2: توپولوژی پیش فرض نمونه های جریان ما برای میکروسرویس های حالت دار. توجه داشته باشید که در اینجا یک مخزن نیز وجود دارد که حاوی ابرداده های برنامه ریزی است.
در این رویکرد جدید، عوامل پیام‌هایی را می‌نویسند که به مبحث منبع تغذیه می‌شوند و مصرف‌کنندگان - مثلاً یک سرویس اعلان پستی - حالت مشترک محاسبه‌شده را از طریق سینک (موضوع خروجی) دریافت می‌کنند.
شکل 3: نمونه جریان کار جدید برای یک سناریو با ریزسرویس های مشترک: 1) عامل پیامی تولید می کند که به مبحث منبع کافکا می رسد. 2) یک میکروسرویس با حالت اشتراکی (با استفاده از Kafka Streams) آن را پردازش می کند و حالت محاسبه شده را در موضوع نهایی کافکا می نویسد. پس از آن 3) مصرف کنندگان حالت جدید را می پذیرند
سلام، این فروشگاه با ارزش کلیدی داخلی در واقع بسیار مفید است!
همانطور که در بالا ذکر شد، توپولوژی حالت مشترک ما حاوی یک ذخیره کلید-مقدار است. ما چندین گزینه برای استفاده از آن پیدا کردیم که دو مورد از آنها در زیر توضیح داده شده است.
گزینه شماره 1: برای محاسبات از یک ذخیره کلید-مقدار استفاده کنید
اولین ذخیره ارزش کلید ما حاوی داده های کمکی بود که برای محاسبات نیاز داشتیم. به عنوان مثال، در برخی موارد، حالت مشترک با اصل "آی اکثریت" تعیین می شد. مخزن می تواند تمام آخرین گزارش های عامل در مورد وضعیت برخی از شی را نگه دارد. سپس، هنگامی که یک گزارش جدید از یک یا آن عامل دریافت کردیم، می‌توانیم آن را ذخیره کنیم، گزارش‌هایی را از همه عوامل دیگر در مورد وضعیت همان شی از ذخیره‌سازی بازیابی کنیم و محاسبه را تکرار کنیم.
شکل 4 زیر نشان می دهد که چگونه ما ذخیره کلید/مقدار را در معرض روش پردازش پردازنده قرار دادیم تا پیام جدید پردازش شود.
تصویر 4: ما برای روش پردازش پردازنده دسترسی به ذخیره کلید-مقدار را باز می کنیم (پس از این، هر اسکریپتی که با حالت اشتراکی کار می کند باید روش را پیاده سازی کند. doProcess)
گزینه شماره 2: ایجاد یک CRUD API در بالای Kafka Streams
پس از ایجاد جریان کار اصلی خود، شروع به نوشتن یک API CRUD RESTful برای میکروسرویس های دولتی مشترک خود کردیم. ما می خواستیم بتوانیم وضعیت برخی یا همه اشیاء را بازیابی کنیم، همچنین وضعیت یک شی را تنظیم یا حذف کنیم (مفید برای پشتیبانی از Backend).
برای پشتیبانی از تمام APIهای Get State، هر زمان که نیاز به محاسبه مجدد وضعیت در حین پردازش داشتیم، آن را برای مدت طولانی در یک ذخیره‌سازی با مقدار کلید داخلی ذخیره می‌کردیم. در این مورد، پیاده سازی چنین API با استفاده از یک نمونه از Kafka Streams، همانطور که در لیست زیر نشان داده شده است، بسیار ساده می شود:
شکل 5: استفاده از ذخیره سازی مقدار کلید داخلی برای به دست آوردن حالت از پیش محاسبه شده یک شی
به روز رسانی وضعیت یک شی از طریق API نیز به راحتی قابل پیاده سازی است. اساسا، تنها کاری که باید انجام دهید این است که یک تهیه کننده کافکا بسازید و از آن برای ساختن یک رکورد حاوی حالت جدید استفاده کنید. این تضمین می کند که تمام پیام های تولید شده از طریق API به همان روشی که از سایر تولیدکنندگان (مثلاً نمایندگان) دریافت می شود، پردازش می شود.
شکل 6: می توانید وضعیت یک شی را با استفاده از تولید کننده کافکا تنظیم کنید
عارضه کوچک: کافکا پارتیشن های زیادی دارد
در مرحله بعد، ما می‌خواستیم بار پردازشی را توزیع کنیم و در دسترس بودن را با ارائه مجموعه‌ای از ریزسرویس‌های حالت مشترک در هر سناریو بهبود دهیم. راه‌اندازی سریع بود: وقتی همه نمونه‌ها را پیکربندی کردیم تا تحت یک شناسه برنامه (و همان سرورهای بوت استرپ) اجرا شوند، تقریباً همه چیز به طور خودکار انجام می‌شد. ما همچنین مشخص کردیم که هر مبحث منبع از چندین پارتیشن تشکیل شده باشد، به طوری که به هر نمونه می توان زیر مجموعه ای از این پارتیشن ها را اختصاص داد.
همچنین اشاره می‌کنم که تهیه یک نسخه پشتیبان از فروشگاه دولتی معمول است تا به عنوان مثال، در صورت بازیابی پس از خرابی، این نسخه را به نمونه دیگری منتقل کنید. برای هر فروشگاه ایالتی در Kafka Streams، یک موضوع تکراری با یک گزارش تغییرات (که به‌روزرسانی‌های محلی را دنبال می‌کند) ایجاد می‌شود. بنابراین، کافکا دائماً از فروشگاه دولتی پشتیبانی می کند. بنابراین، در صورت خرابی یکی از نمونه‌های Kafka Streams، می‌توان به‌سرعت ذخیره‌سازی حالت را در نمونه دیگری بازیابی کرد، جایی که پارتیشن‌های مربوطه در آنجا خواهند رفت. آزمایشات ما نشان داده است که این کار در چند ثانیه انجام می شود، حتی اگر میلیون ها رکورد در فروشگاه وجود داشته باشد.
با حرکت از یک میکروسرویس منفرد با حالت مشترک به خوشه ای از ریزسرویس ها، پیاده سازی Get State API کمتر پیش پا افتاده می شود. در وضعیت جدید، ذخیره وضعیت هر میکروسرویس تنها بخشی از تصویر کلی را در بر می گیرد (اشیایی که کلیدهای آنها به یک پارتیشن خاص نگاشت شده است). ما باید تعیین می‌کردیم که کدام نمونه حاوی وضعیت شی مورد نیاز ما است، و این کار را بر اساس ابرداده رشته انجام دادیم، همانطور که در زیر نشان داده شده است:
شکل 7: با استفاده از فراداده جریان، تعیین می کنیم که از کدام نمونه وضعیت شی مورد نظر را پرس و جو کنیم. رویکرد مشابهی با GET ALL API استفاده شد
یافته های کلیدی
فروشگاه‌های دولتی در Kafka Streams می‌توانند به‌عنوان یک پایگاه داده توزیع‌شده عمل کنند،
- مدام در کافکا تکرار می شود
- یک CRUD API می تواند به راحتی بر روی چنین سیستمی ساخته شود
- مدیریت چندین پارتیشن کمی پیچیده تر است
- همچنین امکان افزودن یک یا چند فروشگاه حالت به توپولوژی جریان برای ذخیره داده های کمکی وجود دارد. از این گزینه می توان برای موارد زیر استفاده کرد:
- ذخیره سازی طولانی مدت داده های مورد نیاز برای محاسبات در طول پردازش جریان
- ذخیره‌سازی طولانی‌مدت داده‌ها که ممکن است دفعه بعد که نمونه پخش ارائه می‌شود مفید باشد
- خیلی بیشتر...
این مزیت‌ها و دیگر مزیت‌ها باعث می‌شود کافکا استریم برای حفظ وضعیت جهانی در یک سیستم توزیع‌شده مانند ما مناسب باشد. Kafka Streams ثابت کرده است که در تولید بسیار قابل اعتماد است (از زمان استقرار آن عملاً هیچ پیامی از دست نداده ایم)، و مطمئن هستیم که قابلیت های آن در اینجا متوقف نخواهد شد!
منبع: www.habr.com