فهرست مندرجات[پنهان شدن][نمایش]
واتس اپ یک برنامه پیام رسانی اجتماعی است که به کاربران امکان می دهد با یکدیگر پیام رد و بدل کنند.
آیا تا به حال به نحوه عملکرد WhatsApp فکر کرده اید؟
مفاهیمی که زیربنای ایجاد و عملکرد آن است چیست؟
در این مقاله به اصول واتس اپ می پردازیم طراحی سیستم.
همچنین معماری کلی واتس اپ را بررسی می کنیم که می توان از آن برای ساخت هر نوع نرم افزار چت استفاده کرد.
بنابراین، بدون بحث بیشتر، بیایید نگاهی به طراحی سیستم WhatsApp داشته باشیم!
1. الزامات کلیدی
واتس اپ یک فناوری بسیار مقیاس پذیر است که توسط افراد زیادی در سراسر جهان استفاده می شود. در نتیجه، باید به خوبی طراحی شود تا تقریباً همیشه قابل اعتماد و کارکرد باشد.
در نتیجه، تعیین نیازهای حیاتی سیستم حیاتی است.
حداقل شرایط لازم برای پیام رسان واتس اپ به شرح زیر است:
- قادر به تسهیل تعاملات یک به یک.
- تأیید پیام و آخرین بازدید هر دو امکان پذیر است (ارسال، تحویل و خوانده شده).
- اجازه رمزگذاری سرتاسر و پشتیبانی رسانه (تصاویر/فیلم) را بدهید.
بیایید دریابیم که خدمات ضروری ما به چه میزان ظرفیت نیاز دارد.
2. برآورد ظرفیت
هدف ما ایجاد پلتفرمی است که بتواند حجم زیادی از ترافیک را مدیریت کند. فرض کنید روزانه 10 میلیارد پیامک ارسال می شود. ما داریم:
- روزانه 10 میلیارد پیامک توسط یک میلیارد نفر ارسال می شود.
- در اوج ترافیک (در هر ثانیه)، 700,000 نفر فعال بودند (6 برابر متوسط)
- در زمان اوج استفاده، 40 میلیون پیام در هر ثانیه مخابره می شود.
- میانگین طول یک پیام 160 کاراکتر است: 10B * 160 = 1.6TB داده هر روز تولید می شود.
- ده سال خدمت را به عنوان مثال در نظر بگیرید: 10 * 1.6B * 365 PB
- کل برنامه از میکروسرویس هایی تشکیل خواهد شد که هر کدام یک وظیفه تخصصی را انجام می دهند. فرض کنید که ارسال یک پیام 20 میلی ثانیه طول می کشد و 100 اتصال همزمان در هر سرور وجود دارد. در نتیجه، تعداد پیشبینیشده سرورهای چت مورد نیاز = (پیامهای چت در ثانیه تأخیر)/ اتصالات همزمان در هر سرور = 40M * 20ms / 100 = 8000 سرور.
3. معماری سطح بالا
این سیستم بر اساس دو سرویس اصلی ساخته شده است. به عنوان مثال، سرویس چت و سرویس گذرا. سرویس چت تمام ترافیک ایجاد شده توسط پیام های آنلاین کاربران را مدیریت می کند. به طور همزمان، سرویس موقت ترافیک را زمانی که کاربر آفلاین است کنترل می کند.
اگر کاربر آنلاین باشد، سرویس چت وظیفه ارسال پیام ها را بر عهده دارد.
بررسی می کند که آیا گیرنده پیام آنلاین است یا خیر. اگر گیرنده آنلاین باشد، این سرویس بلافاصله پیام را ارسال می کند. اگر گیرنده آنلاین نباشد، سرویس گذرا پس از بازگشت آنلاین پیام را برای آنها ارسال می کند.
سرویس گذرا یک فضای ذخیرهسازی جداگانه برای نگهداری دادههای بهطور موقت در دسترس نگه میدارد تا زمانی که کاربر آفلاین دوباره وصل شود.
طراحی APIهای سطح بالا
این سرویس دارای دو API با عملکرد سطح بالا برای ارسال و خواندن پیام است. سیستم را می توان با استفاده از معماری REST پیاده سازی کرد.
پارامترهای ارسال پیام
این API برای انتقال پیام بین دو کاربر استفاده خواهد شد.
پارامترهای مکالمه
این API برای نمایش چت های رشته ای استفاده می شود. این اولین چیزی است که هنگام باز کردن واتس اپ می بینید. ما فقط می خواهیم چند پیام برای یک کاربر در یک جستجوی API دریافت کنیم. برای انجام این کار، پارامترهای offset و تعداد پیام مورد نیاز است.
ویژگی هایی مانند آخرین مشاهده، تک تیک و تیک دوبل چه کارایی دارند؟
نقش مهم در استقرار این خدمات، خدمات قدردانی است. این ویژگیها از آنجایی ایجاد شدهاند که این سرویس همچنان به تولید و تأیید پاسخهای تأیید ادامه میدهد.
- تک تیک: هنگامی که پیامی از کاربر A به کاربر B می رسد، سرور با ارسال یک تیک تأیید می کند که پیام ارسال شده است.
- دو تیک: پس از اینکه پیام سرور از طریق اتصال مناسب به کاربر B ارسال شد، کاربر B دریافت پیام را به سرور تایید می کند. سپس سرور یک تاییدیه دیگر را به کاربر A ارائه می دهد. در نتیجه یک تیک تکراری ظاهر می شود.
- تیک آبی: کاربر B پس از بررسی پیام، تأییدیه دیگری را برای سرور ارسال می کند. سپس سرور یک پیام تأیید اضافی برای کاربر A ارسال می کند. پس از آن یک تیک آبی روی صفحه کاربر A ظاهر می شود.
- آخرین بار دیده شده: مکانیسم ضربان قلب به طور کامل مسئول آخرین ویژگی مشاهده شده است. هر 5 ثانیه یک ضربان قلب به سرور منتقل می شود که آخرین وضعیت مشاهده شده هر کاربر را در جدولی که می تواند به راحتی توسط هر کاربر دیگری قابل دسترسی باشد، پیگیری می کند.
4. طراحی ویژگی های کلیدی
تعامل شخصی
این بخشی ضروری از سرویس چت است. کاربر می تواند به سادگی با استفاده از این سرویس برای کاربر دیگری پیام ارسال کند. بیایید نگاهی به نحوه عملکرد آن بیندازیم:
فرض کنید جی می خواهد با آیوش ارتباط برقرار کند. جی به یک سرور چت متصل است که با آن پیام را دریافت می کند. جی تأییدیه ای از سرور چت دریافت می کند که پیام ارسال شده است. سرور چت اکنون در حال درخواست اطلاعات از فروشگاه داده در مورد سرور چت است که Aayush به آن متصل است. سرور چت Jay اکنون پیام را به سرور چت Aayush منتقل می کند و Aayush پیام را از طریق مکانیزم فشار دریافت می کند. Aayush اکنون یک تأییدیه به سرور چت جی ارسال می کند که به جی اطلاع می دهد که پیام تحویل داده شده است. اگر آیوش دوباره پیام را می خواند، تأیید تازه ای مبنی بر خوانده شدن پیام به جی تحویل داده می شد.
وضعیت فعالیت کاربر
آخرین باری که یک فرد فعال بوده، یکی از ویژگی های معمولی پیام رسان های فوری است.
سیستمی برای حفظ ارتباط بین مشتری و سرور در این نمودار نشان داده شده است. سوکت های وب برای برقراری ارتباط دو طرفه بین سرور و مشتری استفاده شد. این اتصالات ضربان قلب را ارسال می کنند که برای نظارت بر وضعیت فعالیت کاربر استفاده می شود.
حریم خصوصی انتها به انتها
رمزگذاری انتها به انتها یک ویژگی کلیدی است که تضمین می کند فقط کاربران مکالمه می توانند ارتباطات را بخوانند. یک کلید عمومی بین همه کاربران درگیر در ارتباط مشترک است و برای حفظ رمزگذاری End-to-End حیاتی است. فرض کنید در کانال دو کاربر به نام های جی و آیوش وجود دارند که با هم در ارتباط هستند.
Jay دارای کلید عمومی Aayush است و Aayush دارای کلید عمومی Jay و همچنین کلید خصوصی غیر مشترک آنها است. در نتیجه، هنگامی که جی پیام را ارسال می کند، آن را با کلید عمومی Aayush رمزگذاری می کند، که فقط با کلید خصوصی Aayush قابل رمزگشایی است.
به طور مشابه، جی تنها قادر به رمزگشایی ارتباطات Aayush خواهد بود. در نتیجه، فقط Jay و Aaysuh میتوانند ارتباطات یکدیگر را ببینند و سرور فقط به عنوان یک دروازه در کل فرآیند عمل میکند.
5. تنگناها
هر سیستمی مستعد خرابی است. برای مدیریت چنین حجم وسیعی از ترافیک، سرویس باید همیشه عملیاتی و قابل تحمل باشد تا از تنگناها جلوگیری شود. از آنجایی که سرویس ما کاملاً به سرورهای چت و گذرا متکی است، باید همه مشکلات ناشی از عملکرد آنها را حل کنیم.
خرابی سرور چت: این قلب سیستم ماست. هنگامی که کاربران آنلاین هستند، مسئولیت مدیریت و ارسال پیام ها را بر عهده دارد. در نتیجه این سیستم با کاربران خود ارتباط برقرار می کند.
در نتیجه، اگر این سرویس از کار بیفتد، کل معماری آسیب خواهد دید. دو روش برای مدیریت خرابی سرور چت وجود دارد. یک روش این است که اتصالات TCP را به سرور دیگری منتقل کنید، در حالی که روش دیگر این است که به کاربران اجازه دهید در صورت قطع اتصال، اتصالات را به طور خودکار شروع کنند.
خرابی ذخیره سازی گذرا: یکی دیگر از اجزای مستعد خرابی که ممکن است در نهایت به کل سرویس آسیب برساند، ذخیره سازی موقت است. در صورت عدم موفقیت این سرویس، پیامهایی که در مسیر کاربران آفلاین هستند از بین میروند.
ما می توانیم با تکرار فضای ذخیره سازی موقت هر کاربر، از دست دادن پیام جلوگیری کنیم. در نتیجه، هر زمان که کاربر به صورت آنلاین برمی گردد، می توان از ماکت برای پردازش توابع استفاده کرد. اگر سرور اصلی قابل دسترسی باشد، هر دو نمونه اصلی و مشابه حافظه موقت کاربر در یک فروشگاه واحد ترکیب میشوند.
6. تکنیک های بهینه سازی
تاخیر: برای ارائه یک تجربه مشتری بدون درز و بهبود یافته، سرویس پیام رسان باید بلادرنگ باشد. در نتیجه، تأخیر باید با ذخیره بخشی از داده های اغلب قابل دسترسی کاهش یابد. ما می توانیم وضعیت فعالیت کاربر و مکالمات اخیر را با استفاده از حافظه پنهان توزیع شده مانند Redis در حافظه پنهان کنیم.
دسترسی: ما نیاز داریم که خدمات ما در اکثر مواقع در دسترس باشد. سیستم ما باید عیبپذیر باشد، بنابراین میتوانیم چندین نسخه از پیامهای گذرا را نگه داریم تا هر پیامی که گم میشود به سرعت از نسخههای تکراری آن بازیابی شود. در نتیجه، در دسترس بودن سیستم را نمی توان به خطر انداخت.
نتیجه
سیستم ما اکنون تنها از چند قابلیت پشتیبانی میکند، اما میتوانیم به راحتی آن را گسترش دهیم تا چتهای گروهی را برای توزیع پیامها به چندین نفر اضافه کنیم. همچنین می توانید قابلیت های تماس تصویری و تلفنی را نیز ارائه دهید. این سیستم همچنین می تواند به گونه ای توسعه یابد که کاربران بتوانند به روز رسانی وضعیت یا روایت ها را منتشر کنند و یکدیگر را بخوانند.
من سخت کار کردم تا یک نمای کلی از طراحی سیستم واتس اپ در سطح بالایی به شما ارائه کنم. امیدوارم از آن لذت برده باشید و از آن به خوبی استفاده کنید.
پاسخ دهید