Решить, как разбить систему на микросервисы - PullRequest
0 голосов
/ 17 сентября 2018

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

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

У меня есть один вопрос: рассмотрим тот же пример. Допустим, клиенты могут заказать свои товары в нашем интернет-магазине через две разные веб-страницы: webA и webB.

Какой подход лучше, создать два микросервиса (order-management-webA, order-management-webB) или только одно со всеми вещами (order-management)?

Я думаю, что у обоих подходов есть свои плюсы и минусы, но как вы думаете?

1 Ответ

0 голосов
/ 17 сентября 2018

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

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

Итак, чтобы ответить на ваш вопрос о примере, это зависит от того, что именно OMS делает для каждой из этих веб-страниц? Я могу сказать, что один запрос может исходить от вашего веб-приложения, а другой - от какой-либо торговой площадки, где вы разместили продукт (webB).

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...