Руководство крупного интернет-магазина, у которого постоянно растёт пользовательская база и количество заказов, рассматривает возможность переделки своей внутренней ИТ-системы на основе микросервисов.
Вас пригласили в качестве консультанта для оценки целесообразности перехода на микросервисную архитектуру.
Опишите, какие выгоды может получить компания от перехода на микросервисную архитектуру и какие проблемы нужно решить в первую очередь.
Если вкратце, то все должно быть сведено к тому, чтобы этот переход был менее болезненным и плавным, а также была видна общая картина для всех участников проекта.
Если они не использовали предметно-ориентированное проектирование, тогда можно начать с этого, чтобы выделить контексты. Далее эти контексты можно реализовать в монолите через модули, в результате чего при переходе на микросервисную архитектуру, изменений в коде будет минимум, и сам переход будет более плавным и безопасным. Также желательно, чтобы перенос осуществляли те люди, которые знают домен и контексты, они же программировали монолит, чтобы ошибок было минимум. Таким образом будет быстрее, если не использовать зоопарк из разных версий языков, иначе придется нанимать людей, что существенно замедлит переход.
Когда мы знаем все контексты и их зависимости, мы можем понимать какому контексту какая инфраструктура нужна. Кому-то нужны вычислительные мощности, тогда процессоры посерьезнее берем, кому-то оперативная память и т.п. Также нужно понимать, какие взаимодействия будут синхронными, а какие асинхронными, тогда нужно будет использовать очереди и соответствующее ПО. Для кого-то нужны балансировщики, для кого-то репликации БД, кэшей и т.п. В идеале должна быть архитектурная схема микросервисов, их взаимодействий и деплоя, чтобы девопс понимали, что и как разворачивать, а также чтобы бизнес понимал, какие ресурсы будут использованы и почему, чтобы было понимание за что и сколько бизнес платит.
Также нужно принять решение сколько API версии, да и в целом версий сервисов мы будем поддерживать. Нужно ограничить количество используемых языков и их версий, на которых будут написаны эти микросервисы, иначе ci будет долгим и много ресурсов потреблять, т.к. придется тестировать на конкретном языке всех версий компании вместе с фреймворком и его версиями. В результате комбинаторика из этого всего будет гарантировать качество, а это по ресурсам дорогова-то и долго. Нужно сформировать шаблоны для ci/cd и стандарты, чтобы внедрение сервисов было быстрым и с одинаковыми стандартами.
Тестирование в целом будет сложнее, т.к. придется тестировать межсервисное взаимодействие, и могут потребоваться для теста все сервисы.
О безопасности сложнее заботиться, каждый сервис должен иметь свой контур.
Выгоды:
- Каждый сервис живет своей жизнью, разрабатывается независимо от других, и поддерживает минимум версий. Быстрота и качество.
- Каждый сервис может масштабироваться отдельно от других настолько, насколько ему это необходимо.
- Каждый сервис может иметь балансировку, параллелизм в запросах, работу синхронную или асинхронную, если ранее такого не было.
- Каждый сервис не особо крупного размера, легко поддерживать.
В результате проект будет справляться с большей нагрузкой за меньшее потребление ресурсов. Как следствие, больше довольных пользователей, и довольное начальство. Горизонтальное масштабирование очень сильно, в сравнении с вертикальным. У него пределы дальше, можно его настроить таким образом, чтобы при увеличении нагрузки, происходило масштабирование, а при уменьшении, убиралось, что экономит существенно ресурсы.