Как развернуть микросервисы на Heroku

Я много читал о микросервисов, и хотел бы построить свое приложение с таким подходом. Что я знаю до сих пор, что я nead некоторые услуги, как:

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

  • сервис B - для функциональности B

  • etc. так далее. так далее.

Я узнал, что Heroku-интересное место для развертывания приложений. Моя проблема в том, что я совершенно не понимаю их идеологию. То, что я сделал до сих пор, - это создание / Регистрация немногих "apps":

  • my-app-auth
  • my-app-load-balancer
  • etc. так далее.

Я вижу, что Heroku дает мне некоторое публичное имя хоста для каждого из этого приложения, и здесь начинаются мои проблемы. Следует ли развертывать внутренние службы с общедоступными именами хостов? Я так не думаю. И вот мой вопрос:--1-->

может кто-нибудь дать мне некоторые рекомендации, как бороться с микросервисов на Heroku? Как их развернуть? Как я должен определить свой балансировщик нагрузки и подключить к нему внутренние службы? Что такое JHipster? Нужна ли она мне? Как я могу его использовать? Должен ли я использовать инструменты Heroku (например, CLI) или могу остаться с моим репозиторием gitlab? Я не могу найти какой-либо точки понимания в интернете, об этом.

12
architecture heroku jhipster microservices

1 ответов

Heroku-очень простая платформа как сервисная компания. Способ работы Heroku очень прост:

  • у вас есть несколько проектов (сервисов) в репозиториях Git.
  • вы создаете приложение Heroku для каждого проекта (каждое РЕПО Git).
  • затем вы нажимаете свой код из каждого репозитория Git в соответствующее приложение Heroku.
  • Heroku назначает вам общедоступный URL для каждого приложения, которое у вас есть.
  • Если каждая из ваших служб теперь работает на Heroku, они может отправлять запросы API друг другу через общедоступный HTTPs.

Теперь -- относительно вашего вопроса о сервис-ориентированной архитектуре на Heroku.

Если вы делаете SOA на Heroku, вам нужно, чтобы каждая служба публично разговаривала друг с другом по HTTPS. Это типичный "паттерн".

потому что Heroku предоставляет бесплатный SSL для каждого приложения, и каждое приложение находится в том же регионе Amazon-разговор между вашими службами через HTTPs очень быстро + безопасно.

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

следующий вариант здесь (Если вы не хотите следовать типичным шаблонам) - использовать что-то вроде RabbitMQ или Amazon SQS (служба очереди) и обмениваться "сообщениями" между вашими различными службами.

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

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

наконец, для базы данных: вы можете использовать любого поставщика базы данных хотеть. Самый популярный, вероятно,Heroku Postgres. Это размещенный versino PostgreSQL, который очень надежен / прост в использовании.

вы можете либо поделиться одной базой данных среди всех ваших услуг, или вы можете иметь одну базу данных на службу. Любая стратегия будет работать нормально.

18