Микросервисы в реализации Docker

Мы пишем наши первые микроуслуги, используя контейнеры Docker, используя Amazon Fargate. У нас много сомнений относительно уровня реализации с использованием Spring Boot

У нас в проекте будет несколько микросервисов. Хорошей практикой является написание всех микросервисов в одном контейнере или создание отдельного контейнера Docker для отдельных микросервисов. Экономически эффективным способом мы используем один контейнер, но это создаст какие-то проблемы для структуры нашего проекта в будущем?

Мы планируем развернуть приложение в AWS fargate, и в будущем наше приложение будет иметь возможность расширяться и ожидает от 100 до 150 различных микросервисов. В этом случае выгодно ли загружать все эти микросервисы в разные контейнеры?

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

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

Например, если ваша организация:

• имеет менее 25 технических сотрудников,
• организованы в 1 или 2 команды,
• каждый из которых работает на любой части продукта,
• которому менее 12 месяцев,
• и развертывается все сразу на регулярной основе (например, ежедневно, еженедельно, ежемесячно),
• и организация не собирается быстро расти,

тогда вы почти наверняка хотите забыть о микросервисах на данный момент. В такой ситуации команда все еще новичок в изучении предметной области, поэтому, вероятно, не знает всего, что им нужно знать, чтобы по-настоящему понять, что будет отличным способом разделить систему на распределенную архитектуру. Это означает, что если они разделят его сейчас, они, вероятно, захотят изменить границы позже, и это станет очень дорого, если у вас уже есть распределенная система, и при этом намного проще в монолите. Более того, имея лишь небольшую команду, которая может работать над любой частью системы (и поддерживать ее), нет особых оснований вкладывать средства в создание платформы, на которой отдельные группы могут развертывать и обслуживать отдельные службы. На данном этапе организация, как правило, будет гораздо больше озабочена поиском клиентов и быстрой итерацией продукта, возможно, даже поворотом продукта, в отличие от создания автономных групп и построения масштабируемой, отказоустойчивой архитектуры. Монолитная архитектура имеет смысл на этом этапе, нохорошо продуманный монолит с четкими границами компонентов, обеспечиваемыми API-интерфейсами, и инкапсулированным доступом к данным, что упрощает последующее выделение служб в отдельные процессы.

Давайте посмотрим немного дальше и рассмотрим организацию, которая ...

• более 50 технических специалистов,
• организованы в 7 команд,
• каждая из которых работает только на определенных областях продукта,
• которому 3 года,
• и есть команды, желающие развернуть свою работу независимо от того, что делают другие команды.

Такая организация, безусловно, должна строить распределенную архитектуру. Если они этого не сделают, и вместо этого все эти команды будут работать в монолите, они столкнутся с различными организационными проблемами: командам необходимо координировать свою работу, релизы откладываются, пока одна команда заканчивает QA для своей новой функции, патча разворачивает быть большой проблемой для персонала и клиентов. Более того, со зрелым продуктом организация должна знать достаточно о домене, чтобы иметь возможность разумно разделить домен и команды (в таком порядке; см. Закон Конвея) на разумные, автономные единицы, которые могут добиться прогресса при минимальной координации.

Вы, кажется, уже выбрали микросервисы. В зависимости от того, где вы сидите на весах выше, возможно, вы захотите пересмотреть это решение.

Если вы хотите продолжать разработку с использованием микросервисов, но развертывать их все в одном контейнере, знайте, что в этом нет ничего плохогоесли это соответствует тому, как работает ваша организация в данный момент. Это создаст проблемы для вашей структуры проекта в будущем? Что ж, если вы добились успеха и ваша организация растет, вероятно, придет время, когда это развертывание с одним контейнером больше не будет подходить лучше всего, особенно когда команды начинают владеть службами и хотят развертывать только свои службы без развертывания всего приложения. , Но эта автономия будет стоить дополнительной работы и сложности, и в данный момент она может не принести вам никакой пользы. То, что это не будет правильным подходом для вашей системы в будущем, не означает, что это не правильный подход на сегодняшний день. Хитрость заключается в том, чтобы следить за этим и знать, когда делать дополнительные инвестиции.

Нет проблем, если вы используете один контейнер для своих микросервисов, но основная цель микросервисов состоит в том, чтобы поддерживать каждую услугу отдельно, каждая служба должна быть слабо связана, и каждая служба должна иметь отдельную базу данных (если вы хотите получить базу данных для каждой архитектуры сервиса). Поэтому постарайтесь добиться этого, запустите свои сервисы в отдельном контейнере и организуйте их с помощью Docker Swarm или Kubernetes. Я знаю, что стоимость имеет значение, но если вы сделаете это правильно, то увидите мощь архитектуры микросервисов.