Разделение микросервисов
Я немного запутался. В моей компании у нас много разных интеграций, на данный момент они у нас есть в одном приложении. Если мы решим перейти на микросервисную архитектуру, должна ли каждая интеграция быть отдельной службой или все они должны быть в одном?
Ситуация с интеграциями заключается в том, что они являются платежными интеграциями, мы общаемся с поставщиками платежей и асинхронными ответами от них, поэтому мы должны открывать пару URL-адресов для каждой интеграции, чтобы получать ответы от платежных шлюзов. Значит, они не связаны друг с другом.
Ответы 2
Хотя вы могли бы, я был бы очень осторожен с чрезмерным проектированием вашего решения. Использование докер-контейнеров, например, для создания микросервисов по-прежнему связано с накладными расходами для каждого запущенного контейнера. Я бы порекомендовал начать с нескольких микросервисов. Идеальные кандидаты - если вам нужно масштабировать один микросервис по шкале N-масштабирования, а не другой.
Например:
Service-A имеет высокую нагрузку, поэтому ее необходимо масштабировать до 4 экземпляров.
Service-B имеет низкую нагрузку, поэтому нужно всего 2 экземпляра
Еще один отличный кандидат - если у вас есть микросервис, который можно использовать в нескольких проектах.
Если каждая интеграция будет отдельной услугой, это зависит от того, какой тип интеграции. Но да, микросервис в целом означает создание нескольких небольших сервисов, которые полностью независимы.
Одна из больших проблем с монолитным сервисом заключается в том, что это единственная точка отказа. Таким образом, чтобы избавиться от этого риска, вы разбиваете свою службу на несколько небольших служб. Так что ваш уровень интеграции не потерпит неудачу, если несколько служб вышли из строя.
В примере, который вы описываете для оплаты, вы можете использовать иерархию микросервисов. Вы можете выделить одну или две службы для подключения вашего внешнего убежища и разрешить другой службе подключить тысячу одну или две внутренние службы.
Одна вещь, которую я настоятельно рекомендую, если вы выбираете микросервис, подумайте о внедрении CI / CD (jenkins / chef), docker и kubernetes. Если у вас нет автоматизации, вы скоро обнаружите, что будете больше заниматься обслуживанием сервисов, чем разрабатывать.
В конце концов, самая главная причина, по которой вам нужны микросервисы, - это убедиться, что ваш уровень интеграции всегда доступен и хорошо продается. Без некоторой автоматизации, такой как docker и kubernetes, вам потребуется много ручной работы, чтобы поддерживать состояние вашего сервиса.