Моя концепция соответствует архитектуре Microservice?
Я читаю статья о микросервисах на странице Мартина Фаулера и найти его довольно интересным. Сейчас я планирую структурировать веб-приложение электронной коммерции в качестве подтверждения концепции и задаюсь вопросом, не считается ли моя концепция архитектурой микросервиса.
Архитектура состоит из 3 компонентов:
- одностраничное приложение на основе JavaScript, которое отправляет AJAX-запросы
- сервер с REST API, который передает данные JSON, полученные при вызове других служб (я думаю, вы называете это поведение API Gateway)
- 3 услуги: КаталогПоставщик, ЗаказчикиПровайдер, Оформление заказаПровайдер
На данный момент все сервисы являются конечными точками API Magento (PHP) Shopsystem. В будущем я планирую заменить провайдеров другими системами.
Итак, мои вопросы:
-
MS считаются «независимо развертываемыми». Я понимаю, что в мире JAVA речь идет об одном JAR- или WAR-файле, но как PHP-сервис «независимо разворачивается»?
-
Моя концепция НЕ соответствует принципам архитектуры MS, потому что все провайдеры являются частью одной большой (Magento) системы?
Спасибо за чтение. Я рад за любые предложения.
Решение
Ничто не говорит о том, что ваша архитектура не является архитектурой MS только потому, что вы используете magento и PHP. Но вы должны рассмотреть несколько вещей:
- Подумайте о том, чтобы всегда иметь возможность переписать любую из служб на любом языке и развернуть где-то, что вся система должна просто продолжать работать.
Если ваши сервисы — это просто преобразование / интерфейс, очень тесно связанный с magento, и вы не можете просто переписать их в java / C # / ruby, то, я думаю, у вас нет архитектуры MS.
Для развертываемых артефактов PHP у вас обычно есть какая-то стратегия упаковки или управления версиями вокруг вашего сервиса. Даже если «развернуть» в PHP, как правило, просто поменять местами папку .php файлов. И вам не стоит делить код / конфиг между разными сервисами. Вы даже можете посмотреть на инструменты развертывания для PHP если вы хотите сделать дополнительный шаг.
Другие решения
Что касается микросервисной архитектуры, то здесь существует принцип SRP. Принцип единой ответственности. Каждый сервис имеет свою уникальную ответственность. Схема БД также должна быть разложена. Экспортировать сервисы как остальные внутри монолитного приложения, а не конвертировать монолитное приложение в приложение микросервиса.