Комментарии 18
Каковы на ваш взгляд основные причины для того чтобы разделить сайт с журналами на отдельные микрослужбы? Какие проблемы вы решаете таким образом?
Ещё интересуют причины выбора Mongo вместо традиционных реляционных БД. В чём преимущество Mongo с вашей точки зрения?
Ещё интересуют причины выбора Mongo вместо традиционных реляционных БД. В чём преимущество Mongo с вашей точки зрения?
Из основных причин, пожалуй это высокая нагрузка, но из моего опыта у систем такого класса это достаточно редкое явление ) Также использование микросервисной архитектуры позволяет сделать разные части проекта независимыми, т.е. например, отказ в работе комментариев не отразится на работоспособности других сервисов. В целом, цель статьи показать вариант реализации взаимодействия между микросервисами на простом и понятном примере. MongoDB выбрана с целью децентрализации данных. Использование единой релеационной БД вносит ненужную связанность между микросервисами, а использование отдельных релеационных БД под каждый микросервис, на мой взгляд, избыточно.
1. Каким образом межсервисное сетевое взаимодействие, которое на порядки медленнее in-process, поможет вам в преодолении высоких нагрузок?
2. При отказе сервиса User все будет продолжать работать? Really?
3. Каким образом обеспечивается целостность и непротиворечивость данных в трех экземплярах БД? Или этот аспект вносит «ненужную связность»?
4. В зависимостях между сервисами часть стрелочек (например, комментарии зависят от User) опущена намеренно для «чистоты концепции»?
2. При отказе сервиса User все будет продолжать работать? Really?
3. Каким образом обеспечивается целостность и непротиворечивость данных в трех экземплярах БД? Или этот аспект вносит «ненужную связность»?
4. В зависимостях между сервисами часть стрелочек (например, комментарии зависят от User) опущена намеренно для «чистоты концепции»?
Попробую ответить по пунктам
1.Каким образом межсервисное сетевое взаимодействие ... — имеется ввиду когда под нагрузкой монолит будет «вставать на коленки» микросервис развернутый, например, на K8s за LB будет автоматически скейлится и работать в штатном режиме.
Безусловно за LB можно поставить весь монолит, вопрос сколько Вам для этого потребуется ресурсов. Прелесть микросервисова в том, что вы масштабируете только узкие места, сохраняя производительность малой кровью.
1.Каким образом межсервисное сетевое взаимодействие ... — имеется ввиду когда под нагрузкой монолит будет «вставать на коленки» микросервис развернутый, например, на K8s за LB будет автоматически скейлится и работать в штатном режиме.
Безусловно за LB можно поставить весь монолит, вопрос сколько Вам для этого потребуется ресурсов. Прелесть микросервисова в том, что вы масштабируете только узкие места, сохраняя производительность малой кровью.
Спасибо, вопросы мои были типовые, ответы, соответственно, тоже «давайте все разделим, а со связями разберемся потом, а с чем не разберемся — закэшируем». Начиная с 1980-х, это уже третья попытка. А ведь практически любая функциональная модификация системы добавляет и новые связи.
Не совсем понятно одно: монолит — это все что не микросервисы? Если чуть приподняться, то в предметных областях вы найдете сущности слабо и сильносвязанные, т.е. образующие подсистемы. Система из автономных подсистем тоже монолит?
Не совсем понятно одно: монолит — это все что не микросервисы? Если чуть приподняться, то в предметных областях вы найдете сущности слабо и сильносвязанные, т.е. образующие подсистемы. Система из автономных подсистем тоже монолит?
Простите, не совсем понял Ваш вопрос. Вы хотите чтобы я дал строгое определение монолита и микросервиса? Пожалуй я не готов это сделать, по мне так это очень халиварная тема и мне будет жаль потраченного времени. Но я могу поделиться своим практическим опытом, и продемонстрировать что в моей картине мира есть микросервис, а что монолит.
2. При отказе сервиса User все будет продолжать работать? Really? — why not, все силно зависит от архитектуры решения и способа публикации.
— На том же K8s можно поднять сервис User в котором гарантировано будет работать несколько подов микросервиса.
— Сервисы потребители должны быть устойчивы к подобного рода кейсам и не крашиться, а например повторять запросы по затухающей шкале (в gRPC это реализовано из коробки)
— Если, например, вы используете патерн API Gateway, в этом случае функция аутентификации/авторизации может кэшироваться на API Gateway и в этой части критичность сервиса User снижается
— На том же K8s можно поднять сервис User в котором гарантировано будет работать несколько подов микросервиса.
— Сервисы потребители должны быть устойчивы к подобного рода кейсам и не крашиться, а например повторять запросы по затухающей шкале (в gRPC это реализовано из коробки)
— Если, например, вы используете патерн API Gateway, в этом случае функция аутентификации/авторизации может кэшироваться на API Gateway и в этой части критичность сервиса User снижается
3. Каким образом обеспечивается целостность и непротиворечивость данных в трех экземплярах БД? — на уровне приложения. Это цена за независимость и распределенность.
4. В зависимостях между сервисами часть стрелочек (например, комментарии зависят от User) опущена намеренно для «чистоты концепции»? — чистоты концепции
А ещё я никак не могу понять смысл gRPC. Зачем ещё какая-то прослойка, если можно просто поднять микросервис и по урлу его дёргать? Объясните пожалуйста.
Я тоже не могу найти объективных причин усложнения архитектуры, объемы передаваемой информации не оправдывают его применение. Ну и раз уж речь зашла о gRPC то не плохо было бы сюда прикрутить что нибудь вроде егеря для трассировки. Чтобы решить те задачи которые в данном случае решает gRPC, достаточно реализовать REST Client для каждого микросервиса в виде пакета.
При написании связанных сервисов на GO столкнулся с тем что много кода дублируют друг дружку, особенно части отвечающие за транспорт и бизнесс-область, я правильно понимаю что по этой причине у вас все в одном моно-репозитории?
Сам думал о моно-репе или модных-новых-классных модулях
Мое личное мнение, моно-репа это наследие мышления в системе координат монолитых решений. Избыточность кода, это цена за независимость и децентрализованность. Представьте что каждый отдельный микросервис «пилит» отдельная команда, которая ничего не знает о коде других команд. В этом смысле избыточность выглядет уже иначе )
В примере моно-репа использовалась для упрощения процесса запуска проекта и понимания структуры проекта в целом.
В примере моно-репа использовалась для упрощения процесса запуска проекта и понимания структуры проекта в целом.
В условиях, когда человеческий ресурс избыточен (избыток программистов-техников при дефиците проектировщиков и аналитиков), вместо горизонтальной организации («системщики» делают платформу для «прикладников») часто используют вертикальную, где каждая команда реализует свои функции на базе собственных велосипедов. С точки зрения управления второй способ выглядит проще, как минимум до того момента, пока не вводится горизонтальная команда «архитектуры», уменьшающая риски одних и тех же повторяющихся ошибок.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем блог на микросервисах – часть 1 «Общее описание»