Правильная архитектура для микро сервисов с несколькими пользовательскими интерфейсами - PullRequest
0 голосов
/ 25 ноября 2018

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

diagram of potential architecture for micro services

Примером системы такого типа может быть:

  1. Компания с несколькими сотрудниками, использующая систему для квотирования продуктов

    • , использующая продукты, котировки и пользователей mirco services
  2. Компания с веб-сайтом для отображения продуктов

    • с использованием продуктов микро-сервис
  3. Компания с несколькими сотрудниками, использующая систему для собственных котировок

    • с использованием котировок и пользовательских микро-сервисов

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

Как и вНа иллюстрациях все цитаты, продукты и пользователи могут храниться локально для сервисов mirco, используя уникальные ссылки для идентификации записей для каждой компании.Я не знаю, целесообразно ли это, так как это может затруднить управление данными и может привести к быстрому росту, затрудняя управление.

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

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

Ответы [ 2 ]

0 голосов
/ 02 декабря 2018

После долгих исследований, проведенных после различных онлайн-курсов, видеоуроков и некоторой документации, предоставленной Netflix, я пришел к пониманию первой структуры диаграммы в лучшем решении.

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

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

0 голосов
/ 26 ноября 2018

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

Исходя из первых принципов, у вас есть концепция цитата , которая должна была бы опросить продукт , чтобы узнать цену и другие детали.Может потребоваться доступ к пользователям для получения комиссионной информации и клиентам для таких вещей, как скидки и сроки поставки.Подобные понятия могут использоваться в разных приложениях;например инвентарь , каталог , заказ [немного отличается от цитата ].

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

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

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

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