[PHP, Анализ и проектирование систем, Микросервисы] Из монолита на микросервисы — меняем архитектуру правильно и безболезненно

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
27-Янв-2021 12:30

Цитировать

Как собрать в прямом эфире 17 000 зрителей? Значит, рецепт такой. Берем 15 актуальных IT-направлений, зовем зарубежных спикеров, дарим подарки за активность в чате, и вуа-ля — крупнейший в Украине и восточной Европе онлайн-ивент готов. Именно так прошла ежегодная мультитул конференция NIXMultiConf.
Под слоганом «айтишникам — от айтишников» эксперты из Украины, Беларуси, России, Великобритании и Германии поделились опытом и рассказали о новинках индустрии. Полезно было всем — дизайнерам, девелоперам, тестировщикам и менеджерам. И теперь делимся инсайтами с вами.
По мотивам докладов экспертов NIX продолжаем серию материал на самые актуальные темы. В новой статье PHP developer Александр Павленко объясняет, на каком этапе разработки стоит перейти на микросервисы и как это сделать с минимальными рисками.
Хочешь знать больше — смотри конференцию на YouTube-канале.
Привет! Я Александр Павленко, разработкой на PHP занимаюсь около четырех лет. Среди крупных проектов — Car Sales Platform + Inventory, Archive of Scientific Documents, Job Search Platform, Natural Disasters Alarm System.
Стоит только заговорить о монолите и микросервисах, как многие начинают холивар вокруг их сравнения. Я считаю, вместо поиска плюсов и минусов, лучше выяснить, какой подход больше всего отвечает бизнес-задачам приложения. Наша команда занималась проектом в сфере FinTech, и он изначально строился на монолите. Почему так сложилось и какие возможности мы увидели в микросервисах — расскажу подробнее.
Стартовать проще с монолитом
Монолит напоминает мне кубик Рубика: если вытащить из него одну деталь, собрать новую форму или добавить другие компоненты, кубик уже не будет полноценно работать. Каждый элемент формирует единый функционал. Если какой-то части не хватает, она сломана или стоит не на месте — цветное поле кубика не сложится.
В условиях стартапа с монолитом удается быстрее запустить проект. Когда, условно через месяц, надо презентовать клиенту MVP, но ни конкретных требований, ни спецификаций по продукту нет, спасает только гибкость монолита. Во-вторых, на старте его легко и быстро масштабировать. Для команды тоже были очевидны преимущества. К разработке на монолите может присоединиться больше специалистов, в том числе новички. В изучении PHP они непременно начинают с монолита. Он прост и понятен в использовании.
Наш стартап стремительно развивался. Росло количество пользователей, клиентов, регулярно добавлялся различный функционал. Спустя время проявились недостатки монолита. То, что было критично для нас:

из-за стремительного роста системы становилось сложнее ее поддерживать и развивать без дополнительных ресурсов. Прежде всего это касалось стоимости внесения новых изменений. Чем дальше мы шли и внедряли новые фичи, тем больше они дорожали.
рисковали в будущем застрять на старых технологиях. Думаю, многие коллеги сталкивались с legacy-монолитами — за окном 2020-й год, а на мониторе в коде 2003-й. Переписывать все это крайне сложно. Обычно не хватает ни времени, ни ресурсов.

К счастью, мы заранее предвидели риски, поэтому переход на новую архитектуру не шокировал. Все прошло плавно и спокойно. Микросервисный подход решил несколько задач:

многократное использование микросервисов позволяло легче адаптироваться под новые требования стартапа и масштабировать его;
внедрять новый функционал без дополнительных затрат;
упрощать интеграцию последующих приложений;
использовать разные языки программирования под микросервисы и разные виды протоколов для общения между ними.

Но тут же вспылили недостатки. Во-первых, повысился порог вхождения в проект. Во-вторых, усложнилось поддержание, конфигурация и тестирование настроек. По сути это не является минусом. Главное, что у нас микросервисами закрыли самые важные вопросы.
Со временем заказчик понял, что хочет продавать продукт не только целиком, но и отдельными частями, тем самым упрощая жизнь пользователям. На тот момент у нас уже был различный функционал, из которого планировали выделить небольшие независимые компоненты. А из них — построить идентичные конструкции или создать новые бизнес-решения. Каждый микросервис обладает своей логикой и функциями, но этот пазл можно интегрировать в любую другую систему и самостоятельно развивать ее. Если один из компонентов перестал работать, не значит, что вся система обязательно рухнет. Возможно, отвалится то, что тесно связано с данным микросервисом. Но в том или ином виде система продолжит работать.
Микросервисы хороши и тем, что их можно развертывать и тестировать независимо друг от друга. Это упрощает жизнь команде как в процессе разработки, так и в дальнейшем развитии проекта.
Что микросервисы дали нашему проекту:

взаимодействие PHP и Golang. Отлично дополняют и в некоторых случаях перекрывают слабые стороны друг друга. По сравнению с PHP, с помощью Golang можно значительно улучшить перфоманс. За счет параллелизма — ускорить обработку и выполнение тех или иных процессов. В тоже время у PHP есть все для быстрой реализации удобного CRUD;
от пяти крупных клиентов мы перешли к более чем 20-ти — все благодаря разграничению монолита на отдельные решения;
оптимизировали нагрузку на сервера. По сравнению с PHP, Golang потребляет намного меньше памяти. С его внедрением и переписыванием и развитием нескольких частей приложения на Golang серверам стало легче. Больше мы с этой проблемой не сталкиваемся;
разнообразили команду. Переход к микросервисам — это не только изменение архитектуры кода, но и самой команды. Мы поделились по зонам ответственности. Когда-то нас было пятеро, сейчас — около 40 человек. Добавились бэкенд-разработчики и бизнес-аналитики, заточенные под определенные спецификации.

Появились нюансы, усложняющие поддержку безопасности транзакций. В случае с микросервисами мы имеем дело с децентрализацией данных. Также, прежде чем писать код, разработчикам надо помнить о возможной несогласованности.
Не обошлось без сложностей для новых членов команды. Им нужно больше времени, чтобы понять, как микросервисы между собой взаимодействуют и делают ли это вообще. Насколько глубоко начинающий разработчик должен в этом разбираться? Чем разнообразнее база знаний, тем специалист ценнее на рынке и может оперативно реагировать на изменения в проекте. Когда есть, с чем сравнивать, намного легче среди нескольких вариантов выбрать наиболее подходящий в текущий момент. Поэтому, как минимум, ознакомиться с этим архитектурным подходом я советую всем. Новичок может начать с более простых вещей — с монолита — но помнить, что когда-нибудь придется углубиться в микросервисы. Все-таки тренды индустрии никто не отменял.
Монолит словно здоровенный котел, в котором варится сразу много всего. С появлением новых ингредиентов мы пытались все структурировать. Но помешивая этот «суп», затрагивали другие ингредиенты, даже когда это не требовалось. Микросервисы помогли создать современную технологическую кухню и разделить зоны функциональности. Мы уже не только «варили», но и «запекали», «кипятили», где-то «жарили», а где-то только «подогревали». Познав тонкости этой «высокой кухни», в результате получили качественные продукты.
Получается, микросервисы рулят?
На самом деле, окончательного ответа нет. В тех или иных ситуациях бывает логичнее стартовать с монолита. Но в будущем система может достичь таких масштабов, что переход к микросервисам неизбежен. Из личного опыта я отметил пару сценариев, в которых стоит задуматься о переходе на микросервисы:

когда в монолитном проекте стоимость нового функционала не перекрывает ожидаемую пользу;
когда проект разрастается до такой глыбы, что новые люди в команде теряются. В микросервисах можно взять отдельный компонент, определить, что в нем происходит и работать только с ним. В крупных проектах разделение обязанностей рано или поздно приведет к архитектурным разграничениям. Микросервисы позволяют легче пережить этот момент.

Иногда мы сталкиваемся с настойчивыми клиентами, которые отказываются от здравой идеи разработчиков. Вот вздумалось ему только эту технологию или архитектуру применять. Почему? Да потому что. «Слышал в интернете» или «Все так делают». Заказчик редко задумывается о подводных камнях, на которые могут наткнуться программисты. Если вы видите, что есть более эффективный подход, идея заказчика вызовет новые проблемы или вообще остановит развитие проекта, ваша задача — не бояться сказать клиенту, что он не прав. Объясните, почему лучше использовать ту или иную технологию или подход. Как показывает практика, когда вы можете аргументировать преимущества своей идеи и недостатки предложенного заказчиком решения, он спокойно примет вашу сторону. Проект — это его детище, его деньги, и прежде всего клиент заинтересован в эффективности и прибыльности продукта.
В нашем случае мы разработали много спецификаций, которые жили обособленно и полноценно не взаимодействовали друг с другом. А как только разбили их на независимые микросервисы, получили высокие показатели в перформансе и счастливого заказчика, который приумножил прибыль. Подробности можно узнать из моего доклада на NIXMultiConf.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_php, #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_mikroservisy (Микросервисы), #_mikroservisy (микросервисы), #_monolit (монолит), #_blog_kompanii_nix (
Блог компании NIX
), #_php, #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_mikroservisy (
Микросервисы
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 12:39
Часовой пояс: UTC + 5