В банковском секторе дофига логики на java 6 написано

земля им пухом

Ну у них были свои представления о крутости архитектуры

а какое современное представление о крутости? :)

Мое имхо в том, что нет универсальной таблетки

книга-то хорошая?

а какое современное представление о крутости? :)

Недавно это были микросервисы, щас не знаю

а они не рулят уже чтоли? эти ваши микросервисы? :)

Ну да в них нашли кучи проблем и увеличение сложности

Все уже говорят что пишите монолит до тех пор пока это возможно

Я вижу пока одну проблему - потери производительности на сериализации/десериализации

когда они между собой активно разговаривают

У меня еще есть идея попробовать shared memory, но это так, на будущее. щас лень)

а какая shared memory может быть у микросервисов?

книга-то хорошая?

офигительная ))

а какая shared memory может быть у микросервисов?

Ну такое... Если работают на одном тазике)))

а какая shared memory может быть у микросервисов?

"микро"сервис)))

У меня еще есть идея попробовать shared memory, но это так, на будущее. щас лень)

Ничего себе идея, из 70х годов )

Ничего себе идея, из 70х годов )

Микросервисы оттуда же

Микросервисы оттуда же

Оу ну нет )

Что нет?

Нет, просто нет.

Ааа)

У вас в голове архитектурная каша.

У вас в голове архитектурная каша.

Как скажешь

Про history микросервисов можно почитать вот тут https://en.wikipedia.org/wiki/Microservices

Этот термин и понимание что он означает можно ну максимум отнести к началу 2000х

А сервер который в 70х слушает порт TCP, это не микросервис, нет, не он.

Что такое микросервис в Вашем понимании?

В моем понимании это как написано в первом абзаце википедии

А когда он появился в моем понимании это как написано в параграфе history в википедии )

Ясно

А каша у меня

Ну да, "тогда же", то есть в 70х, знать ничего не знали про микросервисы как сложившуюся концепцию. Были какие то обрывки идей, что вот есть сеть, вот есть какие то клиент серверные приложения они как то работают. Ни оркестрации, ни контейнеризации, ни stateless - о таком вообще даже не думали.

Ну да, "тогда же", то есть в 70х, знать ничего не знали про микросервисы как сложившуюся концепцию. Были какие то обрывки идей, что вот есть сеть, вот есть какие то клиент серверные приложения они как то работают. Ни оркестрации, ни контейнеризации, ни stateless - о таком вообще даже не думали.

Все описанное сейчас Вами нет в первом абзаце Википедии, в описании микросервиса

Я о оркестрации, контейнеризации...

другими словами ajax появился в середине 2000-х, а не в конце 90-х, потому что в 90-х это не называли ajax?)

То, что тогда это так не называлось, не говорит, что этого тогда не было

То, что тогда это так не называлось, не говорит, что этого тогда не было

Это уже философия и филология :)

Это уже философия и филология :)

Как скажешь

Как скажешь

Так не я говорю, говорит википедия и Мартин Фаулер. Ну можешь с ним контраргументировать.

но по сути своей микросервисы — это философия юникс, наложенная на сеть, и корни этой идеи действительно где-то в 60-70 годах, не?)

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

когда маркс написал про разделение труда

скорее, в период неолита, когда были заложены принципы разделения труда)

Я бы сказал что в 60-70 зародилась сама концепция сетей и сетевых протоколов.

А чем вам не нравится идея с шаред мемори?

там же ничо не нужно сериализовать/десериализовать

ну так сама идея микросервисов подразумевает же, что они могут быть размазаны тонким слоем по миру

А чем вам не нравится идея с шаред мемори?

Нравится, просто ты так сказал как будто это хорошая альтернатива микросервисам

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

Ну да, я просто не уточнил :)

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

Так а слой закоммуникацию мы делаем просто компонентом, и все

когда они локально - через шмем, когда на разных хостах - другой компонент:)

и каждый микросервис должен будет знать, не на другом ли сервере, случайно, находится микросервис, с которым он хочет пообщаться

зачем ему об этом знать?

За это отвечает компонент для "общения"

который тоже является микросервисом?)

А компонент через DI внедряется

Мы засунули микросервис в твой микросервис

:D

когда они локально - через шмем, когда на разных хостах - другой компонент:)

Ну вообще, есть трудность, через shared mem обычно обмениваются бинарными данными. Как 2 сервиса будут общаться это вопрос.

В итоге ты можешь прийти к тому что будешь данные сериализовать в тот же json, и оставлять его в памяти для другого сервиса.

согласен

Ты не можешь например, если у тебя есть 2 сервиса на D и на PHP, объект User просто подставить в память другого сервиса.

Ну наверно массивами чисел так можно обмениваться.

Короче я думаю тут нужно учитывать специфику какую то

Если у нас на одном хосте только скрипты на пыхе крутятся, то это сработает, инааче головняк :)

только что мы родили новую архитектурную парадигму — минисервисы

срочно нужно пилить сайт и строчить статьи

точно!

Прикиньте сколько бабла на этом поднимем? :)

по миру можно кататься, лекции читать

аля бизнес тренинги для девелоперов

срочно нужно пилить сайт и строчить статьи

Ирония в том, что так всё и происходит.

Не велико время потери, при сериализации © Йода

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

Да, есть потери по времени, но у тебя еще будут потери и при передачи этих данных по сети на другой сервер

Зато это гибко!

И позволяет разнести логику на части. И писать эти части на том, на чем легко их писать

Или быстро (GOвно, к примеру)...

Ага, гибко. Тоже самое про разработку логики на JS говорят. А потом более 70% времени уходит на бесполезную возню.

Не забывайте про проблему синхронизации версий микросервисов.

Не забывайте про проблему синхронизации версий микросервисов.

Не так уж и сложно

Ага, гибко. Тоже самое про разработку логики на JS говорят. А потом более 70% времени уходит на бесполезную возню.

Я же сказал гибко, а не удобно писать!)))

Любой инструмент или подход нужно использовать с головой и там где приемлимо.

А то начинается забивание гвоздей резиновыми "игрушками".

Зато это гибко.

Понял тебя я не совсем © Йода

о, Атилла быстро фиксит баги, это плюс

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

Там много факторов играет.

Просто говорить, что стек быстрее — бессмыслица.

Почему? Какие факты играют?

что такое “скорость доступа”?

Да вот хз. Я пытаюсь это и понять. А то много раз слышал в контексте что стек предпочтительнее

И мне не понятно почему. Что мешает на стеке хранить только указатели на данные и все

Да вот хз. Я пытаюсь это и понять. А то много раз слышал в контексте что стек предпочтительнее

Стек предпочтительнее потому, что из него не надо убирать, наверное