Есть сценарии, в которых используем очереди. Но это глубоко внутренние сценарии. С моей точки зрения, общение по REST проще в сопровождении и быстрее. Кроме того, простота REST для нас критична как для платформенного решения — представьте семинар по пользованию АПИ, где вы объясняете через POSTMAN collection, и семинар, где вы объясните асинхронную модель и работу с очередями. :) Если что-то для внешних пользователей можно упростить, то это всегда нужно упростить.
оба варианта, как мне кажется, имеют одинаковую сложность. Но в одном случае сложность имплементируется в коде, а во втором — в deployment схеме. Помните знаменитую картинку про микросверисы: сложность в коде vs сложность в связях?
Вы ранее назвали HTTP/gRpc стандартом общения микросервисов, а это значит что общение происходит синхронно(request/response), хотя для поддержания низкой связности всякие event-driven подходы считаются предпочтительнее.
В архитектуре, чисто философски, все компромисс. Иногда ведь и Вы, как архитектор, наверняка отказываетесь от более мощных решений (дающих лучшее масштабирование или производительность) в пользу более понятных решений (дающих более быстрый кодинг, ниже стоимость сопровождения). Cинхронное общение с одной стороны более понятное (простое с точки зрения отладки), с другой стороны более быстрое (все-таки проход через очередь дает много накладных расходов, хотя и добавляет гарантий). Поэтому, как мне кажется, в целом http/gRPC более широко используются чем общение через очереди. Ну и на http можно асинхронное имплементировать (202 и в путь).
Но я согласна с Вами, что event-driven подход имеет свои преимущества
Интересно было бы узнать, независимый ли у микросервисов цикл релизов друг от друга, и сколько сил/времени занимает координация релизов, она ведь всё-равно нужна иногда.
В Acronis сложная модель deploy-я в том смысле, что кроме облака, которым оперируем мы сами, есть еще on-premise deployment, когда наше облако разворачивают customer-ы для своих личных нужд. Поэтому модель «поправили (микро)сервис, залили в прод» у нас не применима. Мы выпускаем целостные релизы Acronis Cyber Cloud где фиксированы версии каждого сервиса
J2ee, кажется, ограничено Java-ой? А задачи Wamp-а не соответствуют задачам Kubernetes?
В общем, здесь можно идти в долгий философский диспут. Я далеко не фанат kubernetes, но, как Вы правильно сказали, стандарты побеждают в долгосрочной перспективе. А из нескольких альтернативных стандартов выживает не всегда самый лучший с технической точки зрения.
>>7 бед — один кубернет. И с ним уже 8 бед.
Намекаете на то что мысль выше — верна? Ок, спасибо.
kubernetes как ответ на вопрос «как потом деплоится такое приложение?». под «распределённый монолит взаимодействующий по сети» Вы имеете в виду сильную связность сервисов?
я бы сказал что история про deploy перекликается с историей про обратную совместимость
Безусловно, чтобы обновить API нужно раздеплоить новую версию компонента. Но, Евгений, кажется, я не улавливаю Выше мысль. Развернете?
Думаю, под «нерешаемой» проблемой скалирования/масштабирования вы имели ввиду «ограниченно решаемую»? Ведь наплодить потоков со своими дубликатами данных в рамках одного адресного пространства — дело несложное, но возникает ограничение размерами физической ноды.
Rust — это хорошая история, но, кажется, тогда всю серверную разработку прийдется переводить с Go на Rust, а это достаточно трудоемко. Вы используете Rust у себя? Можете поделиться опытом?
В монолитах свои проблемы с API. Текущие абстракции (leaky abstractions). Спинлоки, торчащие из интерфейсов, для производительности. Переменные с разделяемым доступом. Неструктурированные, но такие уютные и привычно-домашние интерфейсы, в которых любой посторонний ногу сломит.
Я нежно люблю монолиты за их скорость, но программный интерфейс между подсистемами внутри монолита нельзя называть сильной стороной этого паттерна
Не возникало ли у Вас в процессе мысли о том что проблем было бы меньше если бы использовалось не RESTAPI а более строгая спецификация?
Мысли что-то улучшить рождаются постоянно. Ограничивает обычно время, ресурсы и здравый смысл про лучшее враг хорошего. Но давайте обсудим про более строгие спецификации. Вы имеете в виду GraphQL или что-то другое? И какие плюсы Вы сами в них видите?
А если RESTAPI, то в ее модификации купно с HATEOAS?
Те сервисы Акронис, которые используют мультимедиа контент, следуют рекомендациям HATEOAS. Если у Вас есть позитивный опыт применения HATEOAS в других паттернах, буду рада услышать
Все споры и «сборная солянка» решаются обычно API Guideline-ами. Пока не могу дать ссылку на наш, хотя мы тоже себе разработали (более практичный, менее объемный). Поэтому вот MS-ный github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md
Отвечая же на Ваше сравнение с GraphQL — как архитектор вы всегда в поисках компромисса: жесткий стандарт не всегда уместно ограничивает и порождает уродливые конструкции, гибкое и более высокоуровневое описание дает возможность как написать очень хорошо, так и написать очень плохо…
Swagger (swagger2) имеет мощную инструментальную базу open source. При этом OAS3 в большей части тулзов, что мы пробовали, имеет либо экспериментальную поддержку либо не поддерживается вообще. Перефразируя, OAS3 — это мейнстрим, но пока число тулзов поддерживающих OAS3 значительно меньше чем число тулзов, поддерживающих swagger2
Я, как архитектор, привыкла что привычки людей тоже входят в часть уравнения. Что при принятии решения о выборе технологий учитывается тот стек, который уже в ходу. И оттуда возникает вопрос про «enterprise» или «cloud».
Под более слабым развитием я подразумеваю количество тулзов и возможности ими предоставляемыми. И степени их adoption
WSDL, конечно, мощный протокол. Но кажется его перспективы развития чуть слабее чем у RAML. И исторически WSDL относится больше к enterprise разработке, а не к облачным сервисам, которые преимущественно HTTP REST или gRPC.
едва ли. найдите опытного коллегу по работе и спросите его рекомендаций (хотя бы по вузу и кафедре). зайдите на сайт местного вуза и посмотрите направления. пообщайтесь со студентами нужного вам направления и узнайте их описания по преподавателям. При выборе НР вас интересует: 1/ насколько он в теме? 2/ сколько времени он готов вам уделять на регулярной основе? 3/ что он за человек, будет ли он ощущать ответственность за вас, будет ли он помогать вам. в свою очередь вам нужно показать НР: 1/ насколько серьезны ваши намерения, 2/ какие уже наработки по теме есть.
В первом приближении процесс выглядит так:
1/ придумать себе захватывающее тему
2/ найти научного руководителя, который тоже в теме заинтересован и который сможет оценить научность темы
лучше чтобы эта тема прямо или косвенно соотносилась с работой
3/ работать интенсивно над темой, представлять доклады на научных конфренциях (не менее 4 или 5), писать статьи (не менее 7), мониторить литературу чтобы быть в теме наработок
4/ в какой-то момент сдать кандидатский минимум (3 экзамена) — это можно сделать во многих научных институтах
5/ когда почувствуете, что основной результат получен, приступить к первому наброску автореферата
6/ имея на руках автореферат, работу, статьи и минимум, попросить научрука/коллег посоветовать диссовет. связаться с ними и сказать, что хотите у них защищаться. вам организуют экспертный семинар (где актуальность темы, научность вашего исследования и новизну результатов будет оценивать человек 30, причем чаще всего 30 умных человек). и если после экспертного семинара вы понравитесь в диссовете, то вам нужно писать автореферат, диссертацию и собрать несколько справок (отзывы оппонентов, отзыв научрука, справка о внедрении, отзыв ведущей организации и пр). Но там уже ваш главный советчик ученый секретарь.
В архитектуре, чисто философски, все компромисс. Иногда ведь и Вы, как архитектор, наверняка отказываетесь от более мощных решений (дающих лучшее масштабирование или производительность) в пользу более понятных решений (дающих более быстрый кодинг, ниже стоимость сопровождения). Cинхронное общение с одной стороны более понятное (простое с точки зрения отладки), с другой стороны более быстрое (все-таки проход через очередь дает много накладных расходов, хотя и добавляет гарантий). Поэтому, как мне кажется, в целом http/gRPC более широко используются чем общение через очереди. Ну и на http можно асинхронное имплементировать (202 и в путь).
Но я согласна с Вами, что event-driven подход имеет свои преимущества
В Acronis сложная модель deploy-я в том смысле, что кроме облака, которым оперируем мы сами, есть еще on-premise deployment, когда наше облако разворачивают customer-ы для своих личных нужд. Поэтому модель «поправили (микро)сервис, залили в прод» у нас не применима. Мы выпускаем целостные релизы Acronis Cyber Cloud где фиксированы версии каждого сервиса
В общем, здесь можно идти в долгий философский диспут. Я далеко не фанат kubernetes, но, как Вы правильно сказали, стандарты побеждают в долгосрочной перспективе. А из нескольких альтернативных стандартов выживает не всегда самый лучший с технической точки зрения.
kubernetes как ответ на вопрос «как потом деплоится такое приложение?». под «распределённый монолит взаимодействующий по сети» Вы имеете в виду сильную связность сервисов?
Безусловно, чтобы обновить API нужно раздеплоить новую версию компонента. Но, Евгений, кажется, я не улавливаю Выше мысль. Развернете?
Я нежно люблю монолиты за их скорость, но программный интерфейс между подсистемами внутри монолита нельзя называть сильной стороной этого паттерна
Мысли что-то улучшить рождаются постоянно. Ограничивает обычно время, ресурсы и здравый смысл про лучшее враг хорошего. Но давайте обсудим про более строгие спецификации. Вы имеете в виду GraphQL или что-то другое? И какие плюсы Вы сами в них видите?
Те сервисы Акронис, которые используют мультимедиа контент, следуют рекомендациям HATEOAS. Если у Вас есть позитивный опыт применения HATEOAS в других паттернах, буду рада услышать
Но обычно история про deploy отделена от истории про API.
Отвечая же на Ваше сравнение с GraphQL — как архитектор вы всегда в поисках компромисса: жесткий стандарт не всегда уместно ограничивает и порождает уродливые конструкции, гибкое и более высокоуровневое описание дает возможность как написать очень хорошо, так и написать очень плохо…
Под более слабым развитием я подразумеваю количество тулзов и возможности ими предоставляемыми. И степени их adoption
1/ придумать себе захватывающее тему
2/ найти научного руководителя, который тоже в теме заинтересован и который сможет оценить научность темы
лучше чтобы эта тема прямо или косвенно соотносилась с работой
3/ работать интенсивно над темой, представлять доклады на научных конфренциях (не менее 4 или 5), писать статьи (не менее 7), мониторить литературу чтобы быть в теме наработок
4/ в какой-то момент сдать кандидатский минимум (3 экзамена) — это можно сделать во многих научных институтах
5/ когда почувствуете, что основной результат получен, приступить к первому наброску автореферата
6/ имея на руках автореферат, работу, статьи и минимум, попросить научрука/коллег посоветовать диссовет. связаться с ними и сказать, что хотите у них защищаться. вам организуют экспертный семинар (где актуальность темы, научность вашего исследования и новизну результатов будет оценивать человек 30, причем чаще всего 30 умных человек). и если после экспертного семинара вы понравитесь в диссовете, то вам нужно писать автореферат, диссертацию и собрать несколько справок (отзывы оппонентов, отзыв научрука, справка о внедрении, отзыв ведущей организации и пр). Но там уже ваш главный советчик ученый секретарь.