Monolith First in Elixir совместно с Umbrella Projects

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

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

Не стоит начинать новый проект с микросервисами, даже если вы уверены, что ваше приложение будет достаточно большим, чтобы оно того стоило.
— Мартин Фаулер: МонолитПервый

Используя зонтичные проекты, вы можете получить преимущества монолитов и микросервисов.

Зонтичные проекты

Зонтичные проекты Elixir — это своего рода мета-приложение. Это позволяет нам разделить наш код на несколько приложений elixir и управлять ими на верхнем уровне с помощью mix.

Мы можем сгенерировать новое зонтичное приложение с помощью mix:

mix new --umbrella application_name

Типичный зонтичный проект будет выглядеть так:

umbrella
|-- config
|-- mix.exs
|-+ apps |-+ web |-- config |-- mix.exs |-- lib |-+ data |-- config |-- mix.exs |-- lib |-+ business_logic |-- config |-- mix.exs |-- lib

Верхний уровень umbrella project имеет три внутренних проекта: web, dataа также business_logic.

Приложения

Создайте новое приложение в любое время, когда вы бы создали новый микросервис. У него должен быть связанный домен и собственное хранилище данных (либо база данных, либо внутреннее хранилище ETS).

В типичном веб-проекте я начинаю с двух приложений: web приложение (используя Phoenix) для интерфейса HTTP и data приложение для интерфейса базы данных. Я добавлю новые приложения для бизнес-логики, не связанные ни с хранилищем, ни с веб-запросами.

Релизы

я использую винокурня для создания релизов, когда я буду готов к развертыванию. Простая конфигурация релиза будет выглядеть так:

release :umbrella do set version: "1.0.0" set applications: [web: :permanent, data: :permanent, business\_logic: :permanent,]
end

Если я решу, что приложение бизнес-логики необходимо развернуть отдельно на большем количестве серверов, я могу определить два выпуска:

release :umbrella do set version: "2.0.0" set applications: [web: :permanent, data: :permanent,]
end release :business\_logic do set version: "1.0.0" set applications: [business\_logic: :permanent,]
end

Теперь я могу развернуть umbrella а также business_logic на разные серверы без изменения какой-либо структуры проекта.

Единственным потенциальным недостатком зонтичных приложений является то, что они рассматриваются как библиотеки. Это означает, что вам по-прежнему необходимо применять развязку на уровне API модуля. В микрослужбах каждая служба имеет доступ только к своему собственному коду и вынуждена взаимодействовать по явно определенному протоколу.

Разрушение монолита

По мере роста моей команды отдельные команды занимаются business_logic а также umbrella Приложения. Извлечь внутренние приложения в новый зонтичный проект очень просто.

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

Феникс 1.3

Phoenix 1.3 включает новый генератор зонтов:

mix phx.new --umbrella application_name

Это создает новый проект, который очень близок к описанной выше реализации. Вы можете узнать больше, посмотрев Основной доклад Криса МакКорда Lonestar ElixrConf 2017.