Микросервисы и каноническая модель

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

Шаблон архитектуры микросервисов также отклоняет другие части SOA, такие как концепция канонической схемы.

— Пунтер Вики
источник

Вы случайно не знаете источник этого заявления? (для связи)

— Джек

Конечно Джек, это здесь - nginx.com/blog/introduction-to-microservices/…

— Вики

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

— Арсений Мурзенко

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

— Punter Vicky

Некоторые модели данных да, но мне кажется, что в статье говорится о «общих» или «общих» моделях данных между двумя или более службами. Каноническая схема - это шаблон, предназначенный для сохранения служб при преобразованиях данных во время выполнения. Общий "язык" между сервисами. Похоже, что статья подчеркивает полную независимость РС от «экосистемы», в которой он живет. Возьмем, к примеру, упоминание о ESB. ESB обычно требует корпоративную модель данных (сообщения), которая будет общей для всех в шине. MS отказывается присоединяться к любой внешней системной перетяжке.

— Laiv

Ответы:

Заранее извиняюсь за то, что полагаюсь на комментарий @ArseniMourzenko, но как только я начал читать Википедию, я сразу понял, что означает каноническая схема .

Вот комментарий ОП, который фокусируется на реальных сомнениях

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

Некоторая модель данных да, но кажется, что статья ссылается на «общие» или «общие» модели данных между двумя или более сервисами.

Canonical схема представляет собой модель предназначена для сохранения услуг от в преобразованиях данных во время выполнения. Это также спасает вас от дублирования кода. Но вы также связываете свой сервис с внешней моделью данных. (См. Диаграммы на странице Википедии, ссылка на которую приведена выше)

Это своего рода «язык» между сервисами.

Похоже, что статья подчеркивает полную независимость РС от «экосистемы», в которой он живет.

Возьмем, к примеру, упоминание о ESB.

Они также очень избегают использования ESB и вместо этого реализуют функциональность, подобную ESB, в самих микросервисах.

ESB обычно требует корпоративную модель данных (сообщения), которая будет общей для всех, кто подключен к шине.

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

— LAIV
источник

Спасибо @Laiv. Я буду награждать награду в 9 часов - так ограничивает меня :)

— Punter Vicky

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

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

— pnschofield
источник

If you find that you have microservices making synchronous calls, Не обязательно асинхронные вызовы. Это может произойти и с асинхронными сообщениями ESB. Я думаю, что это сфокусировано на том факте, что он должен быть связан с общими схемами или контрактами данных. Я предполагаю, что в архитектуре MS следует избегать любой связи p2p между серверами. Связь должна происходить через приложения, а не через какой-либо внутренний (внутренний уровень обслуживания) или внешний (ESB, очередь и т. Д.)

— Уровень