А чем микросервис отличается от функции?

Если ты представления не имеешь что такое микросервисы, зачем ты пытаешься их использовать?

Если ты представления не имеешь что такое микросервисы, зачем ты пытаешься их использовать?

Стильно. Модно. Молодежно.

четыре звезды у чела, о майн готт

Нужно ли мне создавать микросервисы, если я делаю все один?

Нужно! Главное, чтобы!

И еще вопросик по кодовой базе: часто одни и те же функции используются.

Cоболезную.

Нужно в одной папочке все микросервисы хранить?

Гуру нтнрнета говорят - храни другие в другой папочке!

А если по сети взаимодействуют, то нужно каждый микросервис обновлять по отдельности?

Если вдвоем, то вместе!

И что еще получается нужен брокер сообщений или лучше на каждом МС поднимать свой http сервер(имхо так проще)?

Практика показала, что проще telnet!

Нужно ли мне создавать микросервисы, если я делаю все один?

Можно, это serverless функции + EDA (Event driven architecture)

Нужно в одной папочке все микросервисы хранить?

Нет, общие функции хранятся в одном репозитории

А если по сети взаимодействуют, то нужно каждый микросервис обновлять по отдельности?

Этим должна заниматься экосистема в которой функции эти находятся

И что еще получается нужен брокер сообщений Должна быть какая-то шина «событий».

В своем pet проджекте я использую knative экосистему для создания servelress функций, в ее поставки идут брокеры in-memory, kafka-broker, nats-brokker и многие другие

или лучше на каждом МС поднимать свой http сервер(имхо так проще)?

Istio инжектит в каждый pod с функцией свой sidecar который подсовывает событий из брокера конкретно в функцию в формате cloudevent

чем микросервис отличается от функции?

Сервис работает постоянно (принимая и обрабатывая запросы), функция (лямбда) стартует по запросу, делает свою работу и завершается.

То есть сервис минус вебсервер = набор лямбд. Ещё меньше рутинных задач, ещё плотнее фокус разработчика на бизнес-логике.

Чем модная и молодёжная лямбда принципиально отличается от старого доброго CGI-скрипта? А б-г его знает %)

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

Чем лямбда отличается от CGI-скрипта? А б-г его знает %)

как минимум возможностью canary-upgrade, blue-green подходом в деплойменте

возможностью canary-upgrade, blue-green подходом в деплойменте

Это скорее фичи инфраструктуры, на которой лямбдоскрипты крутятся, а не их самих.

четыре звезды у чела, о майн готт

Меня смущает что люди оценивают по звёздам что то. Звёзды - это просто сколько времени ты про*рал на этом форуме, не более.

лямбдофункция это всегда про «фичи инфрастуктуры».

лямбдофункция это всегда про «фичи инфрастуктуры».

Ну как бы да, без соответствующей инфраструктуры и CGI-скрипт не заработает %)

Istio инжектит в каждый pod с функцией свой sidecar

А линеечка у тебя есть сертифицированная, с логотипом кубера? %)

А если я использую ‘ps’ и ‘grep’ через конвейер, они становятся микросервисами?

ps axu | grep pattern

А если я использую ‘ps’ и ‘grep’ через конвейер, они становятся микросервисами?

пс да. он дует в трубку грепу.

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

Тем, что сервис «висит» в памяти, а функция вызывается из программы.

Звёзды дают за балаболию, а не за знания. У меня 3 аккаунта с 5 звёздами тут было (есть).

Нужно ли мне создавать микросервисы, если я делаю все один?

Если ты ставишь вопрос так - не нужно.

Нужно ли мне создавать микросервисы, если я делаю все один?

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

А для чего тебе микросервисы? Что ты от них хочешь получить?

Разбивка на микросервисы ведь делается не просто так, а с определенными целями.

И от этих целей зависят ответы на твои вопросы.

микросервис - это отдельное приложение

(Микро)набор функций в отдельном приложении/программе

нет

Приложение без функций?! Это уже следующий уровень.

сервис минус вебсервер

Сервис с вебсервером - это микро или макро?

Если не нравяться анонимные fifo (вызов процедур [со сторонними эффектами]), можно использовать unix-socket (функции, возвращающие результат, возможно, чистые). А там недалеко до IP-стека. Где граница микро/макро?

Сервис с вебсервером - это микро или макро?

Как-то же должен сервис принимать запросы, будь он микро или макро. То есть какой-то сервер в ём обычно есть.

Разбивка на микросервисы ведь делается не просто так, а с определенными целями.

Ага, были стандартные протоколы для rpc (большие и тяжелые из-за универсальности), заменили на нестандартные, у каждого свои, хрен кто влезет со стороны, незаменимость спеца обеспечена, зато микро, по началу, а потом…

А чем микросервис отличается от функции?

Микросервис это программа, функция это отображение одного множества на другое.

Нужно ли мне создавать микросервисы, если я делаю все один?

Не нужно.

И еще вопросик по кодовой базе: часто одни и те же функции используются. Нужно в одной папочке все микросервисы хранить? А если по сети взаимодействуют, то нужно каждый микросервис обновлять по отдельности? И что еще получается нужен брокер сообщений или лучше на каждом МС поднимать свой http сервер(имхо так проще)?

Делай как в каждом конкретном случае правильней.

микросервисы - это способ решить проблему коммуникаций в большом коллективе.

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

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

Для того, чтобы всё это изолировать, дробят на микросервисы: в этой палате^W комнате пишут платежную часть, тут скрепер сайтов, здесь вылизывают ленту фидов. Неизбежно остается платформенная команда - это те, кто обходят этот паноптикум, приносят еду, отмывают со стен кал и поддерживают в рабочем состоянии общую кафку.

Так что если у тебя 6 микросервисов шарят один код, то либо это твой новый stdlib и тогда оформляй его соответствующе: пиши документы, статьи как им пользоваться, желательно найти на гитхабе дураков, которые будут тебе его бесплатно чинить и развивать. Если не хочешь, то ты зря распилил и себя обманул.

То есть «микросервисы» - это про софт-скиллы (кто с кем сидит и кому косички дергает), а конкретный стек технологий - это совсем про другое?

Звёзды дают за балаболию, а не за знания.

я тоже хочу пять звезд, чем я хуже

Товарищ gobot еще как минимум в 2022м году начал работать с микросервисами. И к 2025му раздуплился вопросом, а что это вообще такое.

Нет. Софртина - кластер, состоящий из микросервисов, общающихся меж собой посредством Кролика. Это по сути Framework. Хотя с другой стороны - из коробки рабочая система с веь-админкой. Я кастомизирую все это под себя. Мне надо по событию Х запустить некое действие. Можно конечно логи парсить и там отлавливать, но я решил делать это на уровне Кролика

если для получения пяти звезд необходими отчаянно тупить, то я тоже так могу. @hobbit, что за дела, почему у меня нет пяти звезд, а что, недостаточно тупой?

совершенно верно.

микросервисы - это способ решить проблему коммуникаций в большом коллективе.

это старая парадигма, теперь микросервисы как часть EDA

https://en.wikipedia.org/wiki/Event-driven_architecture

«микросервисы» - это про софт-скиллы

ну ещё как минимум возможность разные ЯП для микросервисов использовать.

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

Event driven, как и общая шина - очень неоднозначная вещь, потому что в этом случае резко растет сложность в том месте, где эта шина начинает не справляться, где нужны синхронные ответы и т.п.

Но как одно из проявлений - да, безусловно

где нужны синхронные ответы и т.п.

в EDA классические синхронные «request-response» не нужны, и именно по этому, попытка сделать по «старинке» усложняет жизненный цикл событий.

Между «внешним миром» и EDA должны существовать API gateway, в которых request-response превращается в создание событий и ожидания нужных.

Some people, when confronted with a problem, think «I know, I’ll use micro-services.» Now they have many distributed problems.

Нужно ли мне создавать микросервисы, если я делаю все один?

При такой формулировке, скорее всего нет, вероятно ты и с одним макросервисом помрешь.

нет, так не пойдет. Если ответ на запрос нужен, значит он нужен.

Если он не нужен, значит в принципе не существует понятия ответ, просто кто-то что-то когда-то пришлет.

Но когда нужен нормальный ответ в разумное время, то вся эта ваша шина превращается в очень мешающую штуку.

нет, так не пойдет.

кому не пойдет?

Если ответ на запрос нужен, значит он нужен.

Но когда нужен нормальный ответ в разумное время

Вы видимо невнимательно читали часть про api-gateway А чем микросервис отличается от функции? (комментарий)

то вся эта ваша шина превращается в очень мешающую штуку.

Да и шина не моя, будьте любезны не приписывайте мне лишнего.

Если это function-as-a-service, FaaS то ничем.

А чем микросервис отличается от функции?

От замыканий. Ничем.

Функция ограничена собой, сервис – своим доменом.

FaaS – прослойка к БД. Сервис – буквально служба.

Да это всё пошло от Ruby on Rails, или даже раньше. Когда тормозная башка выполняет элементарную работу перекладывая вообще всё что можно на службы.

Если смотреть на микросервисы, то это развитие этого подхода.

Только в роли тормозной башки теперь фронт. А всё остальное – службы. Варианты их взаимной организации.

И что еще получается нужен брокер сообщений или лучше на каждом МС поднимать свой http сервер(имхо так проще)?

Брокер нужен, когда запрос нужно обработать независимо от формирования ответа пользователю.

Когда идёт запрос информации. И выдать её нужно здесь и сейчас. То брокер не нужен. Хотя и может использоваться как балансировщик. Раскидывающий запросы на N обработчиков.

Нужно ли мне создавать микросервисы, если я делаю все один?

Микросервисы делят проект на домены или команды. И им обязательно нужна мощная инфра, Kubernetes как минимум и понимание как реализовать инфраструктурные паттерны. Если проект планируется для обучения, пожалуйста. Иначе не вывезешь.

Нужно в одной папочке все микросервисы хранить?

В микросервисах фундамент — не папочки, а автоматизированный деплоймент.

А если по сети взаимодействуют, то нужно каждый микросервис обновлять по отдельности?

Разумеется. Желательно, чтобы это происходило бесшовно (старый сервис работает, новый выкатывается, трафик распределён).

И что еще получается нужен брокер сообщений или лучше на каждом МС поднимать свой http сервер(имхо так проще)?

sync API vs. async API. Разные вещи для разных задач.

Интереса ради, а куда делись твои звёзды? После сотни скора дают одну звезду же.

Ерунда это всё, не слушай никого. Делай, как тебе удобнее.

Ничерта всё это модное не делает полезного. Обвешались Куберами/Кафками сугубо чтобы щёки раздувать и хвастаться перед друг другом. Всё это падает и ломается от любого чиха. Толком взаимодействовать между командами/сервисами не выходит легко и просто. Настройки ПГ запрятаны в какие-то жопы подов, что аж целый образ надо просить девопса пересобирать если хочется wal_level=logical или shared_buffers подкрутить, например.

Тьфу, эта ваша заливная рыба.