Подходы к микросервису Подходит

Question

У меня есть вопрос для сообщества микросервисов. Я приведу пример из образовательной области, но применим к каждой архитектуре микросервисов.

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

Мой вопрос в том, какой подход вы нашли лучше на практике:

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

РЕОР le talk о микросервисных архитектурах больше похож на график, чем на иерархию, и вариант 1 рода превращает это в иерархию, где вы получаете все более грубые композиты. Другие недостатки - это создает путаницу в отношении того, какие сервисные клиенты должны фактически использовать, и происходит некоторое дублирование, потому что API композитов должен включать все параметры, необходимые для вызова нижеперечисленных служб. У этого есть большое преимущество, потому что это дает вам естественное место, чтобы справиться с обработкой ошибок, хореографией и согласованностью дескрипторов.

Вариант 2 кажется, что он имеет свои недостатки тоже:

• АНЯ лицензирование должна просачиваться в студенческой API, так что вы можете указать лицензионные ограничения.

• это ставит много нагрузки на студент-сервис, поскольку он должен обрабатывать согласованность всех зависимых служб

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

Вариант 3 Будучи развязкой неба, я не думаю, что будет работать, потому что это все вызвано из пользовательского интерфейса, и люди на самом деле не используется для «пойти и сделать что-то еще, пока этот новый студент показывает вверх " подход.

Спасибо

Answer 1

лицензирования приложений и создание студентов ортогональны так вариант 2 не имеет смысла.

Вариант 1 более разумный, но я бы постарался не строить еще одну услугу. Вместо этого я попытался бы «отфильтровать» звонки на услуги ученика с помощью промежуточного программного обеспечения лицензирования.

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

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

Answer 2

ИМХО, я бы пошел с вариантом 2. Несколько вещей, чтобы рассмотреть. Если вы покупаете полный комплект SOA и, кроме того, микросервисы, вы не можете вздрагивать каждый раз, когда службе необходимо связаться с другой службой. Успокойтесь с этим ... помните, в этом суть. Что мне действительно нравится в варианте 2, так это то, что успешный ответ студенческого обслуживания не отправляется до тех пор, пока запрос на получение лицензии не будет выполнен. Обращайтесь к лицензионному сервису как к любой другой внешней службе, где вы можете обернуть лицензионный сервис в клиентский объект, который может быть опубликован JAR с лицензией.

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

Да, будет использоваться API лицензионного обслуживания. Вы можете назвать это утечкой (кто-то должен ее использовать) или инкапсуляция, чтобы клиент, запрашивающий услуги-студент, не беспокоился о лицензировании.

• это ставит много нагрузки на студента-сервиса, поскольку он должен обрабатывать согласованность всех зависимых служб

Некоторые службы должен взять на себя это бремя. Но я бы справился с этим органично. Мы говорим о 1 услуге, которая нуждается в другой. Если это вырастет и станет неудобным, тогда можно сделать рефакторинг. Если количество услуг, требуемых для обучения студентов, растет, я думаю, что он может быть изящно реорганизован, и, возможно, студент-сервис становится составным сервисом, и группы независимо используемых сервисов могут быть объединены в новые службы, если это необходимо. Но если список служб зависимостей, которые использует служба-ученик, используется только службой-учеником, то я не знаю, стоит ли их группировать в свою службу. Я думаю, вместо того, чтобы бремя и утечка вы можете рассматривать как инкапсуляцию и владение .... где студент-сервис является владельцем этого бремени, поэтому ему не нужно утечка другим клиентам/услугам.

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

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

Если принудительно каждый из ваших вариантов можно превратить в жизнеспособное решение. Я делаю сомнительный случай для варианта 2.

Answer 3

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

Какой бы подход вы ни решили, разработайте свои услуги в Hexagonal architecture! Это избавит вас от проблем, когда вы решите перейти от одного решения к другому. То, что я обычно делаю, - это дизайн моих DAO как «адаптеров», поэтому DAO, который вызывает услугу A, будет либо вызывать его напрямую, либо через очередь сообщений, независимо от бизнес-логики. Когда мне нужно его изменить, я могу просто изменить этот DAO для другого, не касаясь какой-либо бизнес-логики (в конце концов бизнес-логика не волнует, как она получает данные). Шестиугольная архитектура очень хорошо подходит для тестирования микросервиса, TDD и черного ящика.

Answer 4

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

Как это сделать с помощью архитектуры, основанной на событиях?

1. Использование событий для отслеживания информации о лицензировании с помощью службы лицензирования в службе учеников, практически дублирование данных. Недостатки здесь: у вас только конечная согласованность, так как дублирование данных асинхронно.

2. Используйте асинхронные события, чтобы вызвать цепочку событий, которая в конечном итоге вызывает создание студента. Из вашего вопроса, похоже, у вас уже есть идея, но у вас есть проблема с пользовательским интерфейсом. У вас есть два возможных варианта: дождаться события создания (или сбоя) студента с небольшим количеством тайм-аута или (события лучше), сделайте вашу систему полностью реактивной (используйте механизм push-client-client для пользовательского интерфейса).