Архитектура микросервисов – служба-обертка?
Насколько распространены службы-оболочки/API в микросервисной архитектуре? По моему личному опыту кажется, что это анти-шаблон, но, возможно, я упускаю некоторые детали?
Я работаю над разделением тесно связанной архитектуры на настройку микросервиса. Следовательно, при необходимости каждая служба будет иметь собственную базу данных, в противном случае она будет полностью без сохранения состояния.
Клиент использует некоторые сторонние интеграции, у которых есть собственный сервис, поскольку все они предоставляют одинаковые, но по-разному форматированные ответы. Клиент настаивает на создании службы-оболочки поверх всех интеграций, которая будет отвечать за вызов указанных интеграций (например, прокси-службы) и сопоставлять ответы с общей моделью.
Возможно, я понимаю, в чем заключается дополнительная ценность последовательного ответа (хотя этого можно достичь и по-другому), но мне трудно найти аргументы в пользу идеи обертки.
Кроме того, эти интеграции не обязательно должны присутствовать всегда — один клиент может решить, за сколько и за какие интеграции он готов платить.
@PeterCsala Да, я уверен. В этом контексте служба-оболочка представляет собой автономный API, который будет вызывать другие интеграции и сопоставлять эти ответы с общим. Но это не делает ничего большего. Модели реагирования самих интеграций тоже можно настраивать и синхронизировать, здесь нет никаких ограничений.
И есть ли у вас одна служба-оболочка для каждого микросервиса или только одна служба-оболочка для всех микросервисов (как в шаблоне шлюза API)?
@PeterCsala Это будет один для 3 микросервисов из 15.
Ответы 1
Единственная серьезная причина (как и остальные, потому что программист считает, что это круто или читает блоги в Интернете) заключается в том, что вы считаете, что API должен быть взаимозаменяемым с другим, предоставляющим ту же услугу, и вы захотите удовлетворить что. например, если у вас есть интеграция с поиском Google, и вы думаете, что когда-нибудь захотите заменить ее на Bing.
В противном случае вы просто работаете на себя, в стиле YAGNI. Вы можете подумать, что вам нужен общий интерфейс, чтобы клиенты могли вызывать любую службу с помощью одного и того же кода, но все, что вы сделали, это перенесли усилия по вызову службы на прокси - на самом деле вы ничего не сэкономили, а просто переместили ее в другое место.
Итак, YMMV зависит от ваших обстоятельств, но спросите себя, какую выгоду для бизнеса это принесет.
Спасибо за ответ, я определенно чувствую то же самое. Наличие такого большого количества точек отказа нарушит процесс разработки и тестирования. Я думаю, что основная мысль заключалась в том, что FE будет легко общаться с BE, но я всегда чувствовал, что FE должен быть настраиваемым для вашего клиента, а не наоборот.
Честно говоря, если создание более согласованного интерфейса для использования разработчиками FE является требованием, тогда может иметь смысл обернуть внутренние вызовы таким образом, вы берете на себя боль, чтобы эти разработчики javascript (благослови вас) не испортили это. Однако я бы не стал создавать для этого кучу микросервисов: в таком случае будет более удобен в обслуживании один более крупный, который вызывает любой бэкэнд по мере необходимости.
Да, это тоже вариант, я думаю. Но эти интеграции настолько велики, что усложнят жизнь BE-разработчикам.
Я работаю над разделением тесно связанной архитектуры на микросервисную настройку Рисунок-душитель — распространенный шаблон при переходе от монолитной к микросервисной архитектуре. Вы уверены, что они не имеют в виду этот фасад, когда говорят об услугах по упаковке?