Почему Дядюшка Боб обидел сервисы?
Вставка
- Опубліковано 12 тра 2022
- #soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwareengineervlog
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/id/5f578bdf22e2...
GitHub - github.com/soerdev
Чат для программистов - / discord
Группа ВК - codeartblog
Моя телега t.me/softwareengineervlog
я понимаю что это подкаст
но данную тему мне кажется стоит визуализировать и показывать конкретные примеры когда плохо, и когда хорошо
с данными и диаграммой общения между сервисами
тогда и проще, чем в голове это представлять, и выводы лучше запоминаются
Так все вроде просто. Если я правильно понял, то задача должна быть максимально конкретной, тогда она будет универсальной по внешним признакам. Прасинг Json файлов конкретная задача? Да. И при этом она нужна везде. Но ей грозит отдельная функция, а не сервис. Поэтому второе требование, задача должна потреблять ресурсы, чтобы ее было рентабельно выносить. Автор же привел в пример задачу хранения данных, почтовый сервис и онлайн карты. Мне приходит в голову распознавание лиц, маршрутизация, оркестрация, логирование с аналитикой. Если разбивать бизнес логику, тот тут надо прогнозировать, это уже не из области паттернов, а про аналитику. Вообще советуют начать с монолита, а потом отделять. А так принцип тот же что и везде. Что функция, что класс, что компонент должны выполнять конкретную задачу, тогда в больше всяких мест их можно будет запихнуть))) Это и есть low coupling, high cohesion.
По-моему, Мартин в первую очередь как раз объясняет различия между хорошей архитектурой со слабым зацеплением и сильной связностью и плохой, когда наоборот, и приводит пример, когда сервисы сильно зацеплены и соответственно при изменении данных, это изменение проходит через все сервисы - как пример как раз плохой архитектуры. Далее он объясняет принципы разбиения на компоненты, чтобы уменьшить зацепление и увеличить связность, и говорит, что компонент это может быть как либа, так и сервис.
Эта основная идея и заложена в Agile principles и Clean architecture Мартина, причем вторая книга действительно довольно поверхностно проходится по проблеме (у нее и объем 200-300 страниц), возможно поэтому складывается такое впечатление что Мартин топит против SoA, но это не так. Он топит против именно кривого SoA и объясняет, что сам по себе SoA, то есть микросервисы - не панацея, и там точно также важна правильная, "чистая", архитектура. В Agile principles есть даже отдельный пример иллюстрирующий этот случай.
Гладко было на бумаге, но забыли про овраги
Джуны пишут сервера, старички побитые опытом пишут сервисы…даже в монолите можно написать описанный сервис
Написать правильно новую службу, это дорого и требует огромных навыков у руководства (лиды, архитекторы, овнеры)…реальность слишком сурова… ещё и скрам подходы часто трактуются таким образом, что спринт производит юзер стори, если юзер не пощупал в конце спринта, значит ничего не наработали…вот из-за этого много кто разрабатывает апи сервиса и сразу же его интегрирует в одном спринте, редактируя по пути версию апи и клиентский код. Да и для бизнеса требования к сервису, часто это потребности клиентского кода.
В видео примеры сервисов это уже устоявшиеся службы, почтовик, БД и т.д.
Где АПИ разработан десятки лет назад (SQL это АПИ)
Возможно стоит прокачивать навыки создания того самого апи и думать не от потребностей клиента, например в этой книге много материалов на подумать
Проектирование веб АПИ (Арно Лоре)
За вектор поразмыслить - лайк Соеру! Особенно за… несколько часов - прочитал 🤪 📚
Техника чтения накось
А теперь бы про микросервисы, и их место в сервисно-ориентированной архитектуре
Спасибо за труд, никогда не задумывался над такими, казалось бы, незначительными семантическими деталями, но после просмотра ваших видео начинаю по другому смотреть на многие вещи в своей работе.
Вот бы теперь послушать чем отличаются сервисы и микросервисы
Очень хорошую мысль извлёк из ваших слов и мнения. Спасибо вам большое!
Интересно, благодарю
Интересно было бы послушать про микросервисы!
Потому что их одобрил дядя Сэм 👉. Не знаю как на беке - на фронте микрофронтенды помагают увеличить объемы работы, занять по больше персонала и отмыть по больше баблишек.
так же и на бэке
На бэке еще хуже, там появляется необходимость распределенных транзакций и проблемы многопоточности
@@drovoseg Можно добавить - отсутствие архитектора
Спасибо за разъяснение!
Спасибо за видео! Хорошое объяснение. До этого момента я думал что микросервисная архитектура это модная безсмыслица.
Спасибо!
Сделай выпуск пожалуйста подробнее про микросервисы, почему везде в паутине твердят что Go лучший язык для них?
Ну типа сравнительно простой в изучении, довольно шустрый, нет многотонных фреймворков, собирается всего в один бинарник (можно упростить процесс деплоя). В остальном такой же яп как и все остальные...
1. Быстрая компиляция - в отличие от других компилируемых языков
2. Достаточно простой синтаксис - в отличие от C++ или Rust
3. Скорость выполнения с CG - в отличие интерпретируемых языков и даже в какой-то мере по сравнению с языками, которые выполняются с помощью VM
4. Легкая и понятная многопоточность (для тяжелых сервисов это особенно важно) - в отличие от любого другого языка, который ее поддерживает
5. Статическая типизация - в отличие от JS или Python
6. Стандартная библиотека в большинстве случаев обеспечит все, что необходимо, чтобы запустить микросервис без чего бы то ни было еще. Просто запустил бинарные и сервис работает.
а как субд нам может отказать в обслуживании?
На мой взгляд, зацепление тут не при чем. Сервис - это терминология логического (абстрактного, доменного) уровня, а сервер - это техническое (физическое) понятие. Зацепление же - мера взаимосвязи. Сервер может предоставлять разные сервисы или не предоставлять вообще (какие-нибудь крон джобы). И у сервера может быть как низкое так и высокое зацепление и у сервиса. Если утрировать, это как сказать что если у чего-то скорость низкая то оно теплое, если высокая - оно мягкое. Короче, немного бредово, как по мне.
Речь же про "софтварный" сервер, в контексте "клиент-серверного" взаимодействия. А "сервис" в контексте SOA и далее вся разница в видео разжевана.
... пишите монолиты, когда и если придёт время нужды в "сервисах" к тому моменту вы уже должны быть в состоянии отдать на аутсорс, или начинайте писать новый монолит ))
Спасибо, нашёл 4 книги Роберта Мартина. Прочитаю обязательно.
я так понял, сервис это отдельное маленькое приложение, из этих мини приложений как конструктор собирается большое приложение... если нам какой-то сервис не подходит, легко заменяем его, при этом само приложение не меняется.. а что тогда приложение? это только название, обедняющее различные сервисы?
да
Я всё думаю в бд связь one to mony albums, genres вот думаю в NestJs контролере дёргать 2 сервиса или создать 2 метода 1 сервиса или в сервисе дёргать 2 репозитория или фильтровать с помощью queryParams по году и жанру с одим сервисом, контролером и репозиторием) В angulare с сервисами проще)
Вы не про те сервисы думаете) В данном видео речь идёт о сервисе который поднимается как отдельное приложение в рамках другого процесса и общается с вашим приложением через HTTP запросы, а не сервис в виде класса в вашей приложеньке. Вы думаете о сервисах в контексте DDD, а тут этот термин используется в рамках сервисной или микросервисной архитектур, что совершенно разные вещи.
@@bubblesort6368понял спосибо у меня монолит)
Интересно, но водички много.
Возвращение ошибки с сервера не есть отказ от выполнения обслуживания?
Да. Ошибка от СУБД означает, что "я не понял, что ты имеешь в виду и не могу выполнить запрос. Если напишешь запрос, который я пойму, то выполню". Потому что это СУБД. И она не вернёт ошибку если ресурс просто не найден.
Так и не понял почему дядя Боб обидел сервисы
Сервисный сервис
Думаю, что для ясного понимания необходимо точно переводить "service" и однозначно называть по-русски что подразумеваешь под словом "сервис":
1.Услуга.
2.Обслуживание.
3.Служба.
Вы затронули очень острую тему, сейчас такой хейт поднимется. А по-существу, конечно же, правильно. Причём, не только для темы данного ролика - это повсеместно. Иногда можно увидеть целые лекции, где люди пытаются объяснить что-то, хотя достаточно было бы дать точный, не синонимичный перевод. Достаточно взглянуть на инструкцию к любому лекарству в аптеке, чтобы осознать масштаб языковой катастрофы.
Что-то лайков маловато
Ну не знаю...
Вот допустим разработчики стороннего сервиса - решил поменять свое апи, и при этом забил на обратную совместимость. Что с этим делать?
Ну, типа для примера та же СУБД, вот решили разработчики - что Дата-Время без часового пояса не имеет смысла, с новым апдейтом - все ваши транзакции без пояса - отфутболиваются и настойчиво просят дату-время. Вы конечно можете перейти на другую СУБД, но у вас много своего кода, плюс плюшек куча у той СУБД и вообще, в итоге - вы скорее намутите во всех местах со врпеменем-датой какой-нибудь костыль(ну или баналный перехватчик делаете, который добавляет этот самый часовой пояс если надо), чтобы таки время-дату использовать, если хотите последнюю версию использовать. А возможно вы и хотите, ведь помимо вот таких вот ломающих изменений - там нужные вам плюшки, которых еще и ни у кого нет, еще и миллионы денег заплочены.
Короче. Я к чему. К тому что видимо я что-то не понимаю.
Это какая же такая СУБД, чтоб разработчики так извращались? Само ядро любой СУБД это ее типы данных, разработанные раз и навсегда. Изменив что-то в типах можно просто выкинуть продукт на помойку. Вы о чём? О самописной может?
@@itcloudguy Пример был гипотетический, на основе реального провайдера pgSql для efCore в дотнете, когда в разработчики с той стороны решили, что все, мы будем кидать эксепшн если не передать таймзону для полей с временем(те что просто DateTime). Да, там дали возможность и по старому работать, но пометили это как легаси.
Ну так вот, из-за этого, конкретно у нас - пришлось на время всю разработку остановить. А почему? Потому что - вот, они порешали, что не кошерно и вообще - в дотнете некрутое время, а мы - хотим круто, потому - страдайте. Весело - офигеть.
Использовать слова "служба" и "сервис" как имеющие разный смысл в русском языке намного проще, чем в английском.
Они не о разном смысле. Слово "сервис" - иностранное. И на русском означает "служба". Никак иначе.
@@itcloudguy Вот и я о том. Автор ролика использует эти слова как имеющие разный смысл. И очень интересно, какой англоязычный смысл он имеет в виду, говоря "служба".
Побуду немного душным и скажу, что вы путаете связанность с зацеплением
Это вы путаете, потому что связанность это и есть зацепление (coupling), вы перепутали ее со связностью (cohesion), что суть характеристика модуля, когда в нем содержатся близкие по смыслу концепции (это хорошо). Зацепление - это плохо, это количество внешних зависимостей модуля, чем их больше, тем меньше связность модуля и тем хуже.
@@AlexP-jc7rz Оу, благодарю, буду внимательнее
Дичь лютая!
"Сервис, сильно зацепленный на логику вашего приложения, является просто вынесенной службой." А слово service как с английского переводится?
Чуть ранее в качестве сервиса была упомянута СУБД. ЧЁ??? Где тут низкое зацепление? Разве приложение не содержит слой моделей, которые в точности повторяют структуру таблиц? Или, может быть, приложение продолжает работать после того, как сервер БД прилег?