سلام! نام من وادیم مدیسون است، من توسعه پلت فرم سیستم Avito را رهبری می کنم. بیش از یک بار گفته شده است که چگونه ما در شرکت از یک معماری یکپارچه به یک معماری میکروسرویس حرکت می کنیم. زمان آن فرا رسیده است که به اشتراک بگذاریم که چگونه زیرساخت های خود را تغییر داده ایم تا بیشترین بهره را از ریزسرویس ها ببریم و از گم شدن خود در آنها جلوگیری کنیم. چگونه PaaS در اینجا به ما کمک می کند، چگونه استقرار را ساده کردیم و ایجاد یک میکروسرویس را به یک کلیک کاهش دادیم - ادامه مطلب. همه چیزهایی که در زیر می نویسم به طور کامل در Avito پیاده سازی نشده است، برخی از آنها نحوه توسعه پلت فرم خود است.

(و در پایان این مقاله، در مورد فرصت شرکت در یک سمینار سه روزه از متخصص معماری میکروسرویس کریس ریچاردسون صحبت خواهم کرد).

چگونه به میکروسرویس ها رسیدیم

Avito یکی از بزرگترین سایت های طبقه بندی شده در جهان است که روزانه بیش از 15 میلیون آگهی جدید در آن منتشر می شود. باطن ما بیش از 20 هزار درخواست در ثانیه را می پذیرد. ما در حال حاضر چند صد میکروسرویس داریم.

ما چندین سال است که در حال ساخت یک معماری میکروسرویس هستیم. دقیقا چگونه - همکاران ما در جزئیات گفت در بخش ما در RIT++ 2017. در CodeFest 2017 (نگاه کنید به. تصویریسرگئی اورلوف و میخائیل پروکوپچوک به تفصیل توضیح دادند که چرا ما به انتقال به میکروسرویس ها نیاز داشتیم و Kubernetes چه نقشی در اینجا ایفا کرد. خوب، اکنون ما هر کاری انجام می دهیم تا هزینه های مقیاس بندی را که ذاتی چنین معماری است به حداقل برسانیم.

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

اکنون در ابزار PaaS CLI، یک سرویس جدید با یک دستور ایجاد می شود و یک پایگاه داده جدید با دو دستور دیگر اضافه می شود و در Stage مستقر می شود.

چگونه بر دوران "تجزیه سرویس های میکرو" غلبه کنیم

با معماری یکپارچه، به خاطر ثبات تغییرات در محصول، توسعه دهندگان مجبور شدند بفهمند که با همسایگانشان چه می گذرد. هنگام کار بر روی معماری جدید، زمینه های خدمات دیگر به یکدیگر وابسته نیستند.

علاوه بر این، برای اینکه یک معماری میکروسرویس موثر باشد، فرآیندهای زیادی باید ایجاد شود، از جمله:

• ورود به سیستم.
• ردیابی درخواست (Jaeger);
• تجمع خطا (Sentry);
• وضعیت ها، پیام ها، رویدادها از Kubernetes (پردازش جریان رویداد).
• محدودیت مسابقه / قطع کننده مدار (می توانید از Hystrix استفاده کنید).
• کنترل اتصال سرویس (ما از Netramesh استفاده می کنیم).
• نظارت (Grafana);
• مونتاژ (TeamCity);
• ارتباط و اطلاع رسانی (Slack، ایمیل).
• ردیابی کار. (جیرا)
• تهیه اسناد.

برای اطمینان از اینکه سیستم یکپارچگی خود را از دست نمی‌دهد و همچنان که مقیاس می‌شود مؤثر باقی می‌ماند، سازمان‌دهی میکروسرویس‌ها را در Avito دوباره بررسی کردیم.

چگونه میکروسرویس ها را مدیریت می کنیم

موارد زیر به اجرای یک «سیاست حزبی» واحد در میان بسیاری از میکروسرویس‌های Avito کمک می‌کند:

• تقسیم زیرساخت به لایه ها؛
• مفهوم پلتفرم به عنوان یک سرویس (PaaS)؛
• نظارت بر همه چیزهایی که با میکروسرویس ها اتفاق می افتد.

لایه های انتزاعی زیرساخت شامل سه لایه است. از بالا به پایین برویم.

الف. مش سرویس بالا. در ابتدا ما ایستیو را امتحان کردیم، اما معلوم شد که از منابع زیادی استفاده می کند، که برای حجم های ما بسیار گران است. بنابراین، مهندس ارشد در تیم معماری الکساندر لوکیانچنکو راه حل خود را توسعه داد - نترامش (موجود در منبع باز)، که ما در حال حاضر در تولید از آن استفاده می کنیم و چندین برابر کمتر از ایستیو منابع مصرف می کند (اما هر کاری را که ایستیو می تواند به آن ببالد انجام نمی دهد).
B. متوسط ​​- Kubernetes. ما میکروسرویس ها را بر روی آن مستقر و اجرا می کنیم.
ج. پایین - فلز لخت. ما از ابرها یا چیزهایی مانند OpenStack استفاده نمی‌کنیم، اما کاملاً به فلز خالی متکی هستیم.

همه لایه ها توسط PaaS ترکیب شده اند. و این پلت فرم به نوبه خود از سه قسمت تشکیل شده است.

I. ژنراتورها، از طریق یک ابزار CLI کنترل می شود. این اوست که به توسعه دهنده کمک می کند تا یک میکروسرویس را به روش صحیح و با حداقل تلاش ایجاد کند.

II. کلکتور تلفیقی با کنترل تمام ابزارها از طریق یک داشبورد مشترک.

III. ذخیره سازی. با زمان‌بندی‌هایی که به‌طور خودکار محرک‌هایی را برای اقدامات مهم تنظیم می‌کنند، متصل می‌شود. به لطف چنین سیستمی، تنها به این دلیل که شخصی فراموش کرده است که یک وظیفه را در Jira تنظیم کند، هیچ وظیفه ای از دست نمی رود. برای این کار از یک ابزار داخلی به نام Atlas استفاده می کنیم.

اجرای میکروسرویس ها در Avito نیز طبق یک طرح واحد انجام می شود که کنترل آنها را در هر مرحله از توسعه و انتشار ساده می کند.

خط لوله توسعه میکروسرویس استاندارد چگونه کار می کند؟

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

CLI-push ← ادغام مداوم ← پخت ← استقرار ← آزمایشات مصنوعی ← آزمایشات قناری ← تست فشار ← تولید ← تعمیر و نگهداری.

بیایید دقیقاً به این ترتیب آن را مرور کنیم.

CLI-push

• ایجاد یک میکروسرویس.
ما برای مدت طولانی تلاش کردیم تا به هر توسعه‌دهنده‌ای بیاموزیم که چگونه میکروسرویس را انجام دهد. این شامل نوشتن دستورالعمل های دقیق در Confluence بود. اما طرح ها تغییر کردند و تکمیل شدند. نتیجه این است که در ابتدای سفر یک گلوگاه ظاهر شد: راه‌اندازی میکروسرویس‌ها زمان بسیار بیشتری می‌برد، و همچنان مشکلاتی اغلب در حین ایجاد آنها به وجود می‌آمد.

در پایان، ما یک ابزار ساده CLI ساختیم که مراحل اولیه را هنگام ایجاد یک میکروسرویس خودکار می‌کند. در واقع جایگزین فشار git اول می شود. در اینجا دقیقاً چه کاری انجام می دهد.

- یک سرویس را طبق یک الگو ایجاد می کند - مرحله به مرحله، در حالت "جادوگر". ما قالب هایی برای زبان های برنامه نویسی اصلی در Avito Backend داریم: PHP، Golang و Python.

- یک فرمان در یک زمان یک محیط را برای توسعه محلی روی یک ماشین خاص مستقر می کند - Minikube راه اندازی می شود، نمودارهای Helm به طور خودکار در kubernetes محلی تولید و راه اندازی می شوند.

- پایگاه داده مورد نیاز را متصل می کند. توسعه‌دهنده نیازی به دانستن IP، لاگین و رمز عبور برای دسترسی به پایگاه داده مورد نیاز خود ندارد - چه محلی، چه در مرحله یا در حال تولید. علاوه بر این، پایگاه داده بلافاصله در یک پیکربندی مقاوم در برابر خطا و با تعادل مستقر می شود.

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

- تست های خودکار تولید می کند. به شکل جاهای خالی، اما برای استفاده کاملاً مناسب است.

• استقرار میکروسرویس.

استقرار یک میکروسرویس قبلا برای ما کمی سخت بود. موارد زیر مورد نیاز بود:

I. Dockerfile.

II. پیکربندی
III. نمودار هلم که خود دست و پا گیر است و شامل موارد زیر است:

- خود نمودارها؛
- الگوها؛
- مقادیر خاص با در نظر گرفتن محیط های مختلف.

ما درد ناشی از بازسازی مانیفست‌های Kubernetes را از بین برده‌ایم، بنابراین آنها اکنون به طور خودکار تولید می‌شوند. اما مهمتر از همه، آنها استقرار را تا حد زیادی ساده کردند. از این به بعد ما یک Dockerfile داریم و توسعه دهنده کل پیکربندی را در یک فایل کوتاه app.toml می نویسد.

بله، و در خود app.toml برای یک دقیقه کاری برای انجام دادن وجود ندارد. ما مشخص می‌کنیم که کجا و چند نسخه از این سرویس (در سرور توسعه‌دهنده، در مرحله‌بندی، در مرحله تولید) تولید شود، و وابستگی‌های آن را نشان می‌دهیم. به اندازه خط = "small" در بلوک [موتور] توجه کنید. این محدودیتی است که از طریق Kubernetes به سرویس اختصاص داده می شود.

سپس بر اساس کانفیگ، تمام نمودارهای Helm لازم به صورت خودکار تولید شده و اتصالات به پایگاه های داده ایجاد می شود.

• اعتبار سنجی پایه. چنین چک هایی نیز خودکار هستند.
نیاز به پیگیری:
- آیا Dockerfile وجود دارد.
- آیا app.toml وجود دارد.
- آیا اسناد موجود است؟
- آیا وابستگی درست است؟
- آیا قوانین هشدار تنظیم شده است یا خیر.
تا آخرین نکته: صاحب سرویس خودش تعیین می کند که کدام معیارهای محصول را نظارت کند.

• تهیه مستندات.
هنوز یک منطقه مشکل ساز به نظر می رسد واضح ترین باشد، اما در عین حال رکوردی است که "اغلب فراموش می شود" و بنابراین یک حلقه آسیب پذیر در زنجیره است.
لازم است برای هر میکروسرویس مستنداتی وجود داشته باشد. این شامل بلوک های زیر است.

I. شرح مختصری از خدمات. به معنای واقعی کلمه چند جمله در مورد آنچه که انجام می دهد و چرا به آن نیاز است.

II. لینک نمودار معماری. مهم است که با یک نگاه سریع به آن، به راحتی می توان فهمید که آیا از Redis برای ذخیره سازی در حافظه پنهان استفاده می کنید یا به عنوان ذخیره اصلی داده در حالت مداوم. در Avito در حال حاضر این یک پیوند به Confluence است.

III. ران بوک. راهنمای کوتاهی در مورد شروع سرویس و پیچیدگی های رسیدگی به آن.

IV. سوالات متداول، جایی که خوب است مشکلاتی را که همکاران شما ممکن است در هنگام کار با سرویس با آن مواجه شوند، پیش بینی کنید.

V. شرح نقاط پایانی برای API. اگر به طور ناگهانی مقصد را مشخص نکردید، همکارانی که ریزسرویس‌های آنها با شما مرتبط است تقریباً به طور قطع هزینه آن را پرداخت خواهند کرد. اکنون ما از Swagger و راه حل خود به نام brief برای این کار استفاده می کنیم.

VI. برچسب ها. یا نشانگرهایی که نشان می دهند خدمات متعلق به کدام محصول، عملکرد یا بخش ساختاری شرکت است. آنها به شما کمک می کنند تا به سرعت بفهمید، برای مثال، آیا در حال کاهش عملکردی هستید که همکارانتان یک هفته پیش برای همان واحد تجاری ارائه کردند یا خیر.

VII. مالک یا صاحبان سرویس. در بیشتر موارد، آن - یا آنها - را می‌توان به‌طور خودکار با استفاده از PaaS تعیین کرد، اما برای اطمینان از امنیت، از توسعه‌دهنده می‌خواهیم که آنها را به‌صورت دستی مشخص کند.

در نهایت، بررسی مستندات، مشابه بررسی کد، تمرین خوبی است.

ادغام مداوم

• آماده سازی مخازن
• ایجاد خط لوله در TeamCity.
• تنظیم حقوق
• جستجو برای صاحبان خدمات در اینجا یک طرح ترکیبی وجود دارد - علامت گذاری دستی و حداقل اتوماسیون از PaaS. زمانی که سرویس‌ها برای پشتیبانی به تیم توسعه دیگری منتقل می‌شوند یا برای مثال، اگر توسعه‌دهنده خدمات را ترک کند، یک طرح کاملاً خودکار با شکست مواجه می‌شود.
• ثبت خدمات در اطلس (بالا را ببین). با تمام صاحبان و وابستگی هایش.
• بررسی مهاجرت ها ما بررسی می کنیم که آیا هر یک از آنها به طور بالقوه خطرناک هستند یا خیر. به عنوان مثال، در یکی از آنها یک جدول تغییر یا چیز دیگری ظاهر می شود که می تواند سازگاری طرح داده بین نسخه های مختلف سرویس را از بین ببرد. سپس انتقال انجام نمی‌شود، بلکه در یک اشتراک قرار می‌گیرد - PaaS باید زمانی که استفاده از آن ایمن است به مالک سرویس سیگنال دهد.

پخت

مرحله بعدی خدمات بسته بندی قبل از استقرار است.

• ساخت اپلیکیشن طبق کلاسیک ها - در یک تصویر داکر.
• تولید نمودارهای Helm برای خود سرویس و منابع مرتبط. از جمله برای پایگاه داده و حافظه پنهان. آنها به طور خودکار مطابق با پیکربندی app.toml که در مرحله CLI-push ایجاد شده است ایجاد می شوند.
• ایجاد بلیط برای ادمین ها برای باز کردن پورت ها (وقتی لازم باشه).
• اجرای تست های واحد و محاسبه پوشش کد. اگر پوشش کد زیر آستانه مشخص شده باشد، به احتمال زیاد سرویس بیشتر نخواهد رفت - تا استقرار. اگر در آستانه قابل قبول باشد، به سرویس یک ضریب "بدبین کننده" اختصاص داده می شود: سپس، اگر در طول زمان بهبودی در شاخص ایجاد نشود، توسعه دهنده اخطاری مبنی بر عدم پیشرفت از نظر آزمایش ها دریافت می کند ( و باید کاری برای آن انجام شود).
• در نظر گرفتن محدودیت های حافظه و CPU. ما عمدتا میکروسرویس ها را در Golang می نویسیم و آنها را در Kubernetes اجرا می کنیم. از این رو یک نکته ظریف مربوط به ویژگی های زبان Golang است: به طور پیش فرض، هنگام راه اندازی، از تمام هسته های دستگاه استفاده می شود، اگر به صراحت متغیر GOMAXPROCS را تنظیم نکنید، و هنگامی که چندین سرویس از این قبیل در یک دستگاه راه اندازی می شوند، شروع می شوند. برای رقابت برای منابع، تداخل با یکدیگر. نمودارهای زیر نشان می دهد که اگر برنامه را بدون اختلاف و در حالت رقابت برای منابع اجرا کنید، زمان اجرا چگونه تغییر می کند. (منابع نمودارها هستند اینجا).

زمان اجرا، کمتر بهتر است. حداکثر: 643 میلی‌ثانیه، حداقل: 42 میلی‌ثانیه. عکس قابل کلیک است.

زمان برای جراحی، کمتر بهتر است. حداکثر: 14091 ns، حداقل: 151 ns. عکس قابل کلیک است.

در مرحله آماده سازی اسمبلی، می توانید این متغیر را به صراحت تنظیم کنید یا می توانید از کتابخانه استفاده کنید automaxprocs از بچه های اوبر.

مستقر کنید

• بررسی قراردادها. قبل از شروع تحویل مجموعه های خدماتی به محیط های مورد نظر خود، باید موارد زیر را بررسی کنید:
- نقاط پایانی API.
- انطباق پاسخ های نقاط انتهایی API با طرح.
- فرمت گزارش
- تنظیم هدر برای درخواست های سرویس (در حال حاضر این کار توسط نترامش انجام می شود)
- تنظیم نشانه مالک هنگام ارسال پیام به اتوبوس رویداد. این برای ردیابی اتصال خدمات در سراسر اتوبوس مورد نیاز است. شما می توانید هم داده های idempotent را به اتوبوس ارسال کنید که اتصال سرویس ها را افزایش نمی دهد (که خوب است) و هم داده های تجاری که اتصال سرویس ها را تقویت می کند (که بسیار بد است!). و در نقطه ای که این اتصال به یک مسئله تبدیل می شود، درک اینکه چه کسی اتوبوس را می نویسد و می خواند به جداسازی صحیح سرویس ها کمک می کند.

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

تست های مصنوعی

• تست حلقه بسته. برای این منظور ما اکنون از منبع باز استفاده می کنیم Hoverfly.io. ابتدا بار واقعی سرویس را ثبت می کند، سپس - فقط در یک حلقه بسته - آن را شبیه سازی می کند.

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

در طول آزمایش بار، بررسی می کنیم که آیا مصرف منابع با محدودیت های تعیین شده مطابقت دارد یا خیر. و ما در درجه اول بر روی افراط تمرکز می کنیم.

الف) ما به کل بار نگاه می کنیم.
- خیلی کوچک - به احتمال زیاد اگر بار به طور ناگهانی چندین بار کاهش یابد، چیزی اصلا کار نمی کند.
- خیلی بزرگ - بهینه سازی مورد نیاز است.

ب) بر اساس RPS به برش نگاه می کنیم.
در اینجا به تفاوت نسخه فعلی با نسخه قبلی و تعداد کل نگاه می کنیم. به عنوان مثال، اگر یک سرویس 100 rps تولید کند، یا ضعیف نوشته شده است، یا این ویژگی آن است، اما در هر صورت، این دلیلی است که به سرویس بسیار دقیق نگاه کنید.
اگر برعکس، RPS بیش از حد وجود داشته باشد، ممکن است نوعی باگ وجود داشته باشد و برخی از نقاط پایانی اجرای payload را متوقف کرده باشند، و برخی دیگر به سادگی فعال شوند. return true;

آزمایشات قناری

پس از گذراندن تست های مصنوعی، میکروسرویس را روی تعداد کمی از کاربران آزمایش می کنیم. ما با دقت شروع می کنیم، با سهم کمی از مخاطبان مورد نظر سرویس - کمتر از 0,1٪. در این مرحله بسیار مهم است که معیارهای فنی و محصول صحیح در نظارت لحاظ شود تا در سریع ترین زمان ممکن مشکل را در سرویس نشان دهد. حداقل زمان برای آزمایش قناری 5 دقیقه و اصلی آن 2 ساعت است. برای خدمات پیچیده، زمان را به صورت دستی تنظیم می کنیم.
ما تجزیه و تحلیل می کنیم:
- معیارهای خاص زبان، به ویژه کارگران php-fpm؛
- خطاهای Sentry؛
- وضعیت پاسخ؛
- زمان پاسخگویی، دقیق و متوسط؛
- تاخیر؛
- استثنائات، پردازش شده و کنترل نشده؛
- معیارهای محصول

تست فشار

تست فشار همچنین تست "فشرده" نامیده می شود. نام این تکنیک در نتفلیکس معرفی شد. ماهیت آن این است که ابتدا یک نمونه را با ترافیک واقعی تا نقطه شکست پر می کنیم و بنابراین حد آن را تعیین می کنیم. سپس یک نمونه دیگر اضافه می کنیم و این جفت را بارگذاری می کنیم - دوباره به حداکثر. سقف و دلتای آنها را با اولین "فشردن" می بینیم. و بنابراین ما یک نمونه را در یک زمان به هم متصل می کنیم و الگوی تغییرات را محاسبه می کنیم.
داده‌های آزمایشی از طریق «فشرده کردن» نیز به یک پایگاه داده معیارهای رایج جریان می‌یابند، جایی که ما یا نتایج بار مصنوعی را با آنها غنی می‌کنیم، یا حتی «مصنوعی» را با آنها جایگزین می‌کنیم.

تولید

• پوسته پوسته شدن. هنگامی که ما یک سرویس را برای تولید عرضه می کنیم، بر نحوه مقیاس آن نظارت می کنیم. در تجربه ما، نظارت تنها نشانگرهای CPU بی اثر است. مقیاس‌بندی خودکار با معیار RPS به شکل خالص آن کار می‌کند، اما فقط برای برخی خدمات، مانند پخش آنلاین. بنابراین ابتدا به معیارهای محصول خاص برنامه نگاه می کنیم.

در نتیجه، هنگام مقیاس بندی، تجزیه و تحلیل می کنیم:
- نشانگرهای CPU و RAM
- تعداد درخواست های موجود در صف،
- زمان پاسخ،
- پیش بینی بر اساس داده های تاریخی انباشته شده.

هنگام مقیاس‌بندی یک سرویس، نظارت بر وابستگی‌های آن نیز مهم است تا اولین سرویس در زنجیره را مقیاس‌بندی نکنیم و سرویس‌هایی که به آن دسترسی پیدا می‌کند تحت بار شکست بخورند. برای ایجاد بار قابل قبول برای کل مجموعه خدمات، به داده‌های تاریخی «نزدیک‌ترین» سرویس وابسته (بر اساس ترکیبی از شاخص‌های CPU و RAM، همراه با معیارهای خاص برنامه) نگاه می‌کنیم و آنها را با داده‌های تاریخی مقایسه می‌کنیم. سرویس اولیه، و غیره در سراسر "زنجیره وابستگی" "، از بالا به پایین.

خدمات

پس از راه اندازی میکروسرویس، می توانیم ماشه ها را به آن وصل کنیم.

در اینجا موقعیت های معمولی وجود دارد که در آنها محرک رخ می دهد.
- مهاجرت های بالقوه خطرناک شناسایی شده است.
- به روز رسانی های امنیتی منتشر شده است.
— خود سرویس مدت زیادی است که به روز نشده است.
- بار روی سرویس به طور قابل توجهی کاهش یافته است یا برخی از معیارهای محصول آن خارج از محدوده طبیعی است.
— این سرویس دیگر الزامات پلتفرم جدید را برآورده نمی کند.

برخی از ماشه ها مسئول پایداری عملکرد هستند، برخی - به عنوان تابعی از نگهداری سیستم - به عنوان مثال، برخی از سرویس ها برای مدت طولانی مستقر نشده اند و تصویر پایه آن از بررسی های امنیتی بازمانده است.

داشبورد

به طور خلاصه، داشبورد کنترل پنل کل PaaS ما است.

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

در کل

قبل از معرفی PaaS، یک توسعه‌دهنده جدید می‌تواند چندین هفته وقت بگذارد تا تمام ابزارهای لازم برای راه‌اندازی یک میکروسرویس در تولید را بشناسد: Kubernetes، Helm، ویژگی‌های داخلی TeamCity، راه‌اندازی اتصالات به پایگاه‌های داده و حافظه‌های پنهان به روشی مقاوم در برابر خطا، و غیره. خواندن سریع شروع و ایجاد خود سرویس چند ساعت طول می کشد.

من گزارشی در مورد این موضوع برای HighLoad++ 2018 دادم، می توانید آن را تماشا کنید تصویری и ارائه.

آهنگ جایزه برای کسانی که تا آخر می خوانند

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

این آموزش از 5 تا 7 آگوست در مسکو برگزار می شود. این روزهای کاری است که به طور کامل اشغال خواهد شد. ناهار و آموزش در دفتر ما خواهد بود و شرکت کننده منتخب هزینه سفر و اقامت خود را پرداخت خواهد کرد.

می توانید برای شرکت اقدام کنید در این فرم گوگل. از شما - پاسخ به این سوال که چرا باید در آموزش شرکت کنید و اطلاعاتی در مورد نحوه تماس با شما. به زبان انگلیسی پاسخ دهید، زیرا کریس شرکت کننده ای را که خودش در آموزش شرکت خواهد کرد انتخاب می کند.
نام شرکت کننده آموزشی را در به روز رسانی این پست و در شبکه های اجتماعی Avito برای توسعه دهندگان اعلام خواهیم کرد (AvitoTech in Фейсбуке, Vkontakte, توییتر) حداکثر تا 19 جولای.

منبع: www.habr.com