نحوه سرعت بخشیدن به توسعه عامل RBM با اشتراک کششی

نمایندگان RBM پیام‌ها و رویدادها را از طریق رابطه انتشار/اشتراک با Google Cloud Pub/Sub دریافت می‌کنند. وقتی کاربر به پیام‌های نماینده شما پاسخ می‌دهد، پلتفرم RBM آن پیام‌ها را در یک موضوع Pub/Sub منحصر به فرد منتشر می‌کند که فقط نماینده شما به آن دسترسی دارد. نماینده شما از طریق اشتراک در موضوع منحصر به فرد خود به آن پیام ها و رویدادها دسترسی پیدا می کند.

Pub/Sub از دو نوع اشتراک پشتیبانی می کند: فشار و کشش . با اشتراک فشار، Cloud Pub/Sub پیام‌هایی را به URL وبی هوکی که شما پیکربندی می‌کنید ارسال می‌کند. با یک اشتراک کششی، شما مسئول نوشتن کد برای ایجاد یک شنونده پیام طولانی مدت و تأیید پیام ها در هنگام دریافت آنها هستید.

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

در این مقاله، نحوه تنظیم اشتراک کششی برای آزمایش محلی و نحوه استفاده از این اشتراک در یک محیط تولیدی با موتور برنامه Google Cloud را به شما نشان خواهم داد.

پیکربندی Pub/Sub برای اشتراک کششی

اگر قبلاً Pub/Sub را برای نماینده خود پیکربندی نکرده‌اید، دستورالعمل‌های موجود در Cloud Pub/Sub را دنبال کنید تا اشتراک اولیه خود را ایجاد کنید.

هنگامی که اشتراک خود را ایجاد کردید، تغییر از یک مدل فشاری به یک مدل کششی ساده است. به Google Cloud Console و سپس به بخش Pub/Sub > Subscriptions بروید. روی منوی سرریز در کنار اشتراکی که برای نماینده خود ایجاد کرده‌اید کلیک کنید و ویرایش را انتخاب کنید. شما باید یک صفحه تنظیمات مشابه تصویر زیر را ببینید.

نوع تحویل را روی Pull تنظیم کنید و روی Save کلیک کنید.

راه اندازی یک کنترل کننده اشتراک کشش ناهمزمان

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

کد زیر نحوه راه اندازی یک شنونده اشتراک pull ناهمزمان در Node.js را نشان می دهد:

function initPubsub() {
    let pubsub = new PubSub({
        projectId: REPLACE_WITH_GCP_PROJECT_ID,
        keyFilename: REPLACE_WITH_SERVICE_ACCOUNT_KEY_FILE_LOCATION,
    });

    // references an existing subscription, (e.g. rbm-agent-sub)
    let subscription = pubsub.subscription(PUB_SUB_SUBSCRIPTION_NAME);

    // create an event handler to handle messages
    let messageHandler = (message) => {
        console.log(`Received message ${message.id}:`);
        console.log(`\tData: ${message.data}`);
        console.log(`\tAttributes: ${message.attributes}`);

        let userEvent = JSON.parse(message.data);

        // TODO: process the userEvent to create another RBM message
        // "Ack" (acknowledge receipt of) the message
        message.ack();
    };

    // Listen for new messages
    subscription.on('message', messageHandler);

    return { messageHandler: messageHandler, subscription: subscription };
}

برای آزمایش نمایندگی‌ها به صورت محلی، تنها کاری که باید انجام دهید این است که با شروع برنامه اکسپرس با initPubsub تماس بگیرید و messageHandler را در کنسول خود مشاهده کنید.

پیکربندی و استقرار در موتور برنامه Google

در یک محیط تولید، باید مطمئن شوید که اشتراک همیشه در دسترس است. یک رویکرد ساده، تکیه بر یک کار cron برای شروع مجدد دوره ای شنونده پیام Pub/Sub است.

در App Engine، از cron jobs می توان برای زمان بندی وظایف با فواصل زمانی مختلف استفاده کرد. یک کار cron با توضیحات، URL و فاصله پیکربندی شده است. در برنامه‌های Node.js، اینها را در یک فایل cron.yaml پیکربندی می‌کنید که می‌توانید با استفاده از Google Cloud SDK آن را در App Engine اجرا کنید. می‌توانید در مورد سایر تنظیمات پیکربندی زبان در Jobs Scheduling با cron.yaml مطالعه کنید.

از آنجایی که کار cron به URL نیاز دارد، باید یک نقطه پایانی URL را به مسیریاب برنامه اکسپرس اضافه کنید تا توسط cron فراخوانی شود، که به نوبه خود متد initPubsub را از قسمت قبلی فراخوانی می کند تا شنونده را شروع کند.

router.get('/pubsubCallback', function(req, res, next) {
  let pubsubConfig = initPubsub();

      // Stop listening once the timeout is hit
      setTimeout(() => {
        pubsubConfig.subscription.removeListener('message', pubsubConfig.messageHandler);
      }, CRON_JOB_TIMEOUT * 1000);

  res.status(200).send();
});

در پاسخ به تماس، باید شنونده را قبل از اجرای مجدد وظیفه برنامه ریزی شده حذف کنید. برای مثال، اگر کار cron هر دقیقه اجرا شود، پارامتر CRON_JOB_TIMEOUT را برابر با 60 پیکربندی می‌کنید.

در زیر پیکربندی فایل cron.yaml برای اجرای این نقطه پایانی در هر دقیقه آمده است.

cron:
- description: "Processing Pub/Sub messages"
  url: /pubsubCallback
  schedule: every 1 mins

برای استقرار وظایف cron در App Engine، موارد زیر را اجرا کنید:

gcloud app deploy cron.yaml

پس از استقرار، App engine به طور خودکار وظیفه cron را پیکربندی می‌کند و این کار در زیر App Engine > Cron jobs همانطور که در زیر مشاهده می‌شود قابل مشاهده است.

جمع بندی و TL;DR

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

موفق باشید و کد نویسی شاد!