از monoliths تا microservices: تجربه M.Video-Eldorado و MegaFon

در 25 آوریل، ما در گروه Mail.ru کنفرانسی در مورد ابرها و اطراف برگزار کردیم - mailto: CLOUD. چند نکته برجسته:

• اصلی ارائه دهندگان روسی — Mail.ru Cloud Solutions، #CloudMTS، SberCloud، Selectel، Rostelecom Data Center و Yandex.Cloud در مورد مشخصات بازار ابری ما و خدمات آنها صحبت کردند.
• همکاران Bitrix24 گفتند که چگونه آنها به چند ابری رسید;
• Leroy Merlin، Otkritie، Burger King و Schneider Electric جالب توجه بودند نمای از مصرف کنندگان ابر - کسب و کار آنها چه وظایفی را برای فناوری اطلاعات تعیین می کند و چه فناوری هایی از جمله فناوری های ابری را امیدوارکننده ترین می دانند.

می‌توانید همه ویدیوها را از کنفرانس mailto:CLOUD تماشا کنید по ссылке، و در اینجا می توانید بخوانید که چگونه بحث در مورد میکروسرویس ها پیش رفت. الکساندر دولین، رئیس مرکز تحقیق و توسعه سیستم های تجاری MegaFon، و سرگئی سرگیف، مدیر فناوری اطلاعات گروه M.Video-Eldorado، موارد موفق خود را در خلاص شدن از شر یکپارچه ها به اشتراک گذاشتند. ما همچنین در مورد موضوعات مرتبط با استراتژی فناوری اطلاعات، فرآیندها و حتی منابع انسانی بحث کردیم.

اعضای پانل

• سرگئی سرگئیف، CIO گروه "M.Video-Eldorado";
• الکساندر دولین، رئیس مرکز تحقیق و توسعه سیستم های کسب و کار مگافون;
• مجری - دیمیتری لازارنکو، رئیس بخش PaaS Mail.ru Cloud Solutions.

پس از سخنرانی الکساندر دولین "چگونه مگافون تجارت خود را از طریق یک پلت فرم میکروسرویس گسترش می دهد" سرگئی سرگئیف از M.Video-Eldorado و مدیر بحث دیمیتری لازارنکو، Mail.ru Cloud Solutions به او پیوسته است.

در زیر متن این بحث را برای شما آماده کرده ایم، اما می توانید ویدیو را نیز تماشا کنید:

انتقال به ریزخدمات پاسخی به نیازهای بازار است

دیمیتری:

آیا تجربه موفقی در مهاجرت به میکروسرویس ها داشته اید؟ و به طور کلی: بیشترین سود تجاری را از استفاده از میکروسرویس ها یا حرکت از یکپارچه به میکروسرویس ها در کجا می بینید؟

سرگئی:

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

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

یکی از اولین خدمات که پر بارترین آن بود، خدمات محاسبه قیمت بود. هر بار که به هر کانالی می‌آیید، به گروه شرکت‌های M.Video-Eldorado، چه یک وب‌سایت یا یک فروشگاه خرده‌فروشی، محصولی را در آنجا انتخاب کنید، قیمت را در وب‌سایت یا در «سبد» ببینید، هزینه به‌طور خودکار محاسبه می‌شود. توسط یک سرویس محاسبه می شود. چرا این امر ضروری است: قبل از این، هر سیستم اصول خود را برای کار با تبلیغات - با تخفیف و غیره داشت. دفتر پشتی ما قیمت گذاری را انجام می دهد؛ عملکرد تخفیف در سیستم دیگری پیاده سازی می شود. این باید متمرکز می شد و یک سرویس منحصر به فرد و قابل تفکیک در قالب یک فرآیند تجاری ایجاد می شد که به ما امکان می داد این را پیاده سازی کنیم. تقریباً اینگونه شروع کردیم.

ارزش اولین نتایج بسیار زیاد بود. اولاً، ما توانستیم موجودیت‌های قابل تفکیک ایجاد کنیم که به ما امکان می‌دهد به طور جداگانه و به صورت انبوه کار کنیم. ثانیاً، ما هزینه مالکیت را از نظر ادغام با سیستم های بیشتر کاهش داده ایم.

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

چگونه موفقیت مهاجرت به میکروسرویس ها را اندازه گیری کنیم

دیمیتری:

موفقیت در مهاجرت به میکروسرویس ها چگونه تعیین می شود؟ "قبل" در هر شرکت چه بود؟ از چه معیاری برای تعیین موفقیت این انتقال استفاده کردید، و در واقع چه کسی آن را تعیین کرد؟

سرگئی:

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

اسکندر:

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

سرگئی:

بله موافقم. در سه سال، ما در حال حاضر بیش از دویست خدمات و عقب ماندگی داریم. نیاز به منابع در تیم فقط در حال افزایش است - سالانه 30٪. این اتفاق می افتد زیرا مردم احساس می کردند: سریع تر است، متفاوت است، فن آوری های مختلفی وجود دارد، همه اینها در حال توسعه است.

میکروسرویس ها خواهند آمد، اما هسته اصلی باقی خواهد ماند

دیمیتری:

این مانند یک فرآیند بی پایان است که در آن روی توسعه سرمایه گذاری می کنید. آیا انتقال به خدمات ریز برای تجارت در حال حاضر تمام شده است یا خیر؟

سرگئی:

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

اما ما نمی توانیم همه چیز را به یکباره پوشش دهیم و دوباره انجام دهیم. ما خدمات یکپارچه سازی قدیمی و استانداردی داریم که قبلاً وجود داشت: اتوبوس های سازمانی و غیره. اما عقب ماندگی وجود دارد و نیاز نیز وجود دارد. تعداد اپلیکیشن های موبایل و عملکرد آنها در حال افزایش است. در عین حال هیچکس نمی گوید که 30 درصد بیشتر به شما پول می دهند. یعنی همیشه از یک طرف نیازها و از طرف دیگر جست و جوی کارایی وجود دارد.

دیمیتری:

زندگی در وضعیت خوبی است. (می خندد)

اسکندر:

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

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

نحوه فروش میکروسرویس به مشاغل

دیمیتری:

من همچنین علاقه مند هستم - برای کسانی که تغییر نداده اند، اما قصد دارند: فروش این ایده به تجارت چقدر آسان بود و آیا این یک ماجراجویی، یک پروژه سرمایه گذاری بود؟ یا این یک استراتژی آگاهانه بود: اکنون ما به سمت خدمات میکرو می رویم و تمام است، هیچ چیز ما را متوقف نخواهد کرد. برای تو چطور بود؟

سرگئی:

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

دیمیتری:

زمان مرحله اول را به نوعی ثبت کردید؟

سرگئی:

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

در مرحله بعدی کار سیستماتیک بر اساس نیازهای تجاری، فرصت ها، در دسترس بودن منابع و هر چیزی که در حال حاضر در حال انجام است می آید.

دیمیتری:

خوب. الکساندر چی میگی؟

اسکندر:

ریزسرویس‌های ما از "کف دریا" متولد شدند - به دلیل صرفه جویی در منابع، به دلیل مقداری باقیمانده در قالب ظرفیت سرور و توزیع مجدد نیروها در تیم. در ابتدا، ما این پروژه را به تجارت نفروختیم. این پروژه ای بود که در آن هر دو تحقیق و توسعه کردیم. ما از ابتدای سال 2018 شروع کردیم و به سادگی این مسیر را با اشتیاق توسعه دادیم. فروش به تازگی شروع شده است و ما در حال انجام هستیم.

دیمیتری:

آیا این اتفاق می‌افتد که یک کسب‌وکار به شما اجازه می‌دهد کارهایی مانند Google را در یک روز رایگان در هفته انجام دهید؟ آیا شما چنین جهتی دارید؟

اسکندر:

همزمان با تحقیق، ما به مشکلات تجاری نیز پرداختیم، بنابراین همه خدمات خرد ما راه حلی برای مشکلات تجاری هستند. فقط در ابتدا ما میکروسرویس هایی ساختیم که بخش کوچکی از پایگاه مشترکین را پوشش می داد و اکنون تقریباً در همه محصولات شاخص حضور داریم.

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

خدمات میکرو: تبلیغات یا ضرورت؟

دیمیتری:

اعداد اعداد هستند. و درآمد یا پول ذخیره شده بسیار مهم است. اگر به طرف مقابل نگاه کنید چه؟ به نظر می رسد میکروسرویس ها یک روند، یک هیاهو هستند و بسیاری از شرکت ها از آن سوء استفاده می کنند؟ چقدر واضح بین کارهایی که انجام می‌دهید و کارهایی که به میکروسرویس‌ها ترجمه نمی‌کنید، تفاوت قائل می‌شوید؟ اگر میراث در حال حاضر، آیا شما هنوز هم میراث در 5 سال؟ سن سیستم های اطلاعاتی که در M.Video-Eldorado و MegaFon کار می کنند تا 5 سال دیگر چقدر خواهد بود؟ آیا سیستم های اطلاعاتی ده ساله، پانزده ساله وجود خواهد داشت یا نسل جدیدی خواهد بود؟ این را چگونه می بینید؟

سرگئی:

به نظر من فکر کردن خیلی دور سخت است. اگر به گذشته نگاه کنیم، چه کسی تصور می کرد که بازار فناوری از جمله یادگیری ماشینی و شناسایی کاربر از طریق چهره به این شکل توسعه یابد؟ اما اگر به سال های آینده نگاه کنید، به نظر من سیستم های اصلی، سیستم های کلاس ERP سازمانی در شرکت ها - آنها برای مدت طولانی کار می کنند.

شرکت‌های ما در مجموع ۲۵ سال قدمت دارند و ERP کلاسیک در چشم‌انداز سیستم‌ها بسیار عمیق است. واضح است که ما برخی از قطعات را از آنجا بیرون می آوریم و سعی می کنیم آنها را در میکروسرویس ها جمع آوری کنیم، اما هسته اصلی باقی خواهد ماند. اکنون برای من سخت است تصور کنم که همه سیستم های اصلی را در آنجا جایگزین کنیم و به سرعت به سمت دیگر و روشن سیستم های جدید برویم.

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

ما شاهد این توسعه هستیم:

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

اما در عین حال من طرفدار ادامه استفاده از اصول قدیمی در صورت استفاده مناسب هستم.

فرض کنید شما یک سیستم سازمانی کلاسیک دارید. در چشم انداز یک فروشنده قرار دارد و از دو ماژول تشکیل شده است که با یکدیگر کار می کنند. همچنین یک رابط ادغام استاندارد وجود دارد. چرا آن را دوباره انجام دهید و یک میکروسرویس به آنجا بیاورید؟

اما زمانی که 5 ماژول در دفتر پشتی وجود داشته باشد، که از آنها قطعات اطلاعات در یک فرآیند تجاری جمع آوری می شود، که سپس توسط 8-10 سیستم خط مقدم استفاده می شود، فوراً مزیت آن قابل توجه است. شما از پنج سیستم پشتیبان استفاده می‌کنید و یک سرویس مجزا ایجاد می‌کنید که بر فرآیند کسب‌وکار متمرکز است. سرویس را از نظر فناوری پیشرفته کنید - به طوری که اطلاعات را در حافظه پنهان ذخیره می کند و عیب را تحمل می کند و همچنین با اسناد یا نهادهای تجاری کار می کند. و شما آن را طبق یک اصل واحد با تمام محصولات خط مقدم ادغام می کنید. آنها محصول خط مقدم را لغو کردند - آنها به سادگی ادغام را خاموش کردند. فردا باید یک برنامه موبایل بنویسید یا یک وب سایت کوچک بسازید و فقط یک قسمت را در عملکرد قرار دهید - همه چیز ساده است: شما آن را مانند یک سازنده مونتاژ کردید. من توسعه بیشتری را در این راستا می بینم - حداقل در کشور ما.

اسکندر:

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

دیمیتری:

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

نحوه توسعه میکروسرویس های قابل اعتماد

دیمیتری:

خوب. اما من همچنان علاقه مند هستم. اکنون شما یک داستان موفقیت آمیز را تعریف می کنید: همه چیز خوب بود، ما به میکروسرویس ها روی آوردیم، از ایده برای کسب و کار دفاع کردیم و همه چیز درست شد. اما من داستان های دیگری شنیده ام.

چند سال پیش، یک شرکت سوئیسی که دو سال برای توسعه یک پلتفرم میکروسرویس جدید برای بانک‌ها سرمایه‌گذاری کرده بود، در نهایت پروژه را تعطیل کرد. کاملا فرو ریخت. میلیون ها فرانک سوئیس خرج شد و در پایان تیم پراکنده شد - نتیجه ای نداشت.

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

اسکندر:

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

ما هیچ گونه شکست جهانی با میکروسرویس ها نداشتیم. ما آرام می خوابیم، یک شیفت کاری 24 ساعته داریم که به کل BSS [سیستم پشتیبانی کسب و کار] خدمات می دهد.

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

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

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

میکروسرویس ها و منابع انسانی

سرگئی:

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

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

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

مشکل دیگر - اگرچه این در نوع خود خوب است - رقابت داخلی است. "اوه، مردان شیک جدید اینجا ظاهر شده اند، آنها به یک زبان جدید صحبت می کنند." البته مردم با هم فرق دارند. کسانی هستند که به نوشتن در جاوا عادت دارند و کسانی که Docker و Kubernetes می نویسند و استفاده می کنند. اینها افراد کاملاً متفاوتی هستند، آنها متفاوت صحبت می کنند، از اصطلاحات مختلف استفاده می کنند و گاهی اوقات یکدیگر را درک نمی کنند. توانایی یا ناتوانی در به اشتراک گذاشتن تمرین، به اشتراک گذاری دانش، به این معنا نیز یک مشکل است.

خوب، مقیاس کردن منابع. "عالیه بریم! و اکنون ما سریعتر و بیشتر می خواهیم. چی، نمیتونی؟ آیا امکان تحویل دو برابر در یک سال وجود ندارد؟ و چرا؟" چنین دردهای رشدی احتمالاً برای بسیاری از چیزها، بسیاری از رویکردها استاندارد هستند و شما می توانید آنها را احساس کنید.

در مورد نظارت به نظر من خدمات یا ابزارهای نظارت صنعتی در حال یادگیری هستند یا می توانند با Docker و Kubernetes در حالتی متفاوت و غیر استاندارد کار کنند. به طوری که، به عنوان مثال، شما با 500 ماشین جاوا مواجه نشوید که همه اینها تحت آن در حال اجرا هستند، یعنی جمع می شوند. اما این محصولات هنوز بلوغ ندارند و باید از این مرحله عبور کنند. موضوع واقعا جدید است، به توسعه ادامه خواهد داد.

دیمیتری:

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

سرگئی:

بله کاملا.

اسکندر:

HR این سوال را می پرسد: "تک شاخ صورتی شما بین پشت و جلو کجاست؟" HR نمی فهمد میکروسرویس چیست. ما راز را به آنها گفتیم و به آنها گفتیم که باطن همه کارها را انجام می دهد و تک شاخ وجود ندارد. اما منابع انسانی در حال تغییر است، به سرعت یاد می‌گیرد و افرادی را به خدمت می‌گیرد که دانش اولیه فناوری اطلاعات را دارند.

تکامل میکروسرویس ها

دیمیتری:

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

سرگئی:

ما قبلاً چندین پروتکل ارتباطی را بازنویسی کرده ایم. ابتدا یک پروتکل وجود داشت، اکنون به پروتکل دیگری تغییر مکان دادیم. ما ایمنی و قابلیت اطمینان را افزایش می دهیم. ما با فناوری های سازمانی - Oracle، Web Logic - شروع کردیم. اکنون ما از محصولات شرکت های فناوری در میکروسرویس ها فاصله می گیریم و به سمت فناوری های متن باز یا کاملاً باز می رویم. ما پایگاه‌های داده را رها می‌کنیم و به سمت آنچه در این مدل برای ما مؤثرتر است، حرکت می‌کنیم. ما دیگر نیازی به فناوری اوراکل نداریم.

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

ایمنی بسیار مهم است. به محض اینکه شروع به در دسترس بودن کردید و سرویسی دارید که از طریق آن می توانید چیزهای جالب زیادی را بدست آورید، و خیلی سریع، در کسری از ثانیه، میل به دریافت آن به نه امن ترین راه وجود دارد. برای دور شدن از این موضوع، مجبور شدیم رویکردهای آزمایش و نظارت را تغییر دهیم. ما مجبور شدیم تیم، ساختار مدیریت تحویل، CI/CD را تغییر دهیم.

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

به طور مکرر، چیزی در سال از نقطه نظر فناوری ارائه می شود، چیز دیگری از نقطه نظر عقب ماندگی و نیازها. ما یک چیز را به چیز دیگر متصل می کنیم. این تیم 20٪ را برای بدهی فنی و پشتیبانی فنی برای تیم، 80٪ را برای نهاد تجاری هزینه می کند. و ما با درک اینکه چرا این کار را انجام می‌دهیم، چرا این پیشرفت‌های فناوری را انجام می‌دهیم، و به چه چیزی منجر می‌شوند، حرکت می‌کنیم. مثل اون.

دیمیتری:

سرد. مگافون چیست؟

اسکندر:

چالش اصلی وقتی به میکروسرویس ها رسیدیم این بود که در هرج و مرج قرار نگیریم. دفتر معماری MegaFon بلافاصله به ما ملحق شد، حتی یک آغازگر و راننده شد - اکنون ما یک معماری بسیار قوی داریم. وظیفه او این بود که بفهمد به چه مدل هدفی می رویم و چه فناوری هایی باید به صورت آزمایشی اجرا شوند. با معماری، ما خودمان این خلبان ها را انجام دادیم.

سوال بعدی این بود: "پس چگونه می توان از همه اینها بهره برداری کرد؟" و یک مورد دیگر: "چگونه از تعامل شفاف بین میکروسرویس ها اطمینان حاصل کنیم؟" مش سرویس به ما کمک کرد تا به آخرین سوال پاسخ دهیم. ایستیو را خلبان کردیم و از نتایج خوشمان آمد. اکنون در مرحله ورود به مناطق تولیدی هستیم. ما نگرش مثبتی نسبت به همه چالش ها داریم - این واقعیت که ما باید دائماً پشته را تغییر دهیم، چیز جدیدی یاد بگیریم. ما به توسعه و نه بهره برداری از راه حل های قدیمی علاقه مندیم.

دیمیتری:

کلمات طلایی! چنین چالش هایی تیم و کسب و کار را سرپا نگه می دارند و آینده را می سازند. GDPR افسران ارشد حفاظت از داده ها را ایجاد کرد و چالش های فعلی باعث ایجاد افسران ارشد میکروسرویس ها و معماری می شود. و خوشحال می شود.

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

با تشکر از همه شرکت کنندگان، با تشکر از سرگئی و اسکندر!

سوالات مخاطبان

سوال از حضار (1):

سرگئی، مدیریت فناوری اطلاعات در شرکت شما چگونه تغییر کرده است؟ من درک می کنم که وقتی یک پشته بزرگ از چندین سیستم وجود دارد، نحوه مدیریت آن یک فرآیند نسبتاً واضح و منطقی است. پس از ادغام تعداد بسیار زیادی از میکروسرویس ها در مدت زمان کوتاه، چگونه مدیریت مؤلفه فناوری اطلاعات را بازسازی کردید؟

سرگئی:

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

اما استاندارد، اصول اولیه توسعه، تجزیه و تحلیل کسب و کار، آزمایش و توسعه لغو نشده است. ما فقط سرعت را اضافه کردیم. پیش از این، این چرخه بسیار طول می کشید، نصب در محیط های آزمایشی بسیار بیشتر طول می کشید. حالا تجارت سود را می بیند و می گوید: "چرا ما نمی توانیم در جاهای دیگر همین کار را انجام دهیم؟"

از نظر خوب، مانند یک تزریق به شکل واکسن است که نشان داد: شما می توانید این کار را به این طریق انجام دهید، اما می توانید آن را به روش دیگری انجام دهید. البته در پرسنل، در شایستگی ها، در دانش، در مقاومت مشکل است.

سوال از حضار (2):

منتقدان معماری میکروسرویس می گویند که آزمایش و توسعه دشوار است. این منطقی است که همه چیز پیچیده می شود. تیم شما با چه چالش هایی روبرو بود و چگونه بر آنها غلبه کردید؟ سوال برای همه

اسکندر:

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

به عنوان مثال، ما در حال ساخت محصولی هستیم که از 5-7 میکروسرویس تشکیل شده است. ما باید تست‌های یکپارچه‌سازی را در کل پشته میکروسرویس‌ها ارائه کنیم تا چراغ سبز حرکت به شعبه اصلی را نشان دهیم. این کار برای ما جدید نبود: ما برای مدت طولانی در BSS این کار را انجام می‌دادیم، زمانی که فروشنده راه‌حل‌هایی را که قبلاً ارسال شده بود به ما ارائه کرد.

و مشکل ما فقط در تیم کوچک است. یک مهندس QA برای یک محصول مشروط مورد نیاز است. و بنابراین، ما یک محصول از 5-7 میکروسرویس را ارسال می کنیم که 2-3 مورد از آنها می تواند توسط اشخاص ثالث توسعه یابد. به عنوان مثال، ما محصولی داریم که فروشنده سیستم صورتحساب ما، Mail.ru Group و MegaFon R&D در توسعه آن مشارکت دارند. ما باید قبل از ارسال آن به تولید، آن را با آزمایشات پوشش دهیم. مهندس QA یک ماه و نیم است که روی این محصول کار می کند و بقیه اعضای تیم بدون حمایت او می مانند.

این پیچیدگی فقط به دلیل مقیاس بندی ایجاد می شود. ما می‌دانیم که ریزسرویس‌ها نمی‌توانند در خلاء وجود داشته باشند؛ انزوا مطلق وجود ندارد. هنگام تغییر یک سرویس، ما همیشه سعی می کنیم قرارداد API را حفظ کنیم. اگر چیزی زیر کاپوت تغییر کند، سرویس جلو باقی می ماند. اگر تغییرات کشنده باشد، نوعی دگرگونی معماری رخ می دهد و ما به یک متامدل داده کاملاً متفاوت می رویم که کاملاً ناسازگار است - فقط در این صورت در مورد ظاهر شدن مشخصات API سرویس v2 صحبت می کنیم. ما نسخه اول و دوم را به طور همزمان پشتیبانی می کنیم و پس از اینکه همه مصرف کنندگان به نسخه دوم رفتند، ما به سادگی نسخه اول را می بندیم.

سرگئی:

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

حفظ عملکرد قبلی مهم است و این هزینه اضافی است. اگر یک فناوری را در پروتکل دیگری بازنویسی کنید، سپس آن را بازنویسی می کنید تا زمانی که همه چیز را به طور کامل ببندید.

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

اسکندر:

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

سوال از حضار (3):

تا آنجا که من متوجه شدم، میکروسرویس ها ابتدا از یک تیم جداگانه رشد کردند و اکنون در این مدل وجود دارند. مزایا و معایب آن چیست؟

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

بر این اساس، عملیات ما نیز به سمت سیستم ها می رود، یعنی این موضوع را غیرمتمرکز می کنیم. رویکرد شما چیست و داستان هدف شما چیست؟

اسکندر:

شما نام «کارخانه میکروسرویس‌ها» را از دهانتان بیرون انداختید - ما نیز می‌خواهیم مقیاس کنیم. اولا ما الان واقعا یک تیم داریم. ما می‌خواهیم به همه تیم‌های توسعه‌ای که MegaFon دارد، فرصت کار در یک اکوسیستم مشترک را ارائه دهیم. ما نمی‌خواهیم تمام قابلیت‌های توسعه‌ای را که در حال حاضر داریم به طور کامل در اختیار بگیریم. وظیفه محلی مقیاس کردن است، وظیفه جهانی هدایت توسعه به همه تیم ها در لایه میکروسرویس است.

سرگئی:

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

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

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

اسکندر:

سرگئی، شما در واقع مالک این فرآیند هستید، درست است؟ آیا کارهای عقب افتاده مشترک است؟ چه کسی مسئول توزیع آن است؟

سرگئی:

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

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

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

پایان بحث، اما نه همه

کنفرانس mailto:CLOUD سازماندهی شد Mail.ru Cloud Solutions.

ما همچنین رویدادهای دیگری را انجام می دهیم - به عنوان مثال. @Kubernetes Meetup، جایی که ما همیشه به دنبال بلندگوهای عالی هستیم:

• @Kubernetes و سایر اخبار Meetup@ را در کانال تلگرام ما دنبال کنید t.me/k8s_mail
• علاقه مند به صحبت در یکی از @Meetups هستید؟ یک درخواست برای mcs.mail.ru/speak

منبع: www.habr.com