Microservices регистрация реестра службы и открытие

Question

Маленького домен презентация

Я м на самом деле имею два microservices:

• пользователя - управление CRUD на пользователях
• Биллингс - управление CRUD на выставленных счетах, с " ссылка "на пользователя, связанного с выставлением счета

anation

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

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

«, кто является пользователь с id 123456? Мне нужно его загрузить »

Так что мои две службы могли обмениваться, не зная друг друга или не зная« места »друг друга.

Проблемы

• Мой первый вопрос, какова цель использования реестра службы в этом случае? Очередь сообщений может предоставить нам информацию, не зная ничего о местоположении пользовательского сервиса, нет?

• Когда нам нужно использовать регистрацию услуг: В случае шаблона агрегатора с API RESTFul мы можем перемещаться по ссылкам через ссылки. Может быть, в случае прокси-шаблона? Когда микросервисы взаимодействуют с другой службой?

• Признав теперь, что мы используем прокси-шаблон с «фронтальным сервисом». В этом случае для меня нормально использовать регистрацию услуг. Но это означает, что служба отправки на передний план знает имя службы userService и биллинговой службы при регистрации сервиса? Пример:

Регистры служба пользователя как "UserServiceOfHell: http://80.80.80.80/v1/" на Zookeeper

Service регистрирует Платежная как "BillingService: http://90.90.90.90/v4.3/"

Передний конец службы необходимо отправить некоторые запросы к пользователю и услуге биллинга, это означает, что он должен знать, что пользовательская служба - это «UserServiceOfHell». Это определено в начале проекта?

• Последний вопрос: можем ли мы использовать несколько шаблонов микросервисов в одной архитектуре микросервисов или это плохая практика?

NB: Все, что я спрашиваю основано на http://blog.arungupta.me/microservice-design-patterns/

Answer 1

много хороших вопросов!

Прежде всего, я хочу ответить на ваш последний вопрос - несколько шаблонов одобрены, когда вы знаете, что делаете. Хорошо сочетать асинхронные очереди, HTTP-вызовы и даже двоичные RPC - это зависит от согласованности, доступности и требований производительности. Иногда вы можете хорошо подходить для простого PubSub, и иногда вам нужно распределить блокировку - микросервисы разные.

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

Но нам нужно найти сервисное обслуживание в других случаях! Например, службы поддержки: базы данных, кэши и фактически также стоят. Без обнаружения службы вы, вероятно, жестко закодировали URL-адрес своей очереди, но если он опустится, у вас ничего нет. Вы должны иметь высокую доступность - например, кластер узлов, копирующих вашу очередь. Когда вы добавляете новый узел или существующий узел разбился - вы ничего не должны менять, инструмент обнаружения служб должен понимать это и обновлять реестр.

Consul - идеальное средство для поиска новых сервисов, вы можете просто использовать собственное DNS-имя для доступа к вашим службам поддержки, а Consul будет выполнять постоянные проверки работоспособности и поддерживать работоспособность вашего кластера.

Это же правило может применяться к микросервисам - когда у вас есть служба, работающая в кластере A, и вам нужно получить к ней доступ из службы B без каких-либо очередей (например, для HTTP-вызова), вам необходимо обязательно использовать обнаружение служб эта конечная точка, которую вы используете, приведет вас к здоровому узлу. Таким образом, он идеально подходит для шаблонов Aggregator или Proxy из упомянутой вами статьи.

Возможно, наибольшая путаница вызвана тем, что вы видите «жестко закодированные» URL-адреса в Zookeeper. И вы думаете, что вам нужно управлять этим вручную. Современные инструменты, такие как Consul или etcd, позволяют избежать этой головной боли и просто полагаться на них. На самом деле это также возможно с Zookeeper, но для создания аналогичной настройки потребуется больше времени и ресурсов.

PS: пожалуйста, помните о наиболее важном правиле в микросервисах - http://martinfowler.com/bliki/MonolithFirst.html