При работе с микросервисами следует помнить, что в первую очередь они касаются не технических, а организационных проблем. Поэтому, когда мы смотрим, должна ли организация использовать микросервисы, и как эти службы развертываются, нам нужно посмотреть, есть ли у организации проблемы, которые решает стиль микросервисов.
Таким образом, ответ на ваш вопрос о вашей архитектуре будет в основном зависеть от размера вашей технологической группы, организационной структуры, возраста вашего продукта, ваших текущих методов развертывания и того, как они могут измениться в среднесрочной перспективе.
Например, если ваша организация:
- имеет менее 25 технических сотрудников,
- организованы в 1 или 2 команды,
- каждый из которых работает на любой части продукта,
- которому менее 12 месяцев,
- и развертывается все сразу на регулярной основе (например, ежедневно, еженедельно, ежемесячно),
- и организация не собирается быстро расти,
тогда вы почти наверняка хотите забыть о микросервисах на данный момент. В такой ситуации команда все еще новичок в изучении предметной области, поэтому, вероятно, не знает всего, что им нужно знать, чтобы по-настоящему понять, что будет отличным способом разделить систему на распределенную архитектуру. Это означает, что если они разделят его сейчас, они, вероятно, захотят изменить границы позже, и это станет очень дорого, если у вас уже есть распределенная система, и при этом намного проще в монолите. Более того, имея лишь небольшую команду, которая может работать над любой частью системы (и поддерживать ее), нет особых оснований вкладывать средства в создание платформы, на которой отдельные группы могут развертывать и обслуживать отдельные службы. На данном этапе организация, как правило, будет гораздо больше озабочена поиском клиентов и быстрой итерацией продукта, возможно, даже поворотом продукта, в отличие от создания автономных групп и построения масштабируемой, отказоустойчивой архитектуры. Монолитная архитектура имеет смысл на этом этапе, нохорошо продуманный монолит с четкими границами компонентов, обеспечиваемыми API-интерфейсами, и инкапсулированным доступом к данным, что упрощает последующее выделение служб в отдельные процессы.
Давайте посмотрим немного дальше и рассмотрим организацию, которая ...
- более 50 технических специалистов,
- организованы в 7 команд,
- каждая из которых работает только на определенных областях продукта,
- которому 3 года,
- и есть команды, желающие развернуть свою работу независимо от того, что делают другие команды.
Такая организация, безусловно, должна строить распределенную архитектуру. Если они этого не сделают, и вместо этого все эти команды будут работать в монолите, они столкнутся с различными организационными проблемами: командам необходимо координировать свою работу, релизы откладываются, пока одна команда заканчивает QA для своей новой функции, патча разворачивает быть большой проблемой для персонала и клиентов. Более того, со зрелым продуктом организация должна знать достаточно о домене, чтобы иметь возможность разумно разделить домен и команды (в таком порядке; см. Закон Конвея) на разумные, автономные единицы, которые могут добиться прогресса при минимальной координации.
Вы, кажется, уже выбрали микросервисы. В зависимости от того, где вы сидите на весах выше, возможно, вы захотите пересмотреть это решение.
Если вы хотите продолжать разработку с использованием микросервисов, но развертывать их все в одном контейнере, знайте, что в этом нет ничего плохогоесли это соответствует тому, как работает ваша организация в данный момент. Это создаст проблемы для вашей структуры проекта в будущем? Что ж, если вы добились успеха и ваша организация растет, вероятно, придет время, когда это развертывание с одним контейнером больше не будет подходить лучше всего, особенно когда команды начинают владеть службами и хотят развертывать только свои службы без развертывания всего приложения. , Но эта автономия будет стоить дополнительной работы и сложности, и в данный момент она может не принести вам никакой пользы. То, что это не будет правильным подходом для вашей системы в будущем, не означает, что это не правильный подход на сегодняшний день. Хитрость заключается в том, чтобы следить за этим и знать, когда делать дополнительные инвестиции.