Docker Container и сторонние интеграции?

Question

Я новичок в Docker & microservices и пытаюсь разбить существующие монолитные сервисы на более мелкие микроуслуги, используя контейнеры Docker.Идея состоит в том, чтобы логически разделить монолиты на более мелкие независимые модули в виде микросервисов и поместить каждый в отдельные контейнеры Docker и управлять им через Kubernetes для масштабирования.

Предостережение: эти службы либо подключены к третьим сторонам через REST, либо к критически важным объемным даннымбазы данных.У них нет локальных БД, поэтому у меня не может быть локальных микросервисных БД в ограниченном контексте.

Я пытаюсь найти лучший подход к рефакторингу

• Я думаю, что один из подходов - поместить код подключения к БД в отдельный контейнер и вызывать его из других контейнеров.

• Аналогичным образом поместите логику интеграции REST сторонних производителей в один контейнер и вызовите ее из других контейнеров.

Вопросы:

1. Могу ли я иметь микросервис без подключенной к нему базы данных?
2. Могу ли я иметь контейнерный код, как указано выше, и при этом иметь право на микросервис?
3. Можно ли использовать микросервис только для интеграции??
4. Подходит ли использование докеров для этого сценария?

Answer 1

Когда речь идет об архитектурах, не существует единственного лучшего решения, оно всегда зависит от того, что вы делаете или хотите достичь.Но я могу ответить на несколько вопросов.

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

Вы можете иметь контейнерный код и подходить для микросервисов, так как это хорошая практика для контейнеризации всех микросервисов.

• Я думаю, что вы должны разделить сервисы логически, поэтому база данных для каждого микросервиса должна быть с нимВместо вызова другой службы для базы данных, поскольку это только увеличит стоимость, но не принесет никаких других преимуществ.
• Соедините микросервисы друг с другом либо напрямую, либо с помощью RabbitMQ, я думаю, будет лучше.
• Создатьодин дополнительный сервис, который будет использовать сторонние REST-сервисы, а также предоставлять REST-сервисы при необходимости.

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

Answer 2

Все зависит от того, чего вы пытаетесь достичь.Микросервисы - это ограничение дизайна без единого правильного ответа.Идея заключается в создании слабосвязанных сервисов, которые можно обновлять, масштабировать и развертывать независимо, не затрагивая другие сервисы.

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

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

Просто оцените все сценарии и посмотрите, как вы можете сделать независимые услуги.Надеюсь, это поможет.