Как набрать 17 000 зрителей в прямом эфире? Итак, это рецепт. Берем 15 актуальных IT-направлений, приглашаем иностранных спикеров, дарим подарки за активность в чате и вуаля — крупнейшее онлайн-мероприятие Украины и Восточной Европы готово.
Точно прошедший ежегодная конференция по мультитулам NIXMultiConf .
Под лозунгом «для айтишников, от айтишников» эксперты из Украины, Белоруссии, России, Великобритании и Германии делились опытом и рассказывали об инновациях отрасли.
Было полезно всем — дизайнерам, разработчикам, тестировщикам и менеджерам.
И теперь мы делимся с вами инсайтами.
На основе экспертных отчетов НИКС Продолжаем серию материалов на самые актуальные темы.
В новой статье PHP-разработчика Александр Павленко объясняет, на каком этапе разработки стоит переходить на микросервисы и как это сделать с минимальными рисками.
Если хотите узнать больше, смотрите конференцию по адресу YouTube канал .
Привет! Я Александр Павленко, занимаюсь разработкой на PHP около четырёх лет. Среди крупных проектов — «Платформа продаж автомобилей + инвентаризация», «Архив научных документов», «Платформа поиска работы», «Система сигнализации стихийных бедствий».
Как только начинаешь говорить о монолите и микросервисах, у многих начинается холивар вокруг их сравнения.
Я считаю, что вместо того, чтобы искать плюсы и минусы, лучше выяснить, какой подход лучше всего соответствует бизнес-задачам приложения.
Наша команда работала над финтех-проектом, и изначально он был построен монолитно.
Почему так произошло и какие возможности мы увидели в микросервисах — расскажу подробнее.
Проще начать с монолита
Монолит напоминает кубик Рубика: если из него вынуть одну деталь, собрать новую фигуру или добавить другие компоненты, кубик уже не будет работать полноценно.Каждый элемент формирует единый функционал.
Если какая-то часть отсутствует, сломана или не на своем месте, цветное поле куба не сложится.
В стартап-среде с монолитом можно быстрее запустить проект. Когда, скажем, через месяц вам нужно представить клиенту MVP, а конкретных требований или спецификаций к продукту нет, спасает только гибкость монолита.
Во-вторых, на старте его легко и быстро масштабировать.
Выгоды для команды также были очевидны.
К разработке монолита могут присоединиться и другие специалисты, в том числе новички.
При изучении PHP всегда начинают с монолита.
Он прост и понятен в использовании.
Наш стартап быстро рос.
Число пользователей и клиентов росло, регулярно добавлялся различный функционал.
Со временем недостатки монолита стали очевидны.
Что для нас было критично: Из-за быстрого роста системы стало сложнее поддерживать и развивать ее без дополнительных ресурсов.
В первую очередь это касалось стоимости внесения новых изменений.
Чем дальше мы шли и вводили новые функции, тем дороже они становились.
рискуют застрять в старых технологиях в будущем.
Думаю, многие коллеги сталкивались с легаси-монолитами — год за окном 2020, а на мониторе в коде 2003. Переписать всё это крайне сложно.
Обычно не хватает времени или ресурсов.
К счастью, мы заранее предвидели риски, поэтому переход на новую архитектуру не стал шокирующим.
Все прошло гладко и спокойно.
Микросервисный подход решил несколько проблем: многоразовые микросервисы облегчили адаптацию к новым требованиям стартапа и его масштабирование; внедрить новый функционал без дополнительных затрат; упростить интеграцию последующих приложений; использовать разные языки программирования для микросервисов и разные типы протоколов для связи между ними.
Но затем недостатки обострились.
Во-первых, увеличился порог входа в проект. Во-вторых, усложнилось обслуживание, настройка и тестирование настроек.
На самом деле это не минус.
Главное, что мы затронули самые важные вопросы микросервисов.
Со временем заказчик понял, что хочет продавать продукт не только целиком, но и отдельными частями, тем самым облегчая жизнь пользователям.
На тот момент у нас уже был различный функционал, из которого мы планировали выделить небольшие независимые компоненты.
А из них — строить идентичные структуры или создавать новые бизнес-решения.
Каждый микросервис имеет свою логику и функции, но этот пазл можно интегрировать в любую другую систему и развивать самостоятельно.
Тот факт, что один компонент перестает работать, не означает, что вся система обязательно рухнет. Возможно, отвалится что-то, что тесно связано с этим микросервисом.
Но в том или ином виде система продолжит работать.
Микросервисы хороши еще и тем, что их можно развертывать и тестировать независимо друг от друга.
Это облегчает жизнь команде как в процессе разработки, так и в дальнейшем развитии проекта.
Что микросервисы дали нашему проекту: взаимодействие между PHP и Golang. Они прекрасно дополняют друг друга и в некоторых случаях прикрывают слабые стороны друг друга.
По сравнению с PHP, Golang может значительно улучшить производительность.
За счет параллелизма ускорить обработку и выполнение определенных процессов.
При этом в PHP есть все для быстрой реализации удобного CRUD; Мы перешли от пяти крупных клиентов к более чем 20 — всё благодаря разделению монолита на отдельные решения; оптимизировали нагрузку на сервера.
По сравнению с PHP, Golang потребляет гораздо меньше памяти.
С его реализацией и переписыванием и разработкой нескольких частей приложения на Golang серверам стало проще.
Мы больше не сталкиваемся с этой проблемой; диверсифицировал команду.
Переход на микросервисы — это не только изменение архитектуры кода, но и самой команды.
Мы разделили по зонам ответственности.
Когда-то нас было пятеро, сейчас около 40 человек.
Были добавлены серверные разработчики и бизнес-аналитики, адаптированные к конкретным спецификациям.
Появились нюансы, усложняющие обеспечение безопасности транзакций.
В случае с микросервисами мы имеем дело с децентрализацией данных.
Кроме того, перед написанием кода разработчикам необходимо осознавать возможные несоответствия.
Не обошлось и без проблем для новых членов команды.
Им нужно больше времени, чтобы понять, как микросервисы взаимодействуют друг с другом и делают ли они это вообще.
Насколько глубоко новый разработчик должен это понимать? Чем разнообразнее база знаний, тем ценнее специалист на рынке и может быстрее реагировать на изменения в проекте.
Когда есть с чем сравнивать, гораздо проще выбрать среди нескольких вариантов наиболее подходящий в текущий момент. Поэтому советую всем хотя бы ознакомиться с этим архитектурным подходом.
Новичок может начать с более простых вещей — с монолита — но помните, что когда-нибудь ему придется углубиться в микросервисы.
И все же тенденции отрасли никто не отменял.
Монолит подобен здоровенному котлу, в котором готовится сразу много всего.
С появлением новых ингредиентов мы постарались все структурировать.
Но перемешивание этого «супа» влияло и на другие ингредиенты, даже когда в этом не было необходимости.
Микросервисы помогли создать современную технологичную кухню и отдельные функциональные зоны.
Мы не только «варили», но и «запекали», «варили», иногда «жарили», а иногда только «разогревали».
Познав тонкости этой «высокой кухни», в результате получилась качественная продукция.
Получается, что микросервисы рулят?
На самом деле однозначного ответа нет. В определенных ситуациях может быть логичнее начать с монолита.Но в будущем система может достичь такого масштаба, что переход на микросервисы будет неизбежен.
Из личного опыта я отметил пару сценариев, при которых стоит задуматься о переходе на микросервисы: когда в монолитном проекте стоимость нового функционала не покрывает ожидаемую выгоду; когда проект разрастается до таких размеров, что теряются новые люди в команде.
В микросервисах можно взять один компонент, определить, что в нем происходит, и работать только с ним.
В крупных проектах разделение ответственности рано или поздно приведет к архитектурным границам.
Микросервисы облегчают этот момент. Иногда мы встречаем настойчивых клиентов, которые отказываются от здравой идеи разработчиков.
Он просто решил использовать эту технологию или архитектуру.
Почему? Да потому, что.
«Я услышал это в Интернете» или «Все так делают».
Заказчик редко задумывается о подводных камнях, на которые могут наткнуться программисты.
Если вы видите, что есть более эффективный подход, идея заказчика вызовет новые проблемы или даже остановит развитие проекта, ваша задача — не бояться сказать клиенту, что он не прав.
Объясните, почему лучше использовать ту или иную технологию или подход. Как показывает практика, когда вы сможете аргументировать преимущества своей идеи и недостатки решения, предложенного заказчиком, он спокойно встанет на вашу сторону.
Проект — его детище, его деньги, и прежде всего клиент заинтересован в эффективности и прибыльности продукта.
В нашем случае мы разработали множество спецификаций, которые жили отдельно и не полностью взаимодействовали друг с другом.
А как только мы разделили их на независимые микросервисы, мы получили высокие показатели эффективности и счастливого клиента, который увеличил прибыль.
Подробности можно прочитать в моем отчете NIXMultiConf .
Теги: #Микросервисы #Анализ и проектирование систем #php #monolith
-
Microsoft Беспокоится Об Odf В Калифорнии
19 Oct, 24 -
Создано В .Net
19 Oct, 24
