Вопрос по дизайну приложения Azure Service Fabric

Question

У меня ниже требования в архитектуре микросервиса.Мой проект, относящийся к типу Azure Service Fabric, службы без сохранения состояния и с сохранением состояния в Dot Net Core.

Всего 3 службы без сохранения состояния и 3 с сохранением состояния в этом проекте.

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

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

Для целей связи мы будем использовать прокси-сервер службы (т. Е. Интерфейс, реализованный в IService).

Я могу легко вызывать методы stateful1 из stateless1, но у меня есть требование, как будто мне нужны данные из stateful1, которые зависят от stateful 2 и stateful 3.

У меня есть некоторая бизнес-логика между каждой службой с состоянием,

В настоящее время я создаю прокси-сервер службы на statful1 и собираю все данные с состоянием 2 и 3, и после того, как все данные будут переданы, будут отправлены без сохранения состояния.

У меня возникнет вопрос: лучше ли иметь одинеще слой, называемый репозиторием (проект библиотеки классов, используемый лицами без состояний), который будет связываться с каждой службой с состояниемd comupte бизнес-логика?

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

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

Пожалуйста, предложите мне лучший подход для выполнения этого требования.

Answer 1

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

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

Когда я слышу, что вы говорите о 50+ услугах, каждая из которых имеет аналога, так что на самом деле его 100+Службы, мое первое подозрение, может ли эта ваша архитектура чрезмерно инжиниринг?Но опять же, как я уже указывал, отсутствует много контекста, поэтому мне трудно действительно провести такую ​​оценку.

Возможно, вам следует подумать, может ли быть полезным объединить службу с состоянием 1, 2 и3, как вы их называете?

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

Недавно я был в похожей ситуации, когда 2Микросервисы (которых, по моему мнению, должно было быть 1) имели дело с тесно связанными данными, один был кейс-сервис, другой - сервис проверки данных клиента, бизнес запрашивал экспорт данных в csv-файл, где каждая строка в желаемом выводеCSV-файл содержит комбинацию данных из дела и проверки клиента.Единственный способ добиться этого - перебирать случаи и в каждом случае вызывать микросервис для проверки данных клиента, который, конечно, ужасно масштабировался.1000 случаев будет означать 1000 HTTP-звонков.Однако если в одной базе данных SQL было две таблицы, вы можете легко представить, как просто это можно решить с помощью одного запроса на соединение.

Иногда меньше значит больше.