Как сделать api для микросервисов на php?

Question

[Валерий В.]

Добрый день!
Вопрос в теме - как сделать api шлюз для микросервисов?
Мне не совсем понятно как устроена вся цепочка до сервиса: составляющие, назначение, транспорты и т.д. Какие технологии/стеки лучше применять?
Информация в гугле как то в общем написана, без особых подробностей, поэтому требуется "разжевать".
Спасибо!

Upd: Добавил картинку.



Интересуют структура и связи блока api шлюз(выделено желтым).

Answer 1

[Максим Тимофеев]

api - слишком широкое понятие, как и зоопарк микросервисов на php. Поэтому Вы и не можете найти информацию. Это как искать "сделать что-то что будет обращаться куда-то, как-то получать данные от маленькой как-то написанной программы" Это ни о чем. Конкретизируйте задачу. О каких микросервисах речь, какой способ передачи данных по api (их немало, xml, json). Ну и наконец, что планируете использовать, так как это может быть любой язык программирования, в этом и суть api.
Если все это Вы и пытаетесь найти, тогда опишите саму задачу, например "делаю мобильное приложение, есть вот такое api, что лучше использовать".

Comments

[Валерий В.]

Конкретизирую.
Клиентом может быть что угодно: вебсайт, десктопное или мобильное приложение. Транспорт, наверное HTTP, может что-то другое. Запросы идут на api шлюз (агрегатор), далее на сервисы.
С клиентами и сервисами понятно - как их делать вопросов нет - разные языки, стеки и т.д. Интересует именно часть шлюза-агрегатора, как он архитектурно устроен, это монолитное целое или шлюз отдельно, агрегатор отдельно, какой функционал его частей, как они взаимодействуют, etc.
В общем в этом месте затык и непонятки.
Почему рассматриваю микросервисы, а не монолит - архитектура должна быть независимой, динамичной и расширяемой.

[Максим Тимофеев]

Валерий В., тут все зависит от того, какие данные будут бегать, как часто и т.д. Вот вам первый попавшийся например:
https://habrahabr.ru/post/269659/
Вот вам:
другие варианты

[Валерий В.]

Максим Тимофеев,
Я этот материал прочитал уже не раз, но все равно понимания четкого не возникло, поэтому и сюда пишу. Хотелось бы услышать сравнение вариантов исполнения (внутренних архитектур) с обоснованием. Почему так лучше, а не иначе. Про это нигде не пишут толком. Кусочная отрывочная информация везде.

[Максим Тимофеев]

Валерий В., Так это трактат на очень много страниц, на диссертацию потянет. Вам тут вряд ли кто-то так ответит. Это же сервис вопрос ответ. Вот если в прочитанном, не понятен конкретный момент - спрашивайте.

[Валерий В.]

Максим Тимофеев,
ок, я в другом комментарии написал, что нужно будет трансформировать монолит в микросервисы. Вопрос в middleware.

[Максим Тимофеев]

Вопрос в middleware.

для чего? php? js? Пальцев в небо ткнуть? Прошу:
https://github.com/senchalabs/connect

[Валерий В.]

Для связи клиентов и сервисов.
Сервисы ведь могут быть реализованы и в монолите посредством api.
А я не понимаю как эту связь с монолита перетащить в распределенную систему микросервисов (пока не будем трогать Docker, считаем, что все сервисы на разных машинах будут).

Можете вкратце написать всю цепочку прохождения запроса-ответа с клиента на сервис и обратно с указанием используемых протоколов и архитектурных блоков?
Например: клиент (запрос авторизации) -> протокол HTTP, данные(логин, пароль) -> ... -> ... сервис выдачи токена по запросу (токен) -> ... -> ... клиент получил токен(протокол HTTP)

Answer 2

[Марат Мхитарян]

nginx, haproxy, apache, docker

Answer 3

[Александр Кузнецов]

Если сказать грубо, то API в общем понимание - это и есть набор микросервисов (далее МС).
Т.е., скажем у нас есть API для получения списка пользователей, тогда, в терминах МС, у нас есть МС "Список пользователей", цель которого следует из названия. Общая концепция - иметь минимальное количество качественных действий. Отсюда и его преимущества и недостатки ( https://ru.wikipedia.org/wiki/Микросервисы ) .

В целом по технологиям и стекам - вполне можно и на PHP, используя ту же Symfony/Silex/Slim/Equip и т.д. Тут, на чем удобно, то и используйте. Я вообще не слышал, чтобы разрабатывали конкретные решения под нужды МС.
Если смотреть на Java, я видел не мало примеров на spring-boot, на .NET - .net core думаю будет идеален (asp.net core).

В качестве протоколов обычно выбирается JSON, но никто не будет вас ругать, если вы будете использовать protobuf или вообще, что-то свое. У каждого свои нюансы, в общем.

Говоря про общие моменты, обычно, рядом с МС всегда "употребляют" тот же Docker и автоматические средства развертывания. Т.е. по факту - МС, зачастую, цельный блок инфраструктуры, сразу же готовый для использования после автоматического развертывания.

UPD. Еще, крайне важный момент для МС - это мониторинг работоспособности. Нельзя им пренебрегать. На хабрахабре была не так давно целая статья про мониторинг.

UPD2. Шлюзом-аггрегатором может быть что угодно, более того, его может и не быть. Самый простой вариант шлюза - это NGINX, где можно сделать проксирование запросов, в зависимости от запрашиваемого URL.

Comments

[Валерий В.]

Спасибо за развернутый ответ, но это немножечко не то.
Добавлю еще вводных данных: я хочу сначала сделать монолит (как, собственно, и рекомендуют все), протестировать его работу в продакшне в ограниченном масштабе, а затем безболезненно, с минимальными затратами разобрать его по сервисам. Клиенты и сервисы будут сразу делаться под микросервисы, а вот middleware нужно очень грамотно подумать как сделать.

[Александр Кузнецов]

Если делаете монолит, какое middleware (точнее, что и для каких целей вам потребуется) вы желаете использовать? Не совсем понятен момент.

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

[Валерий В.]

Александр Кузнецов,
вот и мне непонятен :)
Попробуем так: можете вкратце написать всю цепочку прохождения запроса-ответа с клиента на сервис и обратно с указанием используемых протоколов и архитектурных блоков?
Например: клиент (запрос авторизации) -> протокол HTTP, данные(логин, пароль) -> ... -> ... сервис выдачи токена по запросу (токен) -> ... -> ... клиент получил токен(протокол HTTP)

Как то так... нужна вся вот это цепочка.

[Александр Кузнецов]

Уточнение, под блоками -> ... -> ... вы подразумеваете какие-то точки входа в вашу инфраструктуру, которые затем отправляют запрос на конкретные прикладные сервисы? Кроме этого, их возможное назначение, помимо маршрутизации до конкретных сервисов, балансировка нагрузки?

Если это так, тогда на эти точки можно представить вот так

Это путь в одну сторону, назад он возвращается в обратном порядке, грубо говоря.

[Валерий В.]

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

nginx в вашей схеме выступает как web-сервер? другого функционала нет?
а haProxy как балансировщик? или что то еще?

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

[Александр Кузнецов]

haproxy как балансировка нагрузки высокого уровня (опционально). nginx как маршрутизатор (проксирующий сервер) и балансировка более низкого уровня.

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

Если нужна последовательная обработка, схема в виде nginx -> нужный сервис (далее ТВ, точка входа) в целом тут тоже может помочь, т.е. первый сервис делает работу по входящему запросу, затем бросает запрос (и ждет ответ) на ТВ, которая его кидает куда надо и т.д.

Дополнительно по проксированию запросов:
devacademy.ru/posts/razbiraemsya-v-http-proksi-ngi...

Вообще, для этой схемы подойдет и IIS сервер (мало ли, может у вас Windows Stack), работающий с ARR.

[Валерий В.]

Александр Кузнецов,
мы говорим о разных вещах :)
я добавил картинку - нужна функциональная архитектура блока api выделенного желтым

[Александр Кузнецов]

Валерий В., Вообще, нет. То, что я описал, подходит для этого. Или я чего-то не понимаю/не знаю, что знаете вы.

[Валерий В.]

Ну, если быть точным, то, конечно, вы правильно говорите, например, в части очередей: планируется использование rabbitmq, возможно kafka в дальнейшем.
если смотреть на мою картинку, то слой 2 и слой 3 могут быть на одной машине (без Docker, в монолите), а при переходе на распределенную структуру слои 2 и 3 разделяются по разным машинам. Вот я и хочу понять, как лучше сделать архитектурно этот желтый участок, чтобы сохранить остальные части без изменений (больших изменений)

[Александр Кузнецов]

Валерий В., https://habrahabr.ru/post/315128/ , https://github.com/poweredlocal/vrata

Answer 4

[mitaichik]

Учитывая ваши комментарии к другим ответам, вам нужно просто сконфигурировать nginx.

Он принимает запросы от клиентов, и в соответстивии с конфигм, отсылает их куда нужно. Будь то другая машина, разные процессы, или несколько php-fpm пулов - настроить можно как угодно.

Что-то типа

location /match/here1 {
    proxy_pass 127.0.0.1:8081
}

location /match/here2 {
    proxy_pass 127.0.0.1:8082
}

Тут, например, запущенно несколько процессов, которые слушают разные порты. Разыне uri ведут на соответсвующий процесс, которые может обрабатывать данный запрос. Изменив ip на удаленную машину можно направить запрос на другую машину.

Это просто пример, в реальной конфигурации, скорее всего, придется заголовки пробрасывать, а в случае других машин - обеспечивать безопасный канал (если требуется), но в целом все делается крайне просто. Вот линк devacademy.ru/posts/razbiraemsya-v-http-proksi-ngi...

Comments

[Александр Кузнецов]

Я уже давал эту ссылку выше. Помимо этого, есть еще вот такая штука - https://habrahabr.ru/post/315128/

[Валерий В.]

Да, вы верно говорите, можно через nginx проксировать запросы на сервисы.
Но в каком тогда месте агрегировать результаты запросов? Я не хочу вешать этот функционал на клиента, хотя это один из архитектурных вариантов.
Мне нужно чтобы клиент получал готовый результат в нужном ему формате, а всю работу по агрегации и обработке данных делал middleware. Таким образом избавляем разнотипных клиентов от написания для каждого из них своего собственного блока агрегации и обработки. Я хочу избавить клиента от лишней работы.
Да, читал про врата еще до написания этого вопроса. Приблизительно похоже что мне нужно. Но не совсем то.
Давайте еще раз попробую.
Мне нужно провести границу между middleware и сервисами, причем так, чтобы ее можно было реализовать одним и тем же способом и на монолите и на распределенной системе на разных машинах.
Например, через AMQP на RabbitMQ возможно это сделать: т.е. консьюмеры могут быть и на одной машине и на удаленных. Т.е. чтобы быстро попилить монолит на сервисы будет нужно лишь поменять настройки очередей (фактически поменять localhost на ip удаленной машины), а все остальные элементы в цепочке обработки запроса от клиента будут без изменения.
Но при работе на AMQP вырастает время исполнения запроса в целом за счет накладных расходов очередей и дополнительных HTTP соединений.
Отсюда и вопрос возник то основной - как лучше построить взаимодействие системы клиент-middleware-сервисы? А не просто вопрос как раскидать запросы с клиента...

[mitaichik]

Валерий В., а что значит аггрегировать резульиаты, что вы под этим понимаете?

[Валерий В.]

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