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

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

بعضی از این نیازمندی‌ها شامل موارد زیر می‌شوند، اما محدود به آنها نمی‌شود:

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

معماری راه‌حل

مرکز پیام جدید برای دو کامپوننت زیر طراحی شده است:

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

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

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

یک جنبه مهم دیگر برای این سرویس، امکان پشتیبانی از ارتباطات کم‌تاخیر و دوطرفه از مشتری تا سرور است. به همین دلیل، برای ارتباط بین مشتریان تلفن همراه و وب از Protocol Control Transmission (TCP) به عنوان پروتکل اصلی استفاده می‌کنیم. مشتریان تلفن همراه و وب به Hermes متصل می‌شوند، سرویس دروازه TCP آذروت، که بسته‌های TCP را هضم می‌کند و بارهای مفید را از طریق gRPC به مرکز پیام رسانی می‌فرستد. اگر گیرنده و فرستنده هر دو آنلاین باشند، پیام با مدت زمانی کمتر از یک میلی‌ثانیه با موفقیت تحویل می‌شود.

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

نمودار زیر نمایشی از دنباله رویدادهای سطح بالا در هنگام ارسال یک پیام نشان می‌دهد.

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

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

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

دروس/نتیجه‌گیری

با وجود ویژگی‌های بزرگ مانند مرکز پیام، مهم است:

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

به ما بپیوندید

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

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