История изменений

При чём тут rabbitmq? Речь про разделение самого приложения на микросервисы, как альтернативу монолиту, а не про вкомпиливание всего на свете внутрь приложения. Если к монолиту добавить linux kernel, postgresql, rabbitmq, nginx и amazon s3, это всё ещё будет монолит.

Или я не понял, к чему был задан вопрос про rabbitmq.

Если что, монолит вполне может запускаться в 999 экземлярах и использовать тот же rabbitmq для взаимодействия между своими компонентами. Это тоже нормально. Можно даже в 1 экземпляре использовать rabbitmq для взаимодействия между модулями, это же по сути такая специфичная СУБД.

Сервисная или микросервисная архитектура, как противопоставление монолита, это прежде всего другой организационный подход. У разных модулей совершенно разные кодовые базы, чаще всего разные исполнители, порой даже разные языки программирования, не говоря уже о фремворках и библиотеках. Каждый модуль деплоится как независимая единица. И граница их взаимодействия чётко очерчена - это, как правило, HTTP API, ну или тот же Rabbit MQ, но в любом случае один сервис не может через рефлекшн вытащить поле в другом сервисе и поменять у него там значение, потому, что программисту вломы переделывать всё как надо, ему надо баг пофиксить побыстрей и уйти в бар. А в монолите - может. И это всегда нетривиальная задача - блюсти разделение между компонентами и настаивать на соблюдении границ, ведь их так просто нарушить.

Ещё встречаются интересные гибридные архитектуры. Когда в одном приложении явно выделяются разные модули, и есть возможность либо запускать все или часть модулей в рамках одного процесса, в этом случае они общаются внутри процесса, либо запускать один модуль в одном процессе и модули будут общаться через внешний транспорт вроде HTTP. При этом всё в любом случае компилируется в один бинарник. Я такую встречал в loki. Это даёт с одной стороны возможность масштабировать приложение по компонентам, например запустить один компонент в 10 экземлярах, а второй в 2 экземплярах. С другой стороны для простых деплойментов всё запускается как один процесс без лишних заморочек. Но такое есть смысл делать для коробочного софта, вроде того же loki, который устанавливается самым разным клиентам разного масштаба.

Хотя идея запускать самодостаточный EFI-бинарник, в котором вкомпилено и ядро, и приложение, и СУБД при надобности - это прикольно. Ну или хотя бы без ядра, просто приложение без зависимостей. Эдакий супер-монолит. Я такого не видел.

При чём тут rabbitmq? Речь про разделение самого приложения на микросервисы, как альтернативу монолиту, а не про вкомпиливание всего на свете внутрь приложения. Если к монолиту добавить linux kernel, postgresql, rabbitmq, nginx и amazon s3, это всё ещё будет монолит.

Или я не понял, к чему был задан вопрос про rabbitmq.

Если что, монолит вполне может запускаться в 999 экземлярах и использовать тот же rabbitmq для взаимодействия между своими компонентами. Это тоже нормально. Можно даже в 1 экземпляре использовать rabbitmq для взаимодействия между модулями, это же по сути такая специфичная СУБД.

Сервисная или микросервисная архитектура, как противопоставление монолита, это прежде всего другой организационный подход. У разных модулей совершенно разные кодовые базы, чаще всего разные исполнители, порой даже разные языки программирования, не говоря уже о фремворках и библиотеках. Каждый модуль деплоится как независимая единица. И граница их взаимодействия чётко очерчена - это, как правило, HTTP API, ну или тот же Rabbit MQ, но в любом случае один сервис не может через рефлекшн вытащить поле в другом сервисе и поменять у него там значение, потому, что программисту вломы переделывать всё как надо, ему надо баг пофиксить побыстрей и уйти в бар. А в монолите - может. И это всегда нетривиальная задача - блюсти разделение между компонентами и настаивать на соблюдении границ, ведь их так просто нарушить.

Ещё встречаются интересные гибридные архитектуры. Когда в одном приложении явно выделяются разные модули, и есть возможность либо запускать все или часть модулей в рамках одного процесса, в этом случае они общаются внутри процесса, либо запускать один модуль в одном процессе и модули будут общаться через внешний транспорт вроде HTTP. При этом всё в любом случае компилируется в один бинарник. Я такую встречал в loki. Это даёт с одной стороны возможность масштабировать приложение по компонентам, например запустить один компонент в 10 экземлярах, а второй в 2 экземплярах. С другой стороны для простых деплойментов всё запускается как один процесс без лишних заморочек. Но такое есть смысл делать для коробочного софта, вроде того же loki, который устанавливается самым разным клиентам разного масштаба.

Хотя идея запускать самодостаточный EFI-бинарник, в котором вкомпилено и ядро, и приложение, и СУБД при надобности - это прикольно. Эдакий супер-монолит. Я такого не видел.

При чём тут rabbitmq? Речь про разделение самого приложения на микросервисы, как альтернативу монолиту, а не про вкомпиливание всего на свете внутрь приложения. Если к монолиту добавить linux kernel, postgresql, rabbitmq, nginx и amazon s3, это всё ещё будет монолит.

Или я не понял, к чему был задан вопрос про rabbitmq.

Если что, монолит вполне может запускаться в 999 экземлярах и использовать тот же rabbitmq для взаимодействия между своими компонентами. Это тоже нормально. Можно даже в 1 экземпляре использовать rabbitmq для взаимодействия между модулями, это же по сути такая специфичная СУБД.

Сервисная или микросервисная архитектура, как противопоставление монолита, это прежде всего другой организационный подход. У разных модулей совершенно разные кодовые базы, чаще всего разные исполнители, порой даже разные языки программирования, не говоря уже о фремворках и библиотеках. Каждый модуль деплоится как независимая единица. И граница их взаимодействия чётко очерчена - это, как правило, HTTP API, ну или тот же Rabbit MQ, но в любом случае один сервис не может через рефлекшн вытащить поле в другом сервисе и поменять у него там значение, потому, что программисту вломы переделывать всё как надо, ему надо баг пофиксить побыстрей и уйти в бар. А в монолите - может. И это всегда нетривиальная задача - блюсти разделение между компонентами и настаивать на соблюдении границ, ведь их так просто нарушить.

Ещё встречаются интересные гибридные архитектуры. Когда в одном приложении явно выделяются разные модули, и есть возможность либо запускать все или часть модулей в рамках одного процесса, в этом случае они общаются внутри процесса, либо запускать один модуль в одном процессе и модули будут общаться через внешний транспорт вроде HTTP. При этом всё в любом случае компилируется в один бинарник. Я такую встречал в loki. Это даёт с одной стороны возможность масштабировать приложение по компонентам, например запустить один компонент в 10 экземлярах, а второй в 2 экземплярах. С другой стороны для простых деплойментов всё запускается как один процесс без лишних заморочек. Но такое есть смысл делать для коробочного софта, вроде того же loki, который устанавливается самым разным клиентам разного масштаба.

При чём тут rabbitmq? Речь про разделение самого приложения на микросервисы, как альтернативу монолиту, а не про вкомпиливание всего на свете внутрь приложения. Если к монолиту добавить linux kernel, postgresql, rabbitmq, nginx и amazon s3, это всё ещё будет монолит.

Или я не понял, к чему был задан вопрос про rabbitmq.

Если что, монолит вполне может запускаться в 999 экземлярах и использовать тот же rabbitmq для взаимодействия между своими компонентами. Это тоже нормально. Можно даже в 1 экземпляре использовать rabbitmq для взаимодействия между модулями, это же по сути такая специфичная СУБД.

Сервисная или микросервисная архитектура, как противопоставление монолита, это прежде всего другой организационный подход. У разных модулей совершенно разные кодовые базы, чаще всего разные исполнители, порой даже разные языки программирования, не говоря уже о фремворках и библиотеках. Каждый модуль деплоится как независимая единица. И граница их взаимодействия чётко очерчена - это, как правило, HTTP API, ну или тот же Rabbit MQ, но в любом случае один сервис не может через рефлекшн вытащить поле в другом сервисе и поменять у него там значение, потому, что программисту вломы переделывать всё как надо, ему надо баг пофиксить побыстрей и уйти в бар.

Ещё встречаются интересные гибридные архитектуры. Когда в одном приложении явно выделяются разные модули, и есть возможность либо запускать все или часть модулей в рамках одного процесса, в этом случае они общаются внутри процесса, либо запускать один модуль в одном процессе и модули будут общаться через внешний транспорт вроде HTTP. При этом всё в любом случае компилируется в один бинарник. Я такую встречал в loki. Это даёт с одной стороны возможность масштабировать приложение по компонентам, например запустить один компонент в 10 экземлярах, а второй в 2 экземплярах. С другой стороны для простых деплойментов всё запускается как один процесс без лишних заморочек. Но такое есть смысл делать для коробочного софта, вроде того же loki, который устанавливается самым разным клиентам разного масштаба.

При чём тут rabbitmq? Речь про разделение самого приложения на микросервисы, как альтернативу монолиту, а не про вкомпиливание всего на свете внутрь приложения. Если к монолиту добавить linux kernel, postgresql, rabbitmq, nginx и amazon s3, это всё ещё будет монолит.

Или я не понял, к чему был задан вопрос про rabbitmq.

Если что, монолит вполне может запускаться в 999 экземлярах и использовать тот же rabbitmq для взаимодействия между своими компонентами. Это тоже нормально. Можно даже в 1 экземпляре использовать rabbitmq для взаимодействия между модулями, это же по сути такая специфичная СУБД.

Сервисная или микросервисная архитектура, как противопоставлению монолита, это прежде всего другой организационный подход. У разных модулей совершенно разные кодовые базы, чаще всего разные исполнители, порой даже разные языки программирования, не говоря уже о фремворках и библиотеках. Каждый модуль деплоится как независимая единица.

Ещё встречаются интересные гибридные архитектуры. Когда в одном приложении явно выделяются разные модули, и есть возможность либо запускать все или часть модулей в рамках одного процесса, в этом случае они общаются внутри процесса, либо запускать один модуль в одном процессе и модули будут общаться через внешний транспорт вроде HTTP. При этом всё в любом случае компилируется в один бинарник. Я такую встречал в loki. Это даёт с одной стороны возможность масштабировать приложение по компонентам, например запустить один компонент в 10 экземлярах, а второй в 2 экземплярах. С другой стороны для простых деплойментов всё запускается как один процесс без лишних заморочек. Но такое есть смысл делать для коробочного софта, вроде того же loki, который устанавливается самым разным клиентам разного масштаба.

При чём тут rabbitmq? Речь про разделение самого приложения на микросервисы, как альтернативу монолиту, а не про вкомпиливание всего на свете внутрь приложения. Если к монолиту добавить linux kernel, postgresql, rabbitmq, nginx и amazon s3, это всё ещё будет монолит.

Или я не понял, к чему был задан вопрос про rabbitmq.

Если что, монолит вполне может запускаться в 999 экземлярах и использовать тот же rabbitmq для взаимодействия между своими компонентами. Это тоже нормально. Можно даже в 1 экземпляре использовать rabbitmq для взаимодействия между модулями, это же по сути такая специфичная СУБД.

При чём тут rabbitmq? Речь про разделение самого приложения на микросервисы, как альтернативу монолиту, а не про вкомпиливание всего на свете внутрь приложения. Если к монолиту добавить linux kernel, postgresql, rabbitmq, nginx и amazon s3, это всё ещё будет монолит.

Или я не понял, к чему был задан вопрос про rabbitmq.

Если что, монолит вполне может запускаться в 999 экземлярах и использовать тот же rabbitmq для взаимодействия между своими компонентами. Это тоже нормально. Можно даже в 1 экземпляре использовать rabbitmq, это же по сути такая специфичная СУБД.

При чём тут rabbitmq? Речь про разделение самого приложения на микросервисы, как альтернативу монолиту, а не про вкомпиливание всего на свете внутрь приложения. Если к монолиту добавить linux kernel, postgresql, rabbitmq, nginx и amazon s3, это всё ещё будет монолит.