микросервисы - это одна услуга на CRUD

Question

Очень плохо знакомы с микросервисами ...

Если у меня есть API, который имеет дело с CRUD для клиентов и заказов, это переводит на 2 микросервиса, один для клиентов и один для заказов?

API клиента

CreateCustomer
ReadCustomer
UpdateCustomer
DeleteCustomer

API заказа

CreateOrder
ReadOrder
UpdateOrder
DeleteOrder

Answer 1

С чисто технической точки зрения, чем меньше микросервис, тем проще его разработка (Agile), итерация быстрее (Lean) и более частое развертывание (Continuous Delivery).Но на стороне моделирования важно избегать создания слишком маленьких сервисов.Согласно Вону Вернону (автору книги IDDD), мы не можем произвольно уменьшить размер ограниченного контекста, поскольку его оптимальный размер определяется бизнес-контекстом (доменом).Наша техническая потребность в размере услуги иногда может отличаться (меньше) от того, что может облегчить моделирование DDD.Вероятно, именно поэтому Сэм Ньюман очень осторожно назвал ограниченный контекстный анализ отличным началом, но не единственным рецептом определения размера микросервисов.Ограниченные контексты - отличное начало.

Answer 2

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

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

Но опять же, выполнение архитектуры mircorservice должно быть деталью реализации.Прежде всего, ваш домен должен быть хорошо спроектирован, иначе резкое слияние в сервисы станет кошмаром.

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

Answer 3

Я бы сказал, что это зависит от того, как используются эти услуги.Вот два варианта, о которых я мог бы подумать

opt 1) Один лямбда-метод на конечную точку

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

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

opt 2) две лямбда-функции

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

Две функции Lambda совместно используют одни и те же параметры памяти и времени ожидания.

...

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

Обе опции можно легко развернуть, используя SAM .

Некоторая хорошая документация для получения дополнительной информации:

Безсерверная архитектура с AWS Lambda

Answer 4

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

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

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

В конце одна из проблем, с которыми вы можете столкнуться, заключается в том, что ваш пример может быть слишком простым.Простые CRUDы сами по себе обычно не оправдывают реальных микросервисных архитектур, и чрезмерная разработка этих сценариев может принести вам больше вреда, чем пользы.

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