جاش ایوانز در مورد دنیای پر هرج و مرج و رنگارنگ میکروسرویس‌های نتفلیکس صحبت می‌کند و با اصول اولیه شروع می‌کند - آناتومی میکروسرویس‌ها، چالش‌های مرتبط با سیستم‌های توزیع‌شده، و مزایای آنها. او با تکیه بر این پایه، شیوه های فرهنگی، معماری و عملیاتی را که منجر به تسلط در ریزسرویس می شود، بررسی می کند.
برخلاف رانش عملیاتی، معرفی زبان‌های جدید برای بین‌المللی‌سازی خدمات و فناوری‌های جدید مانند کانتینرها، تصمیم‌هایی آگاهانه برای افزودن پیچیدگی جدید به محیط هستند. تیم عملیات من بهترین نقشه راه فناوری را برای Netflix استاندارد کرد، که در بهترین شیوه های از پیش تعریف شده بر اساس جاوا و EC2 ساخته شده بود، اما با رشد کسب و کار، توسعه دهندگان شروع به اضافه کردن اجزای جدید مانند Python، Ruby، Node-JS و Docker کردند.
من بسیار مفتخرم که ما اولین کسی بودیم که از عملکرد عالی محصولمان بدون انتظار شکایات مشتری حمایت کردیم. همه چیز به اندازه کافی ساده شروع شد - ما برنامه های عملیاتی در پایتون و چند برنامه کاربردی پشتیبان در Ruby داشتیم، اما وقتی توسعه دهندگان وب ما اعلام کردند که قصد دارند JVM را کنار بگذارند و وب را جابه جا کنند، همه چیز بسیار جالب تر شد. برنامه در پلتفرم نرم افزار Node. js. پس از معرفی Docker، همه چیز بسیار پیچیده تر شد. ما از منطق پیروی کردیم و فناوری هایی که به دست آوردیم زمانی که آنها را برای مشتریان پیاده سازی کردیم به واقعیت تبدیل شدند زیرا آنها بسیار منطقی بودند. من به شما می گویم که چرا اینطور است.
API Gateway در واقع توانایی ادغام اسکریپت های عالی را دارد که می توانند به عنوان نقطه پایانی برای توسعه دهندگان UI عمل کنند. آنها هر یک از این اسکریپت ها را به گونه ای تبدیل کردند که پس از ایجاد تغییرات می توانستند آنها را در تولید و سپس به دستگاه های کاربر مستقر کنند و همه این تغییرات با نقاط پایانی که در دروازه API اجرا می شدند هماهنگ شدند.
با این حال، این مشکل ایجاد یک مونولیت جدید را تکرار کرد که در آن سرویس API با کد بیش از حد بارگذاری شده بود به گونه‌ای که سناریوهای خرابی مختلفی رخ می‌داد. به عنوان مثال، برخی از نقاط پایانی حذف شدند، یا اسکریپت ها به طور تصادفی نسخه های زیادی از چیزی را تولید کردند که نسخه ها تمام حافظه موجود سرویس API را اشغال کردند.
منطقی بود که این نقاط پایانی را گرفته و از سرویس API خارج کنیم. برای انجام این کار، اجزای Node.js را ایجاد کردیم که به عنوان برنامه های کوچک در کانتینرهای Docker اجرا می شدند. این به ما اجازه می‌دهد تا مشکلات و خرابی‌های ناشی از این برنامه‌های گره را جدا کنیم.
هزینه این تغییرات بسیار زیاد است و شامل عوامل زیر است:
- ابزار بهره وری مدیریت فناوری‌های جدید به ابزارهای جدیدی نیاز داشت، زیرا تیم UI با استفاده از اسکریپت‌های بسیار خوب برای ایجاد یک مدل کارآمد، مجبور نبود زمان زیادی را برای مدیریت زیرساخت صرف کند، آنها فقط باید اسکریپت‌ها را بنویسند و عملکرد آنها را بررسی کنند.
بینش فرصت و مرتب‌سازی - یک مثال کلیدی ابزارهای جدید مورد نیاز برای کشف اطلاعات درایور عملکرد است. لازم بود بدانیم پردازنده چقدر اشغال شده است، از حافظه چگونه استفاده می شود و جمع آوری این اطلاعات به ابزارهای مختلفی نیاز دارد. - تکه تکه شدن تصاویر پایه - پایه ساده AMI تکه تکه تر و تخصصی تر شده است.
- مدیریت گره. هیچ معماری یا فناوری غیرقابل استفاده ای در دسترس نیست که به شما امکان می دهد گره ها را در فضای ابری مدیریت کنید، بنابراین ما Titus را ساختیم، یک پلت فرم مدیریت کانتینر که استقرار کانتینر مقیاس پذیر و قابل اعتماد و یکپارچه سازی ابری را با Amazon AWS فراهم می کند.
- تکراری شدن یک کتابخانه یا پلتفرم ارائه فناوری‌های جدید با همان عملکرد اصلی پلتفرم نیازمند کپی کردن آن در ابزارهای توسعه‌دهنده Node.js مبتنی بر ابر بود.
- منحنی یادگیری و تجربه صنعتی. معرفی فناوری های جدید ناگزیر چالش های جدیدی را ایجاد می کند که باید بر آنها غلبه کرد و از آنها درس گرفت.
بنابراین، ما نمی‌توانستیم خود را به یک «جاده آسفالته» محدود کنیم و مجبور بودیم دائماً راه‌های جدیدی برای پیشرفت فناوری‌های خود بسازیم. برای پایین نگه داشتن هزینه ها، پشتیبانی متمرکز را محدود کردیم و بر JVM، نودهای جدید و داکر تمرکز کردیم. ما تأثیر مؤثر را در اولویت قرار دادیم، تیم‌ها را در مورد هزینه تصمیم‌هایشان آگاه کردیم و آنها را تشویق کردیم که به دنبال راه‌هایی برای استفاده مجدد از راه‌حل‌های تأثیرگذار باشند که قبلاً توسعه داده بودند. ما از این رویکرد هنگام ترجمه خدمات به زبان های خارجی برای ارائه محصول به مشتریان بین المللی استفاده کردیم. نمونه‌ها شامل کتابخانه‌های کلاینت نسبتاً ساده‌ای هستند که می‌توانند به طور خودکار تولید شوند، به طوری که ایجاد یک نسخه پایتون، یک نسخه روبی، یک نسخه جاوا و غیره نسبتاً آسان است.
ما دائماً به دنبال فرصت هایی برای استفاده از فناوری های اثبات شده ای بودیم که خود را در یک مکان و در موقعیت های مشابه دیگر ثابت کرده بودند.
بیایید در مورد آخرین عنصر - تغییرات یا تغییرات صحبت کنیم. نگاه کنید که چگونه مصرف محصول ما در روز هفته و ساعت در طول روز به طور ناموزون تغییر می کند. می توان گفت که ساعت 9 صبح سخت ترین زمان برای نتفلیکس است، زمانی که بار روی سیستم به حداکثر خود می رسد.
چگونه می‌توانیم به سرعت بالای اجرای نوآوری‌های نرم‌افزاری یعنی ایجاد تغییرات جدید در سیستم، بدون ایجاد وقفه در ارائه خدمات و بدون ایجاد مزاحمت برای مشتریان خود دست یابیم؟ نتفلیکس با استفاده از Spinnaker، یک پلتفرم جدید مدیریت مبتنی بر ابر جهانی و تحویل مستمر (CD) به این مهم دست یافت.
به طور حیاتی، Spinnaker برای یکپارچه‌سازی بهترین شیوه‌های ما طراحی شده است، به طوری که در حین استقرار اجزا در تولید، بتوانیم خروجی را مستقیماً در فناوری تحویل رسانه خود ادغام کنیم.
ما توانسته‌ایم دو فناوری را در خط لوله تحویل خود بگنجانیم که برای ما ارزش زیادی قائل است: تجزیه و تحلیل خودکار قناری و استقرار مرحله‌ای. تجزیه و تحلیل قناری به این معنی است که ما یک قطره از ترافیک را به نسخه جدید کد هدایت می کنیم و بقیه ترافیک تولید را از طریق نسخه قدیمی عبور می دهیم. سپس بررسی می‌کنیم که چگونه کد جدید با کار کنار می‌آید - بهتر یا بدتر از کد موجود.
عرضه گام به گام به این معنی است که اگر عرضه در یک منطقه مشکل داشته باشد، ما به سمت عرضه در منطقه دیگر حرکت می کنیم. در این صورت چک لیست فوق باید در خط لوله تولید گنجانده شود. اگر می‌خواهید عمیق‌تر در این موضوع غواصی کنید، در زمان شما صرفه‌جویی می‌کنم و توصیه می‌کنم سخنرانی قبلی من، مهندسی عملیات جهانی نتفلیکس در ابر را بررسی کنید. فیلم ضبط شده سخنرانی را می توانید از طریق لینک پایین اسلاید مشاهده کنید.
در پایان صحبت به طور خلاصه در مورد سازماندهی و معماری نتفلیکس صحبت خواهم کرد. در همان ابتدا ما طرحی به نام تحویل الکترونیک داشتیم که اولین نسخه پخش رسانه ای NRDP 1.x بود. اصطلاح "backstream" را می توان در اینجا استفاده کرد زیرا در ابتدا کاربر فقط می توانست محتوا را برای پخش بعدی در دستگاه بارگیری کند. اولین پلتفرم تحویل دیجیتال نتفلیکس، در سال 2009، چیزی شبیه به این بود.
دستگاه کاربر حاوی برنامه Netflix بود که شامل یک رابط UI، ماژول‌های امنیتی، فعال‌سازی و پخش سرویس بر اساس پلتفرم NRDP - Netflix Ready Device Platform بود.
در آن زمان رابط کاربری بسیار ساده بود. این شامل چیزی بود که Queque Reader نامیده می شد و کاربر برای افزودن چیزی به Queque به سایت می رفت و سپس محتوای اضافه شده را در دستگاه خود مشاهده می کرد. نکته مثبت این بود که تیم فرانت اند و تیم بک اند متعلق به یک سازمان تحویل الکترونیک بودند و رابطه کاری نزدیکی داشتند. محموله بر اساس XML ایجاد شده است. در همان زمان، API Netflix برای کسب و کار DVD ایجاد شد که برنامه های شخص ثالث را تشویق می کرد تا ترافیک را به سمت سرویس ما هدایت کنند.
با این حال، Netflix API برای کمک به ما با یک رابط کاربری نوآورانه، حاوی فراداده‌های تمام محتوا، اطلاعاتی درباره فیلم‌هایی که در دسترس هستند، به ما کمک می‌کند، که توانایی تولید فهرست‌های تماشا را ایجاد می‌کند. دارای یک REST API عمومی مبتنی بر طرح JSON، کد پاسخ HTTP، همان مورد استفاده در معماری مدرن، و یک مدل امنیتی OAuth، که در آن زمان برای یک برنامه فرانت اند مورد نیاز بود. این امکان انتقال از یک مدل عمومی ارائه محتوای جریانی به یک مدل خصوصی را فراهم کرد.
مشکل انتقال، تکه تکه شدن بود، زیرا اکنون سیستم ما دو سرویس را بر اساس اصول عملکرد کاملاً متفاوت اجرا می کند - یکی در Rest، JSON و OAuth، دیگری در RPC، XML و یک مکانیسم امنیتی کاربر بر اساس سیستم توکن NTBA. این اولین معماری هیبریدی بود.
اساساً یک فایروال بین دو تیم ما وجود داشت زیرا در ابتدا API با NCCP خیلی خوب مقیاس نداشت و این منجر به اصطکاک بین تیم ها شد. تفاوت ها در سرویس ها، پروتکل ها، مدارها، ماژول های امنیتی بود و توسعه دهندگان اغلب مجبور بودند بین زمینه های کاملاً متفاوت جابجا شوند.
در همین راستا با یکی از مهندسان ارشد شرکت گفت‌وگو کردم که از او این سوال را پرسیدم که معماری بلندمدت مناسب چگونه باید باشد؟ در مورد پیامدهای سازمانی - اگر این چیزها را یکپارچه کنیم، و آنها آنچه را که یاد گرفته ایم به خوبی انجام دهیم، شکسته شوند، چه اتفاقی می افتد؟ این رویکرد با قانون کانوی بسیار مرتبط است: "سازمان هایی که سیستم ها را طراحی می کنند توسط طرحی که ساختار ارتباطی آن سازمان را تکرار می کند، محدود می شوند." این یک تعریف بسیار انتزاعی است، بنابراین تعریف خاص‌تری را ترجیح می‌دهم: «هر نرم‌افزاری منعکس‌کننده ساختار سازمانی است که آن را ایجاد کرده است». در اینجا نقل قول مورد علاقه من از اریک ریموند است: "اگر شما چهار تیم از توسعه دهندگان دارید که روی یک کامپایلر کار می کنند، در نهایت با یک کامپایلر چهار پاسی مواجه خواهید شد." خوب، نتفلیکس یک کامپایلر چهار پاس دارد، و ما اینگونه کار می کنیم.
می توان گفت که در این حالت دم سگ را تکان می دهد. اولویت اول ما راه حل نیست، بلکه سازمان است؛ این سازمان است که معماری را که ما داریم به پیش می برد. به تدریج، از مجموعه‌ای از سرویس‌ها، به معماری منتقل شدیم که آن را Blade Runner نامیدیم، زیرا در اینجا در مورد سرویس‌های لبه و توانایی NCCP برای جداسازی و ادغام مستقیماً در پراکسی Zuul، دروازه API و عملکرد مربوطه صحبت می‌کنیم. "قطعه ها" به میکروسرویس های جدید با ویژگی های امنیتی پیشرفته تر، پخش مجدد، مرتب سازی داده ها و غیره تبدیل شده اند.
بنابراین، می توان گفت که ساختارهای دپارتمان و پویایی شرکت نقش مهمی در شکل دادن به طراحی سیستم ایفا می کنند و عاملی هستند که باعث ارتقا یا ممانعت از تغییر می شوند. معماری میکروسرویس ها پیچیده و ارگانیک است و سلامت آن مبتنی بر نظم و هرج و مرج معرفی شده است.
مقداری تبلیغات
از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید , یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).
Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید
منبع: www.habr.com