پرس و جو از ریز سرویس ها در زمان واقعی با نماهای واقعی

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

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

درک سناریو و مشکلات

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

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

فرض کنید که الگوی ترکیب API را برای مورد بالا برای پرس و جو داده ها از چندین میکروسرویس در یک فراخوانی API اعمال می کنید.

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

پرس و جو با دیدگاه های مادی شده

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

پرس و جوها را از دستورات جدا کنید

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

پرس و جوها را شناسایی کنید، نماهای واقعی ایجاد کنید

بیایید روی بخش پرس و جو CQRS تمرکز کنیم. یکی از روش‌های پیاده‌سازی آن، استفاده از نماهای بهینه‌سازی شده برای خواندن است.

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

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

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

نماهای تحقق یافته را همگام نگه دارید

در مرحله بعد، ما باید نمای مادی شده را به روز نگه داریم. پایگاه داده جریان می تواند بلع داده ها در زمان واقعی از تمام پایگاه های داده به عنوان جریان رویداد با استفاده از فرآیند Change Data Capture و کانکتور داخلی. اگر از PostgreSQL برای یک میکروسرویس خاص به‌عنوان منبع داده استفاده می‌کنید، می‌توانید از رابط CDC PostgreSQL RisingWave برای به دست آوردن داده‌های بلادرنگ مستقیم از گزارش‌های تغییرات (بدون استفاده از واسطه‌های پیام مانند کافکا) استفاده کنید. RisingWave با پیوستن این جریان‌ها به یکدیگر، نمای مادی‌شده‌ای ایجاد می‌کند و با آمدن رویدادهای جدید، نما را به‌روز نگه می‌دارد (به‌روزرسانی‌های رویداد محور). به عنوان مثال، هنگامی که یک محصول جدید به ریزسرویس کاتالوگ محصول اضافه می‌شود، می‌توان یک رویداد مربوطه را ثبت کرد و برای به‌روزرسانی نمای تحقق‌یافته برای فهرست‌های محصولات، استفاده کرد و اطمینان حاصل کرد که نمایش همیشه به‌روز است.

RisingWave یک پایگاه داده جریان متن باز است که دارای رابط های منبع CDC کاملاً مدیریت شده برای پایگاه های داده مختلف است، همچنین می تواند داده ها را از منابع دیگر مانند Kafka، Pulsar، Kinesis یا Redpanda جمع آوری کند و به شما امکان می دهد استریم های بلادرنگ را جستجو کنید. با استفاده از SQL شما می توانید نمای مادی شده ای داشته باشید که همیشه به روز باشد.

نماهای تحقق یافته را پرس و جو کنید

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

ایجاد و جستجوی نماهای تحقق یافته با RisingWave

در این مخزن GitHub، می توانید چندین مورد استفاده از نماهای تحقق یافته را با پایگاه داده استریم RisingWave پیدا کنید. ببینید چگونه اتصال به MySQL به عنوان منبع و تعریف جداول پایگاه داده برای بازیابی داده هایی که به آنها علاقه مندیم و دریافت به روز رسانی های بلادرنگ در پایگاه داده های جریانی، ساده است.

create table order_events (
    order_id int,
    order_date bigint,
    customer_name varchar,
    price decimal,
    product_id int,
    order_status smallint,
    PRIMARY KEY (order_id)
) with (
    connector = 'mysql-cdc',
    hostname = 'mysql',
    port = '3306',
    username = 'root',
    password = '123456',
    database.name = 'mydb',
    table.name = 'orders',
    server.id = '1'
);

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

CREATE MATERIALIZED VIEW order_details AS
SELECT
    order_id,
    SUM(item_price) AS total_price,
    AVG(item_price) AS avg_price
FROM
    order_events
GROUP BY
    order_id;

مزایای نماهای تحقق یافته با پایگاه داده جریان برای پرس و جو

همانطور که در معماری جدید اپلیکیشن فروشگاه آنلاین دیدیم، اجزای جدیدی مانند پایگاه داده استریم و کنترل کننده پرس و جو را معرفی می کند و چندین مزیت را ارائه می دهد:

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

نتیجه

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

منابع مرتبط

محتوای پیشنهادی

انجمن

🙋 به انجمن Risingwave بپیوندید

درباره نویسنده

از وبلاگ من دیدن کنید: www.iambobur.com