شما ماه ها را صرف طراحی مجدد یکپارچه خود به میکروسرویس کرده اید و در نهایت همه گرد هم آمده اند تا سوئیچ را باز کنند. شما به صفحه اول وب می روید و هیچ اتفاقی نمی افتد. شما آن را دوباره بارگذاری می کنید - و دوباره هیچ چیز خوبی نیست، سایت آنقدر کند است که چندین دقیقه پاسخ نمی دهد. چی شد؟
جیمی بوگارد در سخنرانی خود یک "پس از مرگ" در مورد یک فاجعه ریز خدمات واقعی را انجام خواهد داد. او مشکلات مدل‌سازی، توسعه، و تولیدی را که کشف کرده است نشان می‌دهد و اینکه چگونه تیمش به آرامی یکپارچه توزیع شده جدید را به تصویر نهایی سلامت عقل تبدیل کرد. در حالی که جلوگیری کامل از خطاهای طراحی غیرممکن است، حداقل می توانید مشکلات را در مراحل اولیه طراحی شناسایی کنید تا اطمینان حاصل کنید که محصول نهایی به یک سیستم توزیع قابل اعتماد تبدیل می شود.
سلام به همه، من جیمی هستم و امروز می خواهید بشنوید که چگونه می توانید هنگام ساخت میکروسرویس از بلایای بزرگ جلوگیری کنید. این داستان شرکتی است که من حدود یک سال و نیم در آن کار کردم تا از برخورد کشتی آنها با کوه یخ جلوگیری کنم. برای بیان درست این داستان، باید به گذشته برگردیم و در مورد اینکه این شرکت از کجا شروع به کار کرد و چگونه زیرساخت فناوری اطلاعات آن در طول زمان رشد کرده است صحبت کنیم. برای محافظت از نام افراد بی گناه در این فاجعه، نام این شرکت را به Bell Computers تغییر دادم. اسلاید بعدی نشان می دهد که زیرساخت های فناوری اطلاعات چنین شرکت هایی در اواسط دهه 90 چگونه بوده است. این یک معماری معمولی از یک سرور بزرگ جهانی HP Tandem Mainframe با تحمل خطا برای راه اندازی فروشگاه سخت افزار رایانه است.
آنها نیاز به ایجاد سیستمی برای مدیریت تمام سفارشات، فروش، بازگشت، کاتالوگ محصولات و پایگاه مشتریان داشتند، بنابراین رایج ترین راه حل اصلی را در آن زمان انتخاب کردند. این سیستم غول پیکر حاوی تک تک اطلاعات درباره شرکت، همه چیز ممکن بود و هر تراکنش از طریق این مین فریم انجام می شد. آنها تمام تخم های خود را در یک سبد نگه می داشتند و فکر می کردند که این طبیعی است. تنها چیزی که در اینجا گنجانده نشده است، کاتالوگ سفارش پستی و ثبت سفارش از طریق تلفن است.
با گذشت زمان، سیستم بزرگتر و بزرگتر شد و حجم عظیمی از زباله در آن انباشته شد. همچنین، COBOL رساترین زبان در جهان نیست، بنابراین سیستم در نهایت به یک آشغال بزرگ و یکپارچه تبدیل شد. در سال 2000، آنها دیدند که بسیاری از شرکت‌ها وب‌سایت‌هایی دارند که از طریق آنها کاملاً تمام تجارت خود را انجام می‌دهند و تصمیم گرفتند اولین وب‌سایت تجاری دات‌کام خود را بسازند.
طراحی اولیه بسیار زیبا به نظر می رسید و شامل یک سایت سطح بالا bell.com و تعدادی زیر دامنه برای برنامه های کاربردی بود: catalog.bell.com، accounts.bell.com، orders.bell.com، جستجوی محصول search.bell. com هر زیر دامنه از فریم ورک ASP.Net 1.0 و پایگاه داده های خود استفاده می کرد و همه آنها با سیستم پشتیبان صحبت می کردند. با این حال، همه سفارش‌ها در یک مین‌فریم بزرگ واحد پردازش و اجرا می‌شدند، که تمام زباله‌ها در آن باقی می‌ماند، اما بخش جلویی وب‌سایت‌های جداگانه با برنامه‌های کاربردی و پایگاه‌های داده جداگانه بود.
بنابراین طراحی سیستم منظم و منطقی به نظر می رسید، اما سیستم واقعی همانطور که در اسلاید بعدی نشان داده شده بود.
همه عناصر تماس‌ها را به یکدیگر خطاب می‌کردند، به API دسترسی داشتند، dllهای شخص ثالث تعبیه‌شده و موارد مشابه. اغلب اتفاق می‌افتد که سیستم‌های کنترل نسخه کد شخص دیگری را می‌گیرند، آن را داخل پروژه می‌فرستند و سپس همه چیز خراب می‌شود. MS SQL Server 2005 از مفهوم سرورهای پیوند استفاده می‌کرد و اگرچه فلش‌های روی اسلاید را نشان ندادم، اما هر یک از پایگاه‌های داده نیز با یکدیگر صحبت می‌کردند، زیرا ساخت جداول بر اساس داده‌های به‌دست‌آمده از چندین پایگاه داده اشکالی ندارد.
از آنجایی که آنها اکنون بین مناطق مختلف منطقی سیستم فاصله داشتند، این به لکه های خاکی توزیع شده تبدیل شد و بزرگترین تکه زباله هنوز در بک اند مین فریم باقی مانده است.
نکته خنده دار این بود که این مین فریم توسط رقبای رایانه های بل ساخته شد و همچنان توسط مشاوران فنی آنها نگهداری می شد. این شرکت که از عملکرد نامطلوب برنامه های خود متقاعد شده بود، تصمیم گرفت از شر آنها خلاص شود و سیستم را دوباره طراحی کند.
برنامه موجود به مدت 15 سال در حال تولید بود که یک رکورد برای برنامه های مبتنی بر ASP.Net است. این سرویس سفارشات را از سرتاسر جهان پذیرفت و درآمد سالانه این اپلیکیشن به یک میلیارد دلار رسید. بخش قابل توجهی از سود توسط وب سایت bell.com ایجاد شد. در جمعه های سیاه، تعداد سفارش های ثبت شده از طریق سایت به چندین میلیون رسید. با این حال، معماری موجود اجازه هیچ گونه توسعه ای را نمی دهد، زیرا اتصالات سفت و سخت عناصر سیستم عملاً اجازه نمی دهد هیچ تغییری در سرویس ایجاد شود.
جدی ترین مشکل عدم امکان ثبت سفارش از یک کشور، پرداخت هزینه آن در کشور دیگر و ارسال آن به کشور سوم بود، با وجود اینکه چنین طرح معاملاتی در شرکت های جهانی بسیار رایج است. وب سایت موجود اجازه چنین چیزی را نمی داد، بنابراین آنها مجبور شدند این سفارشات را از طریق تلفن بپذیرند و انجام دهند. این باعث شد که شرکت به طور فزاینده ای به تغییر معماری، به ویژه در مورد سوئیچ به میکروسرویس ها فکر کند.
آنها کار هوشمندانه ای را با نگاه کردن به شرکت های دیگر انجام دادند تا ببینند چگونه مشکل مشابهی را حل کرده اند. یکی از این راه حل ها، معماری سرویس نتفلیکس بود که شامل میکروسرویس هایی است که از طریق یک API و یک پایگاه داده خارجی متصل می شوند.
مدیریت Bell Computers تصمیم گرفت که دقیقاً چنین معماری را با رعایت اصول اولیه خاص بسازد. اول، آنها تکرار داده ها را با استفاده از یک رویکرد پایگاه داده مشترک حذف کردند. هیچ داده ای ارسال نشد، برعکس، همه کسانی که به آن نیاز داشتند باید به یک منبع متمرکز می رفتند. این امر با انزوا و خودمختاری همراه بود - هر سرویس مستقل از دیگران بود. آنها تصمیم گرفتند که از Web API برای همه چیز استفاده کنند - اگر می خواستید داده ها را دریافت کنید یا تغییراتی در سیستم دیگری ایجاد کنید، همه از طریق Web API انجام می شد. آخرین چیز بزرگ، یک مین فریم جدید به نام "Bell on Bell" بود که برخلاف مین فریم "Bell" بر اساس سخت افزار رقبا بود.
بنابراین، در طول 18 ماه، آنها سیستم را حول این اصول اصلی ساختند و آن را به مرحله پیش تولید رساندند. پس از تعطیلات آخر هفته، توسعه دهندگان دور هم جمع شدند و تمام سرورهایی را که سیستم جدید به آنها متصل بود روشن کردند. 18 ماه کار، صدها توسعه‌دهنده، مدرن‌ترین سخت‌افزار Bell - و بدون نتیجه مثبت! این امر بسیاری از مردم را ناامید کرده است زیرا آنها بارها این سیستم را روی لپ تاپ خود اجرا کرده اند و همه چیز خوب بود.
آنها باهوش بودند که تمام پول خود را صرف حل این مشکل کردند. آنها مدرن ترین قفسه های سرور را با سوئیچ نصب کردند، از فیبر نوری گیگابیتی استفاده کردند، قدرتمندترین سخت افزار سرور با مقدار دیوانه کننده رم، همه آن را متصل کردند، پیکربندی کردند - و باز هم هیچ چیز! سپس آنها شروع به مشکوک شدن کردند که دلیل آن ممکن است مهلت زمانی باشد، بنابراین آنها به تمام تنظیمات وب، تمام تنظیمات API رفتند و کل پیکربندی مهلت زمانی را به حداکثر مقادیر به روز کردند، به طوری که تنها کاری که می توانستند انجام دهند این بود که بنشینند و منتظر بمانند تا اتفاقی بیفتد. به سایت آنها منتظر ماندند و منتظر ماندند و 9 دقیقه و نیم منتظر ماندند تا بالاخره وب سایت بارگذاری شد.
بعد از آن متوجه شدند که شرایط فعلی نیاز به تحلیل دقیق دارد و ما را دعوت کردند. اولین چیزی که متوجه شدیم این بود که در تمام 18 ماه توسعه، یک "میکرو" واقعی ایجاد نشد - همه چیز فقط بزرگتر شد. پس از این، ما شروع به نوشتن یک پس از مرگ کردیم، همچنین به عنوان "عقب نگر" یا "بازنگری غم انگیز" شناخته می شود، همچنین به عنوان "طوفان سرزنش" شناخته می شود، شبیه به یک "طوفان مغزی"، برای درک علت فاجعه.
ما چندین سرنخ داشتیم که یکی از آنها اشباع کامل ترافیک در زمان فراخوانی API بود. هنگامی که از یک معماری سرویس یکپارچه استفاده می کنید، می توانید بلافاصله متوجه شوید که دقیقا چه اشتباهی رخ داده است، زیرا یک ردیابی پشته ای دارید که همه چیزهایی را که می تواند باعث خرابی شده باشد را گزارش می دهد. در موردی که تعدادی از سرویس ها به طور همزمان به یک API دسترسی دارند، راهی برای ردیابی ردیابی وجود ندارد به جز استفاده از ابزارهای نظارتی شبکه اضافی مانند WireShark که به لطف آن می توانید یک درخواست را بررسی کنید و متوجه شوید که در طول اجرای آن چه اتفاقی افتاده است. بنابراین ما یک صفحه وب را انتخاب کردیم و تقریباً 2 هفته وقت گذاشتیم تا قطعات پازل را کنار هم قرار دهیم، تماس های مختلفی با آن برقرار کنیم و تجزیه و تحلیل کنیم که هر کدام از آنها به چه چیزی منجر می شود.
به این عکس نگاه کن. این نشان می‌دهد که یک درخواست خارجی از سرویس می‌خواهد تا تماس‌های داخلی زیادی برقرار کند که برمی‌گردند. به نظر می رسد که هر تماس داخلی برای اینکه بتواند به طور مستقل این درخواست را سرویس دهد، پرش های اضافی ایجاد می کند، زیرا نمی تواند برای به دست آوردن اطلاعات لازم به جای دیگری مراجعه کند. این تصویر مانند یک آبشار بی‌معنی از تماس‌ها به نظر می‌رسد، زیرا درخواست خارجی سرویس‌های اضافی را فراخوانی می‌کند، که سایر خدمات اضافی و غیره را تقریباً بی‌نهایت فراخوانی می‌کند.
رنگ سبز در این نمودار نیم دایره ای را نشان می دهد که در آن سرویس ها یکدیگر را صدا می زنند - سرویس A با سرویس B تماس می گیرد و سرویس B سرویس C و دوباره سرویس A را فراخوانی می کند.در نتیجه یک "بن بست توزیع شده" دریافت می کنیم. یک درخواست، هزاران تماس API شبکه ایجاد کرد، و از آنجایی که سیستم دارای تحمل خطا و محافظت از حلقه داخلی نبود، اگر حتی یکی از این تماس‌های API شکست بخورد، درخواست با شکست مواجه می‌شود.
ما کمی ریاضی انجام دادیم. هر تماس API دارای SLA حداکثر 150 میلی‌ثانیه و 99,9 درصد آپتایم بود. یک درخواست باعث 200 تماس مختلف شد و در بهترین حالت، صفحه را می‌توان در 200 x 150 ms = 30 ثانیه نشان داد. طبیعتاً این خوب نبود. با ضرب 99,9% آپتایم در 200، در دسترس بودن 0% بدست آمد. معلوم می شود که این معماری از همان ابتدا محکوم به شکست بوده است.
از توسعه دهندگان پرسیدیم که چگونه پس از 18 ماه کار نتوانستند این مشکل را تشخیص دهند؟ معلوم شد که آنها فقط SLA را برای کدی که اجرا کرده اند شمارش کرده اند، اما اگر سرویس آنها سرویس دیگری را فراخوانی می کند، آن زمان را در SLA خود حساب نمی کنند. هر چیزی که در یک فرآیند راه‌اندازی می‌شد، به مقدار 150 میلی‌ثانیه پایبند بود، اما دسترسی به سایر فرآیندهای سرویس، کل تأخیر را چندین برابر افزایش داد. اولین درس آموخته شده این بود: "آیا شما کنترل SLA خود را دارید یا SLA کنترل شما را در دست دارد؟" در مورد ما، دومی بود.
نکته بعدی که ما کشف کردیم این بود که آنها از مفهوم اشتباهات محاسباتی توزیع شده که توسط پیتر دیچ و جیمز گاسلینگ فرموله شده بود می دانستند، اما قسمت اول آن را نادیده گرفتند. بیان می‌کند که عبارات «شبکه قابل اعتماد است»، «تأخیر صفر» و «توان بی‌نهایت» تصورات نادرستی هستند. سایر تصورات غلط عبارتند از: "شبکه امن است"، "توپولوژی هرگز تغییر نمی کند"، "همیشه فقط یک مدیر وجود دارد"، "هزینه انتقال داده ها صفر است" و "شبکه همگن است."
آنها اشتباه کردند زیرا سرویس خود را روی ماشین های محلی آزمایش کردند و هرگز با سرویس های خارجی وصل نشدند. هنگام توسعه محلی و استفاده از کش محلی، آنها هرگز با پرش شبکه مواجه نشدند. در تمام 18 ماه توسعه، آنها هرگز فکر نکردند که اگر خدمات خارجی تحت تأثیر قرار گیرند چه اتفاقی می افتد.
اگر به مرزهای سرویس در تصویر قبلی نگاه کنید، متوجه می شوید که همه آنها نادرست هستند. منابع زیادی وجود دارند که در مورد چگونگی تعریف مرزهای سرویس توصیه می کنند، و اکثر آنها این کار را اشتباه انجام می دهند، مانند مایکروسافت در اسلاید بعدی.
این تصویر از وبلاگ MS با موضوع "چگونه میکروسرویس بسازیم" است. این یک برنامه وب ساده، یک بلوک منطق تجاری و یک پایگاه داده را نشان می دهد. درخواست مستقیماً ارسال می شود، احتمالاً یک سرور برای وب، یک سرور برای تجارت و یکی برای پایگاه داده وجود دارد. اگر ترافیک را افزایش دهید، تصویر کمی تغییر می کند.
در اینجا یک بار متعادل کننده برای توزیع ترافیک بین دو سرور وب، یک کش که بین وب سرویس و منطق تجاری قرار دارد، و یک کش دیگر بین منطق تجاری و پایگاه داده ارائه می شود. این دقیقاً همان معماری است که Bell برای متعادل کردن بار و برنامه استقرار آبی/سبز در اواسط دهه 2000 استفاده کرد. تا زمانی که همه چیز به خوبی کار می کرد، زیرا این طرح برای یک ساختار یکپارچه در نظر گرفته شده بود.
تصویر زیر نشان می‌دهد که چگونه MS حرکت از یکپارچه به میکروسرویس‌ها را توصیه می‌کند - به سادگی هر یک از سرویس‌های اصلی را به میکروسرویس‌های جداگانه تقسیم می‌کنند. در حین اجرای این طرح بود که بل مرتکب اشتباه شد.
آنها تمام خدمات خود را به لایه های مختلفی تقسیم کردند که هر کدام شامل بسیاری از خدمات فردی بود. به عنوان مثال، وب سرویس شامل میکروسرویس‌هایی برای رندر محتوا و احراز هویت بود، سرویس منطق تجاری شامل ریزسرویس‌هایی برای پردازش سفارش‌ها و اطلاعات حساب بود، پایگاه داده به دسته‌ای از ریزسرویس‌ها با داده‌های تخصصی تقسیم شد. هم وب، هم منطق تجاری و هم پایگاه داده خدماتی بدون تابعیت بودند.
با این حال، این تصویر کاملاً اشتباه بود زیرا هیچ واحد تجاری خارج از خوشه فناوری اطلاعات شرکت را ترسیم نکرد. این طرح هیچ ارتباطی با دنیای خارج را در نظر نمی گرفت، بنابراین مشخص نبود که مثلاً چگونه می توان تجزیه و تحلیل تجاری شخص ثالث را به دست آورد. متذکر می شوم که آنها خدمات متعددی نیز داشتند که صرفاً برای توسعه مشاغل فردی کارمندانی اختراع شده بودند که به دنبال مدیریت هر چه بیشتر افراد بودند تا برای آن پول بیشتری به دست آورند.
آنها بر این باور بودند که انتقال به میکروسرویس ها به راحتی زیرساخت لایه فیزیکی لایه N داخلی آنها و چسباندن Docker بر روی آن است. بیایید نگاهی به معماری سنتی N-tier بیاندازیم.
این شامل 4 سطح است: سطح رابط کاربری UI، سطح منطق تجاری، سطح دسترسی به داده ها و پایگاه داده. پیشرفته تر DDD (طراحی دامنه محور) یا معماری نرم افزار محور است که در آن دو سطح میانی اشیاء دامنه و یک مخزن هستند.
من سعی کردم در این معماری به حوزه های مختلف تغییر، حوزه های مختلف مسئولیت نگاه کنم. در یک کاربرد معمولی N-tier، نواحی مختلف تغییر طبقه بندی می شوند که از بالا به پایین به صورت عمودی در ساختار نفوذ می کنند. اینها عبارتند از کاتالوگ، تنظیمات پیکربندی انجام شده در رایانه های فردی، و بررسی های Checkout که توسط تیم من انجام می شود.
ویژگی این طرح این است که مرزهای این مناطق تغییر نه تنها بر سطح منطق تجاری تأثیر می گذارد، بلکه به پایگاه داده نیز گسترش می یابد.
بیایید ببینیم که سرویس بودن به چه معناست. 6 ویژگی مشخصه برای تعریف سرویس وجود دارد - نرم افزاری است که:
- ایجاد و استفاده توسط یک سازمان خاص؛
- مسئول محتوا، پردازش و/یا ارائه نوع خاصی از اطلاعات در سیستم است.
- می تواند به طور مستقل برای رفع نیازهای عملیاتی خاص ساخته، مستقر و اجرا شود.
- با مصرف کنندگان و سایر خدمات ارتباط برقرار می کند و اطلاعاتی را بر اساس توافق نامه ها یا ضمانت های قراردادی ارائه می دهد.
- از خود در برابر دسترسی غیرمجاز محافظت می کند و اطلاعات خود را از دست دادن محافظت می کند.
- خرابی ها را به گونه ای مدیریت می کند که منجر به آسیب اطلاعاتی نشود.
همه این ویژگی ها را می توان در یک کلمه "خودمختاری" بیان کرد. خدمات مستقل از یکدیگر عمل می کنند، محدودیت های خاصی را برآورده می کنند و قراردادهایی را تعریف می کنند که بر اساس آن افراد می توانند اطلاعات مورد نیاز خود را دریافت کنند. من به فناوری های خاصی اشاره نکردم که استفاده از آنها بدیهی است.
حال بیایید به تعریف میکروسرویس ها نگاه کنیم:
- یک میکروسرویس از نظر اندازه کوچک است و برای حل یک مشکل خاص طراحی شده است.
- میکروسرویس مستقل است.
- هنگام ایجاد یک معماری میکروسرویس، از استعاره برنامه ریزی شهری استفاده می شود. این تعریف از کتاب سام نیومن به نام Building Microservices است.
تعریف Bounded Context از کتاب طراحی دامنه محور اریک ایوانز گرفته شده است. این یک الگوی اصلی در DDD است، یک مرکز طراحی معماری که با مدل‌های معماری حجمی کار می‌کند، آنها را به زمینه‌های محدود مختلف تقسیم می‌کند و به صراحت تعاملات بین آنها را تعریف می‌کند.
به زبان ساده، Bounded Context محدوده ای را نشان می دهد که در آن یک ماژول خاص می تواند استفاده شود. در این زمینه یک مدل منطقی یکپارچه وجود دارد که به عنوان مثال در حوزه کسب و کار شما قابل مشاهده است. اگر از پرسنل دخیل در سفارشات بپرسید «مشتری کیست»، یک تعریف دریافت خواهید کرد، اگر از کسانی که درگیر فروش هستند بپرسید، تعریف دیگری دریافت خواهید کرد و مجریان تعریف سومی را به شما خواهند داد.
بنابراین، Bounded Context می‌گوید که اگر نمی‌توانیم تعریف روشنی از مصرف‌کننده خدماتمان ارائه کنیم، بیایید مرزهایی را تعریف کنیم که در آن می‌توانیم درباره معنای این اصطلاح صحبت کنیم و سپس نقاط انتقال بین این تعاریف مختلف را تعریف کنیم. یعنی اگر از نظر سفارش دادن در مورد مشتری صحبت می کنیم، این یعنی این و آن و اگر از نظر فروش، این یعنی این و آن.
تعریف بعدی میکروسرویس، کپسوله کردن هر نوع عملیات داخلی است که از "نشت" اجزای فرآیند کار به محیط جلوگیری می کند. در مرحله بعدی «تعریف قراردادهای صریح برای تعاملات خارجی یا ارتباطات خارجی» آمده است که با ایده قراردادهای بازگشتی از SLA نشان داده می شود. آخرین تعریف، استعاره سلول یا سلول است که به معنای کپسوله‌سازی کامل مجموعه‌ای از عملیات در یک میکروسرویس و وجود گیرنده‌هایی برای ارتباط با دنیای خارج در آن است.
بنابراین ما به بچه‌های Bell Computers گفتیم: «ما نمی‌توانیم هیچ یک از آشفتگی‌هایی را که ایجاد کرده‌اید برطرف کنیم، زیرا شما پول لازم برای انجام آن را ندارید، اما ما فقط یک سرویس را تعمیر می‌کنیم تا همه آن را به نتیجه برسانیم. احساس، مفهوم." در این مرحله، من با بیان اینکه چگونه تنها سرویس خود را به گونه‌ای تعمیر کردیم که سریع‌تر از 9 دقیقه و نیم به درخواست‌ها پاسخ دهد، شروع می‌کنم.
22:30 دقیقه
به زودی ادامه دارد...
مقداری تبلیغات
از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید , یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: (در دسترس با 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